Blue-green deployment starter pack.

TL;DR

blue-green

I want to share a simple way to start with blue-green deployment. From the diagram to the working solution. Please check my sample GitHub repository with the bicep sample for Azure FrondDoor and Azure App Service (two instances).

Reason

blue-green

I want to start with the meme - but it is not - it is a real case! Do you want to check the newest .Net Framework with your (legacy) application? Or do you want to test a clean deployment process for your infrastructure? In the perfect scenario, 100% test coverage and integration and E2E tests for each service and delivery team will bring you 99.99% confidence in the deployment process. But in the real world, I’m not blaming, but the standard case is that a secret, password, or production endpoint can fail and disable the whole application for seconds, minutes, or hours.

Please check the cases below.

  1. Minimizing Downtime
  2. Reducing Deployment Risk
  3. Easy Rollback
  4. Seamless Updates
  5. Testing in Production
  6. Zero-Downtime Migrations
  7. Improved Continuous Delivery
  8. Enhanced Monitoring and Validation

Solution 1

blue-green

FrontDoor RuleSet decision to route traffic to Blue or Green deployment origin. When deploying a new version, the FrontDoor Rule can override the routing to the new deployment origin based on the X-Target-Origin header and value green. A system consumer can change the header value to green to route the traffic to the Green deployment origin. The automated test on the pipeline can also check the new deployed service.

Solution 2

blue-green

As an extension to the basic case with Version 2 (V2), the FrontDoor can use two origins for the same Origing Group and route the traffic based on a defined rule (e.g., 75% to 25%). In the case of errors with the 1.1 version, the traffic can be routed to the 1.0 version based on the alert, event bus, and automation.

Other possible solutions

Slot deployment (Azure App Service)

Pros

  • Easy to implement
  • No additional costs

Cons

  • Not fully isolated - same .Net Core version, KeyVault, etc.

Post-mortem

In my current scenario, I don’t have a ‘problem’ with the versioning or changes with the data source—like a database. I’m not covering the process for database migration and support from both blue and green instances here. Also, each case can be specific—for example, “service” logic can be different for each version. This can provide issues or errors from different versions, and in that case, you should consider the “feature flag” approach.