What are deployment environments (dev, staging, production)?

Question

Accepted Answer

Software is typically deployed through multiple **environments** — like **development**, **staging**, and **production** — each serving a purpose in the path from code to live users. Promoting code through environments catches issues before they reach real users.

## The typical environments

```text
DEVELOPMENT (dev) → where developers build and test (local or a shared dev environment);
  unstable, frequent changes, experimentation
STAGING (test/QA/pre-prod) → a PRODUCTION-LIKE environment for final testing:
  → mirrors production (same config/infrastructure as closely as possible)
  → run integration/E2E tests, QA, UAT before releasing
  → catch issues in a safe, prod-like setting BEFORE real users see them
PRODUCTION (prod) → the LIVE environment serving real users:
  → stability is critical; changes are careful and monitored
```

## Promoting through environments

```text
Code flows through environments, gaining confidence at each:
  dev → staging → production
  → tested in dev, verified in prod-like staging, then released to production
  → each environment is a GATE catching issues before the next
→ CI/CD pipelines AUTOMATE this promotion (deploy to staging, then prod).
```

## Why multiple environments?

```text
✓ Catch issues BEFORE production (test in staging, not on real users)
✓ ISOLATION — experiment/break dev without affecting production or users
✓ Realistic testing — staging mirrors prod (catch environment-specific issues)
✓ Controlled releases — promote verified code through stages
→ Each environment should be as consistent as possible (config via env vars, IaC).
```

## Why it matters

Understanding deployment environments is valuable because the practice of promoting code through multiple environments is fundamental to safe software delivery, so it's useful practical knowledge.

The typical environments — **development** (where developers build and experiment, unstable and frequently changing), **staging** (a **production-like** environment for final testing, QA, and verification), and **production** (the live environment serving real users, where stability is critical) — each serve a distinct purpose in the path from code to users.

Understanding **promoting code through environments** (code flowing dev → staging → production, gaining confidence at each stage, with each environment acting as a gate catching issues before the next, and CI/CD pipelines automating this promotion) is the key practice.

Understanding **why multiple environments matter** is important: they **catch issues before production** (testing in staging rather than on real users — protecting the live experience), provide **isolation** (experimenting and breaking things in dev without affecting production), enable **realistic testing** (staging mirroring production to catch environment-specific issues that wouldn't appear in dev), and support **controlled releases** (promoting verified code through stages).

The principle that **staging should closely mirror production** (so testing there is realistic and catches prod-specific issues) and that environments should be consistent (configuration via environment variables and Infrastructure as Code) reflects good practice.

Since safe software delivery depends on testing and verifying code before it reaches real users, and since the multi-environment model (dev for building, staging for prod-like verification, production for live) with controlled promotion is the standard practice for this, understanding deployment environments is valuable, practically-relevant knowledge for software delivery — a fundamental practice that protects production users by catching issues in earlier environments, and core knowledge for how software safely progresses from development to live use.