Environment naming standards in software development?

Question

My project is currently suffering from environment naming issues. Different people have different assumptions as to what environments should be named or what the names designate, and it's causing confusion when discussing them. I've done a bit of research and I haven't found any standards out there.

The terms include "Local", "Sand", "Dev", "Test", "User", "QA", "Staging" and "Prod" (plus a few more that different people have asked about)

I'm not looking for just opinions, though if there's one out there that "everyone" has I'll take it - I'm trying to find definitions advanced by some sort of authority, even if it's unofficial.

Here's the environments we currently use:

1. Environment on the developer's PC
2. Shared Environment where developers directly upload code to self-test
3. Shared Environment where standards and functionality are tested by QA people
4. Shared Environment where completed and QA-checked code is approved by project requesters
5. Environment that mirrors the final environment as a final check and to prepare for deployment
6. Final Environment where code is in use

I know what I'd call them, but is there some sort of standard on this? Thanks in advance.

Answer 1

There not only is not a fixed standard, but there really isn't a fixed pattern. The dependencies between what you are building and the scale at which you can afford to replicate it are going to dictate what this has to look like from one sort of project to another.

I have worked with as few as one environment and as many as 13.

In the sequence you describe I would usually see them named them something like

1. local or dev if you don't use dev in the next step
2. dev or integration if this is the first deploy after merges
3. test or QA
4. uat or acceptance or QA if you didn't use QA in step 3
5. pre-prod, staging or performance if it a performance step for final sign-off
6. prod

My advice would be to agree on the names, purposes and criteria to enter and leave each for every product or per project then when you realize you need a 7th environment or only need 5 in one case for some other reason in the future discuss again with the team.

If you have team members that are getting hung up on the semantics of the names you can always just drop the names and refer to them as prod minus six through prod minus one with one manager that simply refused to let his QA staff test on an environment that was not named "QA"

If you are looking to name the servers themselves I usually suggest naming them by who's authority they are under. Usually this goes something like:

• dev machines can be manipulated by developers
• QA machines cannot be manipulated by developers but are also not monitored by production support
• prod machines are prod support's business

most people end up using those sorts of names as prefixes or suffixes so that you have a chain like "devsqllweb" "qasqlweb" "prodsqlweb" or something like that.

Answer 2

There is no fixed definition. There are a few that are used by common practice (which you have listed). If you want to give each environment the name of a character in Toy Story, you can (will not recommend it, though).

What I would do is create a glossary for the company, in which we would give the names that we would want to use.

Answer 3

I guess coming from a more structured, regulated industry the option of naming a server is a luxury I don't have. Our servers are named according to our company IT policy - so the actual hostname of the machine is not something we can control.

What we have done is gone the route of DNS names and aliases. The rule is the first letter identifies the general role of the server in the development process (the zone)

• p = production
• d = development
• s = staging
• t = testing

Then we have a max three letter name to identify the role of the machine

• app = application
• db = database
• web = frontend/web
• kas = caching

Following by a numeral if there are multiple machines in that zone. We publish this on the internal documentation server and provide it as part of any new documentation for projects and during the bootstrapping stage.

These are for those servers that are part of the development process. For support machines we have a more liberal policy; and when we have to provision a new auxilliary server we ask development teams to come up with a name that they prefer.

This has lead to some interesting ones, my two favorites ones are cerberus (internal proxy) box and hades (documentation server/intranet)

I'm sure this is not some best practice, but this is what we use and it works for us.