

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

I work for a company where we build enterprise applications, and we maintain three environments: dev, stage and prod.

The meaning of dev is intuitive: it's the environment used during development of the application.

What's the difference between stage and production environments?

share|improve this question
up vote 71 down vote accepted

For smaller companies (it's not clear how big yours is), three environments (dev, stage, production) are common. Larger companies will often have a QA environment between dev and stage.

These normally break down as follows:

dev: Working code copy. Changes made by developers are deployed here so integration and features can be tested. This environment is rapidly updated and contains the most recent version of the application.

qa: (Not all companies will have this). Environment for quality assurance; this provides a less frequently changed version of the application which testers can perform checks against. This allows reporting on a common revision so developers know whether particular issues found by testers has already been corrected in the development code.

staging: This is the release candidate, and this environment is normally a mirror of the production environment. The staging area contains the "next" version of the application and is used for final stress testing and client/manager approvals before going live.

production: This is the currently released version of the application, accessible to the client/end users. This version preferably does not change except for during scheduled releases.

share|improve this answer
This is right in terms of the software. There is also the data: dev and qa are connected to test databases so the developers and testers don't have to worry about introducing changes, while staging and production use production databases. Think of a bank. – Juan Lanus Jul 19 '13 at 11:58
There is another dimension: who are the users? dev: the developers; qa (I prefer qc): the testers; staging and production: actual users. In business applications with mean databases, the developers are not allowed to see let alone touch production databases, they are furnished with anonymized versions. – Juan Lanus Jul 19 '13 at 12:05
@JuanLanus: Usually, the staging environment will use a copy of production data - you typically don't want to change production data from staging. – sleske Sep 6 '14 at 21:40
@JuanLanus: Sorry, I meant "you do not want edits in the staging environment to be visible in the prod environment" - hence staging uses a copy of production data, but (typically) an editable copy. – sleske Sep 8 '14 at 7:15
We call qa 'test': dev (me), test (team), staging (client), prod (world) – Rudie Oct 18 '14 at 12:36

I am a bit surprised that a test environment is not present as well, as a location for code to go to before being promoted to staging.

To answer the question:

A stage environment should mirror the production environment as closely as possible.

It is used for verification of deployment procedures - making sure that when code is production ready it can be deployed without causing problems.

That is, code goes to staging - this is comprehensively tested and regressed to ensure that deployment went as planned (and to iron out any issues if it didn't).

share|improve this answer
Exactly - it exists to take code out of the dev environment into a more controlled environment, among other things, showing up any dependancies missed in documentation, and any 'well it worked on our machine' embarrassment on the live/prod environment. – Danny Staple Nov 4 '11 at 23:40

The stage environment is a preprod environment that mirrors production. Often, it may have some production data so that a test group composed of actual users and QA testers can confirm that the pre-released code base/data will deploy and work properly in a prod-like environment, usually through scripted use cases and regression tests.

As @Oded notes, it's usually common to have a QA environment that QA testers use to test the code.

share|improve this answer

My experience with US Government/Department of Defense IT is that:

  1. DEVELOPMENT/TEST is for developers and application developers. They build and test applications away from enterprise systems.
  2. When the applications are completed, they will be deployed to the IT environment into the PACKAGING server(s).
  3. From that point on, the applications are supported by IT, migrated into STAGING (which enables IT to develop/check implementation guidelines, configurations, etc.). User testing may happen at this stage to some degree to verify that the application will function as expected in a system that replicates PRODUCTION.
  4. If all of the test plans are completed and they are good to go the application will be moved to PRODUCTION and go into the sustainment (i.e., operations and maintenance, or O&M) mode.
  5. New updates from the developers will also be deployed into PACKAGING and the process continues.
share|improve this answer
Welcome to Programmers. Our site focuses on high quality questions and answers. It's not like typical forums. Please have a look over the help center for more information. I don't see how your answer addresses any points that haven't already been made by other answers to this question. – GlenH7 Oct 8 '13 at 14:04

Your Answer


