Dev, QA, Staging, Production: Environments Explained

Deployment environments are separate copies of your application, each with its own purpose, that code passes through on its way to users. The classic set is development, QA, staging and production. Each one catches a different kind of problem before your customers do.

The point is not ceremony. It is to make sure the first time code meets real conditions is not in front of a paying client.

The four common environments

Development (dev). Where developers integrate their work. It changes constantly and breaks often, and that is fine. Its job is to show whether separate pieces of work fit together.

QA (test). A stable environment for testers. Code arrives here when it is ready to be tested, and stays put while test runs happen. If dev is a workshop, QA is the inspection bench.

Staging (pre-production). As close to production as you can make it: same configuration, similar data, same infrastructure. This is where you rehearse the release itself, including database scripts, and where clients often do final acceptance.

Production (live). What real users see. Changes arrive only through a controlled release.

Some teams add more, such as a UAT environment dedicated to the client or a demo environment for sales. Others merge QA and staging. Fewer environments are fine as long as each step still has a clear purpose.

How code moves between them

Code should be promoted, not rebuilt. The same build that passed QA is the one that goes to staging and then production. Rebuilding at each step means you are shipping something slightly different from what you tested.

A typical promotion path:

1. Merge to main triggers a build and deploy to dev.
2. A release candidate is deployed to QA for a test run.
3. Once tests pass and the client signs off, the same build goes to staging.
4. The release checklist runs, and the build is deployed to production.

Pipelines automate most of this. Our guide to CI/CD explains how.

Shipping something soon? See how Flow turns releases into a checklist, not a gamble. Get started with Flow →

Common environment problems

• Drift. Staging slowly stops matching production, so "it worked on staging" means less and less.
• Mystery versions. Nobody knows which build is on QA right now, so testers report bugs that are already fixed.
• Shared data collisions. Two testers changing the same test record and confusing each other.
• Configuration surprises. A setting that exists in staging but not in production.

Most of these are visibility problems. If everyone can see what is deployed where, half of them disappear.

How Flow helps

Azure DevOps and GitHub both handle the mechanics of environments well. Azure Pipelines and GitHub Actions can deploy to named environments with approvals and protection rules. Flow focuses on the delivery view on top of that: which tickets are where, and who needs to know. Livex Flow offers:

• Environments with names and colours, so dev, QA, staging and production are instantly recognisable across the platform.
• A release planner per environment, with QA, live and hotfix releases tracked separately.
• Automatic pipeline run tracking from Azure DevOps and GitHub, plus manual deploys and a deployment wizard for the steps that are not automated.
• "Which build or release did this ticket ship in" on every ticket, which ends the mystery-version problem.

For the release side of the story, read release management.