Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Jun 26 '12 at 14:19

This question came from our site for professional and enthusiast programmers.

    
Thanks. I wasn't aware of that SE. I knew it didn't belong on ServerFault or SuperUser, but I've never heard of programmers.se before. –  Marcus_33 Jun 26 '12 at 13:21
    
I flagged it for a move, so ideally it should find it's way to the right site. –  Ricardo Altamirano Jun 26 '12 at 13:22
    
Depending on scope of project, you may have fewer or more environments. –  Yusubov Jun 26 '12 at 14:40

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer
    
You're basically stating the conclusion I came to. I was hoping there was some sort of standard out there so I could resolve the situation without setting essentially arbitrary standards. My problem lies in that our "main" environment structure has less environments than this project I'm working on (so I can't just mirror what we use normally) - and my project has a lot of consultants from various places, meaning no one has the same standards. I'll leave this question open for a few more hours to see if anyone else will chime in, but this is the answer I was afraid of. –  Marcus_33 Jun 26 '12 at 15:24
    
I have seen standards for this. They are the kind of standards that are either opinion or very specific to a certain situation unfortunately. –  Bill Jun 26 '12 at 15:47

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.