Safe Deployments
Blue-Green Deployment Checklist
Plan blue-green releases with environment parity, database compatibility, traffic switching, session behavior and tested rollback evidence. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Build parity | Keep configuration, dependencies and infrastructure differences explicit between blue and green. |
| Prove compatibility | Validate database, queues, caches and external callbacks with both application versions. |
| Test the switch | Exercise routing, connection draining, sessions and DNS or load-balancer propagation. |
| Hold rollback capacity | Keep blue healthy until green passes a defined observation window. |
Starter snippet
deploy green -> verify privately -> shift traffic -> observe -> retire blueReview checks
- Use immutable release artifacts.
- Run synthetic and business smoke tests.
- Define a traffic-switch owner.
- Preserve logs and metrics for both colors.
Common mistakes
- Applying a destructive migration before the switch.
- Reusing stateful workers across colors blindly.
- Retiring blue immediately after one successful request.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Database Migration Rollback, Release Checklist For Developers, Application Health Check Guide.