Naming convention for Projects and Net Service Name

[narasimha]

Hi all,

We are moving to a new set of DataStage servers and looking to see if we should use the same names for projects across all the environments, or different: Example XXX-DEV, XXX-TEST and XXX-PROD

Also want to know if the oracle net_service_name (in the tnsnames.ora file) should be the same name across different environments or is it a better practice to name it as per the environment example XXX-DEV, XXX-TEST, XXX-PROD.

One might say there is no standard naming convention or depends on the company standards (but currently we have none).
Please share your thoughts, if you found one better than the other with your experience.

[ray.wurlod]

There is a suggested standard in the Installation and Upgrade Guide.
DEVxxxVn through to PRODxxxVn. This convention allows for versions of projects, which may be a bit "over the top" for some sites.

You may have more than one phase of testing so might consider UAT, SIT or even SIT1, SIT2 and so on.

[narasimha]

Thanks for the reply.
True, we are going to have a UAT environment too, we would call it something like XXX-UAT.
Since these environments would be on complete different machines, we were debating the purpose of naming if differently, but I get when it comes to Versioning, it is better to have different names for different environments.

Any suggestions for the second part of the question, with respect to the Oracle "Net Service Name"

[chulett]

I prefer using the '-DEV/TEST/UAT/PROD' part of the name as a suffix, because I prefer projects to sort by name rather than environment when mixed on the same server. Still just a personal preference in the end, so you could end up with something like this:

A-DEV
A-TEST
A-UAT
B-DEV
B-TEST
B-UAT

-or-

DEV-A
DEV-B
TEST-A
TEST-B
UAT-A
UAT-B

I've seen both out there in the wild. For the Production side of the house, I generally drop the suffix rather than using "-PROD" but either is perfectly valid IMHO.

For the Oracle question, ideally that should all be controlled from a central name server where everyone has access to a single set of tns entries. This to cut down on having multiple tnsnames.ora files scattered around with possibly mismatched or conflicting entries in them. Only down-side I can see from that would be the loss of the ability to control access to certain environments per server. For example, your dev/test server may not have production tns entries and vice versa to prevent accidental cross-contamination.

As to the names you use for the various connections, definitely name them after the environment they connect to, even when you may think it would be "obvious". If you are connecting to the xxxxx instance from the production server, you may know that "xxxxx" on that server is a production entry but if it is named "xxxxx-prod" there's no doubt about what is what. Sure, that does mean it is something you need to parameterize in every job that connects to Oracle but that's something you should be doing regardless for schema / password so adding one more would be painless.

Now... all that being said... I could see using the same name for a tnsname entry across environments (and not parameterized in the job) if your projects are all on separate servers and you want to lock people to the instance matched to the current environment - dev to dev, test to test, etc.

My 2.875 cents. YMMV.

[narasimha]

Valuable suggestions... Thanks Craig!
I miss walking up to you for my questions