Environment Strategy

Environment strategy defines how code, configuration, data, and risk move from development to production. Keep environments boring, repeatable, and clearly owned.

Environment model

Prefer a small set of durable environments plus short-lived preview environments where useful.

Durable environments

Use durable environments when teams need shared integration points, realistic network controls, or production-like validation.

• Keep infrastructure defined as code.
• Keep configuration environment-specific but schema-consistent.
• Use production-like identity, network, and observability controls.
• Restrict production data copies and require sanitization when copied.
• Make drift visible through deployment and infrastructure checks.

Preview environments

Use preview environments for pull requests, feature branches, and short-lived validation.

• Create them automatically and destroy them automatically.
• Scope credentials and data to the preview lifetime.
• Avoid shared mutable dependencies when tests need isolation.
• Cap cost with quotas, TTLs, and cleanup alerts.
• Publish URLs and diagnostics back to the pull request.

Promotion model

Prefer promoting immutable artifacts over rebuilding the same commit for each environment. Rebuilding can be acceptable for simple apps, but it must produce traceable artifacts with equivalent inputs.

Every promotion should record:

• Source commit and artifact digest.
• Environment, approver or automated gate, and timestamp.
• Configuration version and deployment strategy.
• Verification result and rollback target.