Blue-Green Deployment
A blue-green deployment keeps the current and new versions in separate environments. Traffic switches after the new environment is checked.
blue active + green ready -> validate -> switch traffic -> observe -> retire or switch backlive 100%GREEN · v2preview readyhealth + smoke ✓→blue active + green ready -> validate -> switch traffic -> observe -> retire or switch backOPSAnother example
Blue serves checkout traffic. Green runs version 2 and passes checks. Routing switches to green while blue stays ready for return.
Main parts
- 01Active environment
- 02Preview environment
- 03Matching settings and capacity
- 04Pre-switch checks
- 05Traffic switch
- 06Observation and return window
Use it when
Use it when two environments fit the budget and a fast traffic switch matters. Plan checks, capacity, switching, observation, and return.
Do not use it when
Do not promise zero downtime or easy database rollback. Routing delays, long connections, and incompatible data changes can still break the switch.
Name used in code
blue active + green ready -> validate -> switch traffic -> observe -> retire or switch back Before you ship
Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.
Outcome: Use Blue-Green Deployment to release or recover the change safely, with a clear record. User context: Blue serves checkout traffic. Green runs version 2 and passes checks. Routing switches to green while blue stays ready for return. Delivery concept or operation: Blue-Green Deployment. Why it fits: Use it when two environments fit the budget and a fast traffic switch matters. Plan checks, capacity, switching, observation, and return. Do not use it when: Do not promise zero downtime or easy database rollback. Routing delays, long connections, and incompatible data changes can still break the switch. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.
Check this request
Review the current use of Blue-Green Deployment. Definition: A blue-green deployment keeps the current and new versions in separate environments. Traffic switches after the new environment is checked. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.