Development Environment – Naming Standards in Software Development

development-environmentnaming-standards

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.

Best Answer

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.