What Is Blue-Green Deployment?
Learn how blue-green deployment works — two full environments, instant traffic cutover, and instant rollback — with a DevOps interview answer.
Expected Interview Answer
Blue-green deployment is a release strategy that maintains two identical, fully provisioned production environments — blue (currently live) and green (the new version) — and switches all live traffic from blue to green at once via the router or load balancer, only after green has been fully tested.
The green environment is provisioned with the new application version and validated with smoke tests and health checks while it receives zero real user traffic, so there is no partial exposure of an unverified release. Once green passes validation, a load balancer, DNS change, or router configuration flips all traffic to green instantly, and blue is kept running idle as an immediate rollback target — if problems surface, traffic is flipped straight back to blue with near-zero downtime. The main cost is that both environments must run simultaneously during the cutover window, doubling infrastructure for that period, and any database schema changes must remain backward-compatible with both versions until blue is decommissioned. Blue-green is best suited for releases where instant, reliable rollback matters more than gradually validating against a slice of real production traffic.
- Near-zero-downtime cutover between versions
- Instant rollback by flipping traffic back to the old environment
- New version is fully tested before receiving any real traffic
- Simple mental model compared to gradual traffic-splitting strategies
AI Mentor Explanation
Blue-green deployment is like a team having a fully padded-up substitute eleven waiting in the dressing room, completely rehearsed and ready, while the current eleven finishes the innings on the field. At the change of innings, the captain sends out the entire substitute eleven at once instead of swapping players one by one mid-over. If the new eleven struggles badly, the captain can send the original eleven back out for the next session immediately. The switch itself is instantaneous — there is no in-between state where both elevens share the field.
Step-by-Step Explanation
Step 1
Provision the green environment
Stand up a full copy of production infrastructure with the new application version deployed.
Step 2
Validate in isolation
Run smoke tests and health checks against green while it receives zero real user traffic.
Step 3
Cut over traffic
Flip the load balancer, router, or DNS so all live traffic now hits green instantly.
Step 4
Keep blue as rollback
Leave blue running idle; if issues surface, flip traffic straight back to blue with near-zero downtime.
What Interviewer Expects
- Understanding that both environments are fully provisioned before cutover
- Awareness that traffic switches all at once, not gradually
- Knowledge of the instant-rollback benefit by flipping back to blue
- Ability to mention the double-infrastructure cost and schema-compatibility caveat
Common Mistakes
- Confusing blue-green with canary, which shifts traffic gradually
- Forgetting that database schema changes must stay compatible with both versions during cutover
- Not accounting for the temporary doubled infrastructure cost
- Assuming blue can be decommissioned immediately instead of kept as a rollback target
Best Answer (HR Friendly)
“Blue-green deployment means we keep two full copies of production running — the current live version and the new version fully tested and ready — and we switch every user over to the new one in a single instant flip. If something goes wrong, we can flip straight back to the old version in seconds, which makes it a very safe way to release with minimal downtime, at the cost of briefly running double the infrastructure.”
Code Example
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp
version: green # flip from “blue” to “green” to cut over instantly
ports:
- port: 80
targetPort: 3000
# Rollback: flip the selector back to “blue”
# kubectl patch service myapp -p '{"spec":{"selector":{"version":"blue"}}}'Follow-up Questions
- How do you handle a database migration safely during a blue-green switch?
- How long would you typically keep the old (blue) environment running after cutover?
- What monitoring would you check immediately after flipping traffic to green?
- How does blue-green compare to canary release in terms of blast radius?
MCQ Practice
1. In blue-green deployment, when does the green environment first receive real user traffic?
Green is fully tested in isolation with zero real traffic, then all traffic is switched over in a single cutover.
2. What is the primary rollback mechanism in blue-green deployment?
Because blue is kept running idle after cutover, rollback is as fast as flipping traffic back to it.
3. What is a key infrastructure cost of blue-green deployment?
Blue and green both run fully provisioned at the same time until blue is decommissioned after a successful cutover.
Flash Cards
What is blue-green deployment? — Running two full environments and switching all traffic instantly from old to new.
How does rollback work in blue-green? — Flip the router/load balancer back to the still-running old (blue) environment.
Main cost of blue-green? — Both environments run simultaneously during cutover, temporarily doubling infrastructure.
Key caveat for database changes? — Schema changes must stay backward-compatible with both versions until blue is decommissioned.