Blue-Green Deployment Strategy Analysis Prompt

This prompt is for infrastructure and platform engineers who need a structured, risk-focused review of a proposed blue-green deployment design before it reaches production. The job-to-be-done is not to generate a deployment script, but to surface hidden failure modes—environment parity gaps, DNS TTL misconfigurations, session draining race conditions, and rollback time SLA violations—that turn a clean cutover into an outage. Use this prompt when you have a concrete deployment architecture document, runbook draft, or infrastructure-as-code definition and you need an adversarial review that assumes things will break at the worst possible moment.

The ideal user brings a written design artifact: a network topology diagram, a load balancer configuration, a database replication plan, and a rollback procedure. The prompt works best when you supply [DEPLOYMENT_ARCHITECTURE] as structured text describing environment pairs, traffic routing, data synchronization, and cutover triggers. Do not use this prompt for greenfield architecture selection (use the Deployment Strategy Trade-Off Decision Prompt instead), for runtime incident response (use an operational runbook prompt), or when the team has not yet agreed on basic deployment requirements. The prompt is an analysis tool, not a decision-maker—it identifies risks but does not choose your strategy for you.

Before running this prompt, confirm that you have documented the current state and target state environments, the traffic cutover mechanism, the data replication approach, and the rollback trigger conditions. If any of these are missing, the analysis will produce low-confidence results filled with assumptions rather than evidence-backed findings. After receiving the output, treat every identified risk as a prompt for further investigation, not a blocker. The next step is to take the top three severity findings and design specific mitigations before proceeding to a dry-run or tabletop exercise.

This prompt template is designed to produce a structured analysis of a blue-green deployment strategy. It evaluates environment parity, data synchronization, session draining, rollback time SLAs, and common failure modes such as DNS TTL misconfiguration and connection pool exhaustion. The template uses square-bracket placeholders that you replace with your specific deployment context before sending it to the model.

textCopy
You are a site reliability engineer reviewing a blue-green deployment strategy.

Analyze the following deployment design and produce a structured review.

## Deployment Context
[SYSTEM_DESCRIPTION]

## Environment Specifications
- Blue Environment: [BLUE_ENV_DETAILS]
- Green Environment: [GREEN_ENV_DETAILS]
- Traffic Routing: [ROUTING_MECHANISM]

## Review Criteria
Evaluate each area below with a finding, risk level (Low/Medium/High/Critical), and specific recommendation.

1. **Environment Parity**: Are blue and green environments identical in configuration, dependencies, and infrastructure? Check for drift in OS versions, library versions, environment variables, and infrastructure-as-code state.

2. **Data Synchronization**: How is data kept consistent between environments during cutover? Evaluate replication lag, stateful service handling, and database migration compatibility.

3. **Session Draining**: How are in-flight requests and user sessions handled during cutover? Check for connection draining timeouts, sticky session behavior, and long-lived connection handling.

4. **Rollback Time SLA**: What is the measured or estimated time to roll back? Evaluate whether the rollback procedure meets the stated SLA of [ROLLBACK_SLA]. Check for manual steps that could extend recovery time.

5. **DNS and Traffic Routing**: Review TTL settings, propagation delays, and client-side caching behavior. Flag any TTL values above [MAX_DNS_TTL] seconds as risks for delayed cutover or rollback.

6. **Connection Pool Exhaustion**: Assess whether connection pools in load balancers, application servers, and database clients are sized for simultaneous connections to both environments during cutover. Check for hard limits that could cause connection storms.

7. **Health Check Design**: Evaluate the health check endpoints used for cutover decisions. Are they deep enough to catch application-level failures, or do they only check process liveness?

8. **Automated vs Manual Steps**: Identify every manual step in the cutover and rollback process. For each, assess the risk of operator error and recommend automation where feasible.

## Output Format
Return a JSON object with this schema:
{
  "overall_risk_level": "Low|Medium|High|Critical",
  "summary": "One-paragraph executive summary of findings",
  "findings": [
    {
      "area": "string",
      "risk_level": "Low|Medium|High|Critical",
      "finding": "string",
      "recommendation": "string",
      "requires_human_review": boolean
    }
  ],
  "critical_issues": ["string"],
  "rollback_feasibility": "string",
  "recommended_actions_before_cutover": ["string"]
}

## Constraints
- If any finding is Critical, set overall_risk_level to Critical.
- Flag any manual rollback step that exceeds [ROLLBACK_SLA] as Critical.
- If DNS TTL exceeds [MAX_DNS_TTL], flag as High or Critical depending on rollback SLA.
- Do not fabricate metrics. If information is missing, note it as an unknown risk.
- Recommend human review for any finding rated High or Critical.

To adapt this template, replace each square-bracket placeholder with your actual deployment details. For [SYSTEM_DESCRIPTION], include the service name, traffic volume, and criticality. For [ROLLBACK_SLA], use your team's committed recovery time objective in seconds. For [MAX_DNS_TTL], set a threshold appropriate to your infrastructure—typically 60 seconds or less for fast cutover. If your deployment uses a service mesh or API gateway for traffic shifting instead of DNS, modify the DNS section to evaluate the actual routing mechanism. The output schema is designed for programmatic consumption, so wire the JSON response into your deployment pipeline's approval gate or risk register.

This prompt is designed to be called programmatically as part of a deployment readiness check or architecture review pipeline. The primary integration point is a CI/CD system (such as GitHub Actions, GitLab CI, or Jenkins) that triggers the prompt when a deployment plan is submitted for review. The prompt expects structured input describing the proposed blue-green cutover design, and it returns a structured analysis that downstream systems can parse, log, and act on. Because the output includes risk assessments and failure mode checks, the harness must treat the model's response as advisory input to a human reviewer, not as an autonomous gate decision.

Input assembly is the first integration concern. Collect the required [DEPLOYMENT_DESIGN] from your infrastructure-as-code definitions, runbooks, or architecture decision records. Map these to the prompt's placeholders: environment topology (hostnames, DNS TTL values, load balancer configs), data synchronization strategy (replication lag tolerances, state transfer procedures), session draining approach (connection draining timeouts, sticky session handling), and rollback time SLA. If your organization maintains a service catalog or CMDB, query it to populate the [CURRENT_STATE] placeholder with accurate infrastructure details rather than relying on manual description. Model selection matters here: use a model with strong reasoning capabilities (GPT-4, Claude 3.5 Sonnet, or equivalent) because the analysis requires multi-step causal reasoning about failure propagation. Avoid smaller or faster models that may miss subtle interaction effects between DNS TTL, connection pooling, and session state.

Validation and retry logic should be built into the harness. Parse the model's output against the expected schema (a JSON object with sections for environment parity, data sync, session draining, rollback, and overall risk). If the output fails schema validation, retry once with the validation error appended to the prompt as feedback. If the second attempt also fails, log the failure and escalate to a human reviewer with the raw output attached. Logging and audit trails are critical: store the full prompt, model response, validator results, and reviewer decision in an immutable log. This supports post-deployment incident review and demonstrates due diligence for compliance purposes. Include the model version, timestamp, and any retry attempts in the log record.

Human review integration is the most important harness decision. The prompt's output should be surfaced in a pull request comment, a deployment approval dashboard, or an architecture review tool (such as a lightweight ADR system). Present the analysis alongside the deployment plan so reviewers can compare the model's identified risks against their own assessment. The harness should require explicit human approval before the deployment proceeds—do not automate the gate decision based solely on the model's risk score. For high-risk environments (production, regulated systems), consider a two-person review rule where the model's analysis is one input among multiple. Tool use can extend the harness: if your infrastructure is defined in Terraform or Pulumi, a tool can extract the actual DNS TTL values, health check configurations, and load balancer settings to ground the analysis in live configuration rather than documentation that may be stale. Similarly, a tool that queries your observability platform for recent connection pool metrics or replication lag data can provide the prompt with current operational evidence.

What to avoid: Do not use this prompt as a replacement for load testing, chaos engineering, or actual cutover rehearsals. The model identifies design-level risks but cannot simulate runtime behavior. Do not skip the human review step for production deployments—the prompt's analysis is a forcing function for thorough review, not a substitute for engineering judgment. Do not feed the prompt sensitive credentials, connection strings, or internal hostnames that would expose your infrastructure in model provider logs unless you are using a private deployment. Finally, test the harness end-to-end with a known-bad deployment design (deliberately broken DNS TTL, missing session draining) to verify that the prompt catches the issues and the review workflow surfaces them correctly before you rely on it for real deployments.