Development, Staging, And Production Strategy

Separate environments reduce deployment risk. They should run the same application and broadly the same deployment shape while using distinct data, credentials, scale, and operational controls. The goal is not to make staging expensive. It is to catch release problems before real users meet them.

Separate Values From Code

  • Keep environment-specific values outside source code.
  • Use separate credentials and services.
  • Make staging realistic enough for release checks without copying sensitive production data casually.

Make Staging Useful

  • Document config differences.
  • Promote one tested artifact.
  • Verify migrations, jobs, logs, and rollback per environment.

Watch For Drift

  • Configuration drift makes staging misleading.
  • Shared credentials increase blast radius.
  • Production data in development creates privacy risk.

Environment Matrix

development: local services, synthetic data, verbose developer diagnostics
staging: production-like deployment shape, safe test data, release checks
production: restricted access, real traffic, monitored rollout, rollback ready

Document intentional differences. If a deployment succeeds in staging but fails in production, compare configuration, runtime versions, extensions, service connectivity, and process types before treating the failure as mysterious.

Promote One Artifact

Build one immutable release and promote that artifact through environments. Rebuilding separately for staging and production can introduce dependency, asset, or compiler drift after testing has completed.

Keep Data And Access Different

Production data should not be copied casually into development. Use generated or carefully anonymized fixtures, separate credentials, least privilege, and explicit access controls. Staging should resemble production architecture without pretending it has the same scale or sensitivity.

Configuration Matrix

Record runtime versions, extensions, database engine, cache, queue, mail, object storage, external-service modes, domains, TLS, logging, feature flags, and secrets ownership for every environment.

Promotion Evidence

A release should move forward only after automated checks, environment smoke tests, migration compatibility checks, health signals, and rollback readiness are visible.

Practice

Practice: Compare Environment Configuration

Prepare a small environment matrix for development, staging, and production. Mark which values must differ and which deployment behaviours should remain comparable.

Requirements

  • Keep environment-specific values outside source code.
  • Use separate credentials and services.
  • Make staging realistic enough for release checks without copying sensitive production data casually.
  • Document config differences.
  • Promote one tested artifact.
  • Verify migrations, jobs, logs, and rollback per environment.
Show solution

Keep source code and the promoted artifact the same across environments. Use distinct credentials, databases, caches, mail destinations, and external-service keys. Development can show verbose diagnostics; production should log failures without exposing details to users.

Staging should still exercise the serving runtime, migrations, workers, logs, health checks, and rollback path. Record intentional differences so a production-only failure can be investigated systematically.

Practice: Build An Environment Matrix

Create a matrix for local, CI, staging, and production covering runtime, services, credentials, data, outbound providers, and observability.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

Record the same categories for every environment, explain intentional differences, assign owners, and flag drift that can invalidate staging evidence.

Verify the real response, deployment, or workload rather than relying only on configuration text.

Practice: Promote One Artifact

Design a pipeline that builds once and promotes through staging and production.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

Validate source, build an immutable versioned artifact, deploy it to staging, run smoke and compatibility checks, approve, deploy the identical digest to production, then monitor and retain rollback metadata.

Verify the real response, deployment, or workload rather than relying only on configuration text.