{"product_id":"blue-green-deployment-pipeline","title":"Blue-Green Deployment Pipeline","description":"\u003ch3\u003eBlue-Green Deployment Pipeline\u003c\/h3\u003e\n\u003cp\u003eMost teams say \"we do blue-green deployments\" when what they actually do is deploy the new version and hope it works. A real blue-green deployment requires two identical production environments, a traffic router that can switch between them in seconds, and a rollback procedure that has been tested — not just documented. At Lockheed Martin, our deployment pipeline for a classified system had a 30-second rollback requirement. The only way to meet it was to have the previous version already running and ready to receive traffic. This template implements the three most common deployment strategies with actual traffic management, health validation, and automated rollback.\u003c\/p\u003e\n\n\u003ch3\u003ePipeline Strategies\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eBlue-Green Deployment\u003c\/strong\u003e\n\u003cul\u003e\n\u003cli\u003eTwo identical environments: blue (current) and green (new). Both running simultaneously.\u003c\/li\u003e\n\u003cli\u003eDeploy new version to green. Run health checks and integration tests against green.\u003c\/li\u003e\n\u003cli\u003eRoute traffic from blue to green via load balancer update (ALB target group swap, Kubernetes service selector, or DNS weight change).\u003c\/li\u003e\n\u003cli\u003eMonitor for 15 minutes. If error rate \u0026gt; 0.1% or p99 latency \u0026gt; 500ms, revert load balancer to blue immediately (under 30 seconds).\u003c\/li\u003e\n\u003cli\u003eBlue environment retained for 24 hours as rollback target, then updated to match green.\u003c\/li\u003e\n\u003c\/ul\u003e\n\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCanary Deployment\u003c\/strong\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy new version alongside current. Route 5% of traffic to canary.\u003c\/li\u003e\n\u003cli\u003eAutomated metric comparison: canary vs. baseline. Compare error rate, latency percentiles, CPU utilization, custom business metrics.\u003c\/li\u003e\n\u003cli\u003eGradual promotion: 5% → 25% → 50% → 100%. Each stage has a 10-minute bake time and metric validation.\u003c\/li\u003e\n\u003cli\u003eAutomatic rollback if any metric deviates by more than 2 standard deviations from baseline.\u003c\/li\u003e\n\u003cli\u003eArgo Rollouts or Flagger for Kubernetes. AWS CodeDeploy for ECS\/Lambda.\u003c\/li\u003e\n\u003c\/ul\u003e\n\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eFeature Flag Deployment\u003c\/strong\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy new code behind a feature flag (LaunchDarkly, Unleash, or CloudBees). Code is in production but inactive.\u003c\/li\u003e\n\u003cli\u003eEnable flag for internal users → 1% of external users → 10% → 50% → 100%.\u003c\/li\u003e\n\u003cli\u003eRollback by flipping the flag — zero deployment required. Sub-second rollback.\u003c\/li\u003e\n\u003cli\u003ePipeline deploys code and creates\/updates the feature flag. Separate workflow for flag lifecycle management.\u003c\/li\u003e\n\u003c\/ul\u003e\n\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch3\u003eSecurity Gates\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePre-deployment approval\u003c\/strong\u003e — Manual approval gate before traffic routing. Approver sees: diff of changes, security scan results, staging test results.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAutomated rollback\u003c\/strong\u003e — No human intervention required for metric-triggered rollback. Reduces mean-time-to-recovery from minutes to seconds.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAudit trail\u003c\/strong\u003e — Every deployment, traffic shift, and rollback logged with timestamp, actor, and reason. Compliance-ready for SOC 2 and FedRAMP.\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch3\u003eWhat Breaks First\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eDatabase schema incompatibility between blue and green\u003c\/strong\u003e — The new version expects a column that does not exist in the old version's schema. Blue-green rollback fails because the old version cannot read the new schema. Fix: make all schema changes backward-compatible. Add new columns as nullable, deploy code that reads both schemas, then remove the old column in a subsequent release.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCanary metric baseline drift\u003c\/strong\u003e — The baseline metrics shift during the canary window due to traffic pattern changes (daily peak begins). The canary appears to be degraded but is actually performing identically. Fix: compare canary and baseline pods receiving the same traffic mix, not absolute metric values.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eFeature flag evaluation latency\u003c\/strong\u003e — SDK initialization takes 2 seconds, during which all flags evaluate to defaults. Users see the old experience for 2 seconds, then the page flickers to the new experience. Fix: use server-side evaluation and cache flag values at the edge, or initialize the SDK during server startup, not per-request.\u003c\/li\u003e\n\u003c\/ul\u003e","brand":"Citadel Cloud Management","offers":[{"title":"Default Title","offer_id":54890411819299,"sku":"CCM-DEV-016","price":35.0,"currency_code":"USD","in_stock":true}],"thumbnail_url":"\/\/cdn.shopify.com\/s\/files\/1\/0979\/8539\/7027\/files\/citadel-devops-product_54aa3897-cb6b-4041-8be1-601aa2d1ab3c.jpg?v=1775137856","url":"https:\/\/www.citadelcloudmanagement.com\/products\/blue-green-deployment-pipeline","provider":"Citadel Cloud Management","version":"1.0","type":"link"}