Operations → Deployment
Environment
A named, isolated execution context with its own configuration, data, credentials, dependencies, and infrastructure for a stage of software delivery.
What an environment is
An Environment is a named execution context with its own configuration, data, credentials, dependencies, and infrastructure. Environments separate work by purpose and risk so that changes can be built, tested, approved, and operated without unintentionally affecting production.
Common environments
- A Local Environment is controlled by an individual developer.
- A shared Development Environment supports early integration.
- A QA Environment supports functional, integration, regression, and exploratory testing.
- A general Test Environment is prepared for automated or manual verification.
- A UAT Environment lets business users or product representatives perform User Acceptance Testing.
- A Staging Environment, also called a Pre-Production Environment, closely resembles production and supports release rehearsals.
- The Production Environment serves real users and business workloads.
- A Sandbox Environment isolates experiments and external integration work.
- A Preview Environment, often an Ephemeral Environment, is created temporarily for a branch or pull request.
Environment parity
Higher confidence comes from keeping environments similar in topology, runtime versions, deployment mechanisms, and configuration shape. Exact parity is not always economical, but important differences should be explicit and tested.
Data and access
Non-production environments should not casually copy sensitive production data. Use synthetic, anonymized, or carefully controlled datasets. Credentials and permissions should be isolated per environment, with production access governed more strictly.
Promotion and deployment
A delivery pipeline usually promotes the same immutable artifact through environments while changing environment-specific configuration. Rebuilding different binaries for each environment makes traceability and rollback harder.
Common mistakes
- Treating QA and UAT as synonyms: QA verifies software quality, while UAT validates business acceptance.
- Allowing staging to drift far from production.
- Sharing credentials or databases across environments.
- Keeping long-lived environments full of hidden manual changes.
- Assuming more environments always create more confidence; each environment adds cost and operational complexity.