flagship case study / production experience

Blue-Green Release Pipeline

A release strategy using namespace-level isolation and Istio VirtualService routing, with a Traffic Controller pipeline handling APIM / ORP and shared-service integration.

Problem

Release changes needed a safer promotion path than sending all production traffic to a new version at once. The design separates the active and candidate workloads so the candidate can be validated before traffic is moved.

Contribution

I owned the Azure DevOps build/release and Traffic Controller pipelines, Helm deployment, namespace structure, Istio gateway and VirtualService routing, Web App slot switching, and Key Vault/Managed Identity integration. I co-owned validation, rollback, and architecture documentation.

Production traffic path

Userincoming application request

Azure Traffic Managerdirects traffic to the active endpoint

Active Web App slotselected application slot

AKS + Istio Ingress Gatewaycluster ingress and service-mesh routing

Active blue or green namespaceroutes to the selected service version

Deployment flow

Developer → Azure DevOps buildbuild and release automation

Helm deploymentdeploy to the inactive blue or green namespace

Validation gatesreadiness/liveness, health endpoint, smoke and integration tests, Datadog/App Insights, manual approval

Traffic Controllerswitch Web App slot and Istio routing to the validated environment

No Argo CD or GitOps controller is currently part of this flow.

Technical decisions

Namespace isolation keeps active and candidate workloads separate within AKS.
Istio gateways and VirtualServices provide controlled routing to the selected namespace.
Azure DevOps and Helm make the release sequence repeatable.
Azure Key Vault, Managed Identity, and variable groups handle secrets and deployment configuration.

Failure handling

Validation must pass before the traffic switch.
Rollback reruns the Traffic Controller pipeline to return traffic to the previous environment.
The failed environment stays running for investigation, then is fixed and redeployed.
The known-good environment remains available throughout the process.

Operational outcome

The release team can deploy and validate the inactive environment during normal working hours. Only the controlled production switch and final validation need the approved nighttime window, preserving sensitive-data restrictions while reducing long late-night deployments.

Faster rollback through a repeatable Traffic Controller pipeline.
Fewer release incidents through pre-switch validation.
Safer validation before production traffic.
Reduced nighttime deployment effort for the onsite release team.

Engineering lesson

Blue-green delivery is most useful when it changes the operating model, not just the deployment target: isolate the candidate, validate it before exposure, switch traffic deliberately, retain a known-good path, and make rollback executable rather than theoretical.