Blue-Green Deployment Planner

Traffic path visual unavailable.

Routing surface:

Weighted routes create waves; a plain Service selector creates one atomic switch.

Service name:

Shown in the release brief, exports, and command drafts.

Current environment:

For example, blue, stable, or production.

Target environment:

The current and target names must be different.

First target shift:

A smaller first share limits initial exposure when the route supports weights.

Shift increment:

The final wave is capped at 100% target traffic.

Bake interval:

A bake under 10 minutes is flagged for review.

min

Metric lag:

Added to every wave interval.

min

Pre-warm time:

Applied before the first production wave.

min

Baseline traffic:

Used only for modeled target-request exposure.

req/min

Target capacity:

Below 100% creates a capacity hold cue.

% peak

Health checks:

Use one check per line; include readiness, errors, latency, saturation, and a user-path signal.

Rollback trigger:

The draft should be clear enough for an on-call operator to act without debate.

Route target:

Generated commands still contain review placeholders for account-specific identifiers.

Old-environment hold:

A hold under 30 minutes is flagged for review.

min

DNS TTL override:

Zero adds no TTL-based caution and leaves provider behavior outside the estimate.

sec

Sticky-session estimate:

Zero is neutral; above 20% creates a traffic-observation caution.

Promotion gate:

This labels the checklist owner; it does not approve or execute a deployment.

{{ releaseBriefText }}

Wave	Elapsed	Target	Current	Target requests	Gate	Copy
{{ row.wave }}	{{ formatDuration(row.elapsed_minutes) }}	{{ formatPercent(row.target_percent) }}	{{ formatPercent(row.current_percent) }}	{{ formatInteger(row.exposure_requests) }}	{{ row.gate }}

Gate	Signal	Threshold	Action	Copy
{{ row.gate }}	{{ row.signal }}	{{ row.threshold }}	{{ row.action }}

The chart renderer is unavailable. The same traffic rows remain available in the shift schedule.

{{ commandText }}

Two production environments buy a release team one valuable option: a fast return to the version that was already serving users. The current environment, often called blue, stays available while the target environment, often called green, is prepared and tested. Production routing then moves from one to the other.

Blue-green describes the environments, not the traffic pattern. A router that supports weights can expose the target in measured waves. A plain service selector usually performs one atomic switch. Weighted Domain Name System (DNS) routing can appear gradual at the provider while resolvers and clients continue using cached answers. The release schedule must reflect the routing surface that will actually carry traffic.

Blue-green routing choices and their main planning concerns
Routing choice	Shift shape	Main concern
Load balancer weights	Gradual	Target health, connection draining, and session stickiness
Weighted DNS	Gradual at the authority	Time to live and resolver-cache lag
Service mesh or ingress	Gradual	Route precedence, retries, subsets, and outlier policy
Service selector	Atomic	A complete preview and one decisive rollback switch

A traffic percentage is only an exposure estimate. Ten percent of 100 requests per minute and ten percent of 100,000 requests per minute have very different blast radii. Session affinity can also make observed traffic diverge from configured weights. Release judgment therefore needs request volume, error and latency checks, business outcomes, and enough observation time for delayed failures to appear.

Bake time is the deliberate pause after a shift. Metric lag is additional time needed for logs, traces, counters, or batch-derived signals to become trustworthy. Promotion should wait for both. A short clean interval can be false reassurance when the monitoring window has not caught up.

The old environment remains useful only while it is healthy, deployable, and compatible with data written by the new version. Database migrations, queued work, caches, and one-way data transformations can make a routing rollback incomplete. Blue-green planning should name those limits before the first production request moves.

How to Use This Tool:

Start with the real routing surface because it decides whether the release can use weighted waves or must make one atomic switch.

Choose the Routing surface, then name the service, current environment, and target environment exactly enough for the release brief. The two environment names must differ.
For a weighted route, set the first target share and increment. For a Kubernetes Service selector, treat the generated 100% switch as atomic rather than relying on the percentage fields.
Set the Bake interval, Metric lag, and Pre-warm time. The schedule adds bake and lag to every production wave and applies pre-warm once before traffic moves.
Enter baseline requests per minute and target capacity. These values model target exposure and flag capacity below 100% of expected peak.
Write measurable health checks and a rollback trigger. Include readiness, errors, latency, saturation, and a user-path or business signal when those checks exist.
A blank rollback trigger or fewer than three health checks increases the review score. Generated route commands do not replace an agreed stop condition.
Review the shift schedule, gate checklist, and route commands with the operator who will run the release. Replace every command placeholder and verify the real account, region, namespace, route, and identifier before execution.
Keep the old-environment hold long enough for drains, delayed jobs, and rollback confidence. Record the selected approval owner before 100% promotion or teardown.

Interpreting Results:

The reported plan horizon combines pre-warm time, every wave interval, and the old-environment hold. The modeled request count is cumulative target exposure across the scheduled waves, not a prediction of unique users or successful requests.

Risk bands summarize only the declared planning checks. Ready path means no listed caution raised the score to 18. Scores from 18 to 39 are watch closely, 40 to 69 are cautious rollout, and 70 or more means hold for review. These bands do not approve a deployment.

Treat any “Hold” gate, capacity shortfall, missing rollback trigger, or routing mismatch as a stop. For DNS, confirm real cache behavior. For a service selector, verify the target through a preview path before the atomic switch.

Technical Details:

A weighted schedule starts at the chosen first target percentage, adds the fixed increment, and caps the final wave at 100%. Duplicate rounded percentages are removed. An atomic service-selector route instead contains one 100% production wave.

Formula Core:

Each weighted wave holds for the bake interval plus the observation lag. With P pre-warm minutes, B bake minutes, L lag minutes, and N waves, full target traffic is scheduled at:

T_{shift} = P + N \times (B + L)

The total plan adds the old-environment hold H. Exposure uses baseline requests per minute q and target share w for each wave. A zero-minute interval is modeled as one minute so exposure does not collapse to zero:

T_{plan} = T_{shift} + H

E = q \times \max (1, B + L) \times \sum_{i}^{N} \frac{w_{i}}{100}

Request exposure is not rounded during calculation. Display formatting may show a whole request count.

Rule Core:

The risk score is the sum of triggered review points, capped at 100. Boundary checks are inclusive where the table says “at least” and strict where it says “over” or “under.”

Blue-green planning risk rules
Condition	Points	Meaning
Fewer than 3 health checks	18	Guardrails are too thin
Rollback trigger is blank	24	No measurable stop condition
Target capacity under 100%	30	Target is below expected peak
Bake under 10 minutes	14	Delayed failures may not settle
First weighted shift over 25%	12	Larger initial blast radius
Increment over 50% with more than 2 waves	10	Useful observation points may be skipped
DNS TTL exceeds both 60 seconds and the bake duration	12	Caches may outlast the comparison window
Sticky-session estimate over 20%	10	Observed shares may diverge from weights
Old-environment hold under 30 minutes	8	Rollback capacity may disappear too soon
Selector route configured as a partial shift	16	The selected route is atomic

The command draft changes by route: weighted load balancer, weighted DNS, service mesh, or Kubernetes Service selector. It sanitizes names into command-safe tokens but does not validate credentials, resource existence, provider support, or production policy.

Limitations and Accuracy Notes:

The risk score and exposure count are transparent planning heuristics used here, not vendor approval or an observed production forecast.
Configured traffic weights may differ from observed requests because of low volume, caching, retries, long-lived connections, or session affinity.
The model does not evaluate schema compatibility, data migration reversibility, queue consumers, background jobs, cache state, or regional failover.
Generated commands are review drafts with placeholders. Test the exact provider syntax and rollback path before the release window.

Worked Examples:

Six-wave weighted release

A 10% first shift with 20-point increments produces 10%, 30%, 50%, 70%, 90%, and 100% waves. With 15 minutes of pre-warm, a 30-minute bake, 5 minutes of metric lag, 4,200 requests per minute, and a 60-minute hold, full target traffic arrives after 225 minutes, the plan horizon is 285 minutes, and modeled target exposure is 514,500 requests. Those values describe the schedule only; every health gate still has to pass.

References:

Introduction to Blue/Green Deployments on AWS, Amazon Web Services.
Amazon ECS blue/green service deployment workflow, Amazon Web Services.
How to run a blue-green deployment cutover with HAProxy, Simplified Guide.