Dev vs Staging vs Production: Environment Strategy

What each environment is actually for

Development (dev) is where individual developers test their changes before creating a pull request. It is frequently broken, frequently reset, and never used for customer-facing validation. Speed matters more than stability in dev — a developer should be able to deploy their branch, test it, and destroy it within minutes. Dev data is synthetic or a small anonymized subset. Dev exists for fast feedback, not quality assurance.

Staging is a stable environment that mirrors production in architecture and configuration. Integration tests, QA, user acceptance testing (UAT), and performance testing happen here. Staging must not be broken during business hours — if a deployment breaks staging, it is treated like a production incident in terms of urgency to fix. Staging data is production-like in shape but not real customer data (anonymized or generated). Staging catches the class of bugs that only appear when all services run together: integration failures, configuration errors, and environment-specific regressions.

Production is live, customer-facing infrastructure. No experimental changes, no direct developer write access, and all changes deployed through a controlled pipeline with approval gates. Production is the environment you are protecting. Every other environment exists to give you confidence before you touch production.

What staging must match in production

The value of staging comes from parity with production. If staging is different in important ways, bugs that staging would have caught slip through. These things must be identical between staging and production:

Infrastructure as code per environment

When you manage infrastructure with Terraform or Bicep, you need a strategy for handling multiple environments. Two common approaches:

Terraform workspaces. A single set of Terraform files, multiple workspaces (one per environment). Each workspace has its own state file. Variable values differ per workspace through .tfvars files. Simple to implement, but all environments share the same code structure. A change to the Terraform code affects all environments on the next apply.

# Create and use the staging workspace
terraform workspace new staging
terraform workspace select staging
terraform apply -var-file=staging.tfvars

# Switch to production
terraform workspace select production
terraform apply -var-file=production.tfvars

Separate state files with separate backends. The Terraform code is the same, but each environment uses a different backend configuration (different storage account container) for its state. This gives more isolation — a corrupted staging state does not affect production state. Many teams store state in separate storage accounts in separate subscriptions entirely.

# Initialize for staging (different backend)
terraform init \
  -backend-config="resource_group_name=rg-tfstate-staging" \
  -backend-config="storage_account_name=satfstatestaging001" \
  -backend-config="container_name=tfstate" \
  -backend-config="key=myapp.tfstate"

Environment promotion workflow

Promotion is the process of moving a validated artifact from a lower environment to a higher one. The workflow:

1. Developer creates a pull request. The CI pipeline builds the artifact and runs unit tests. If tests pass, the artifact is published.

2. On merge to main, the CD pipeline deploys the artifact to dev automatically. Automated smoke tests run. If they pass, the pipeline continues.

3. The pipeline deploys to staging. Integration tests and automated end-to-end tests run. The pipeline pauses for human approval.

4. After QA signs off in staging, a designated approver approves the production deployment in Azure DevOps.

5. The same artifact deploys to production. Post-deployment smoke tests verify the deployment. Monitoring dashboards are checked for error rate increases.

This is a linear promotion: dev → staging → production. The artifact never skips an environment. The only exception is hotfixes, which follow an expedited process with post-deployment review.

Feature flags as an alternative to environment promotion

Environment promotion gates features behind environment boundaries. Feature flags gate features behind runtime configuration switches, allowing the same code to be deployed everywhere while controlling which users see which features.

Azure App Configuration supports feature flags natively. Flags are stored in App Configuration and queried by the application at runtime. Flags can be toggled without redeployment, targeted to specific users or percentages of users, and scheduled to activate or deactivate at specific times.

Feature flags complement environment promotion — they do not replace it. Use environment promotion for infrastructure changes, configuration changes, and breaking changes. Use feature flags for gradual rollout of new application features after the code has already been deployed and validated in staging.

Data strategy across environments

Data is the hardest part of environment parity. Production has real customer data that cannot go into staging due to privacy regulations (GDPR, CCPA) and security requirements. Staging needs data that resembles production in shape and volume for realistic testing.

Approaches: synthetic data generation (use tools to create realistic-looking but fake datasets), data masking (copy production data and anonymize PII fields before importing to staging), and subset sampling (take a statistically representative 1% sample of production data, anonymize it, use in staging).

Database schema migrations need special attention across environments. Apply schema changes to staging first, validate application compatibility, then apply to production. Never apply a migration to production that has not first been validated in staging with a data set that resembles production schema and volume.