Blue-Green & Canary Deployments UK

How we set up the switch

We stand up two identical environments — blue and green — and cut traffic over at the load balancer or ingress once the new version has passed smoke tests. If something's wrong, rollback is the same switch in reverse, not a redeploy. For higher-risk changes we run canary rollouts instead: a small percentage of traffic hits the new version first, and metric gates decide whether it ramps up or rolls back automatically.

• Two identical environments, traffic switched at the load balancer
• Automated smoke tests run before any traffic switch happens
• Canary rollouts with traffic percentages and metric gates
• Session draining so in-flight requests finish on the old environment

Best practices we apply

Zero-downtime deployment mostly fails at the database layer, not the application layer — a schema change that isn't backward-compatible with both environments running at once will break blue-green no matter how well the switch is engineered. We apply the same discipline on every rollout we set up, database migrations included, and we walk your team through the expand-and-contract pattern the first time it comes up so it isn't a surprise mid-release.

• Never deploy a schema-breaking migration in the same release as the code
• Automated smoke tests gate every switch, not a manual check
• Rollback reduced to a single command, tested before go-live
• Old environment kept live until metrics confirm the new one is healthy
• Deploy windows aligned to your actual business hours, not ours

Database migrations without breaking the old version

The hard part of zero-downtime deployment is almost always the database, not the application code. We use an expand/contract pattern: add the new column or table alongside the old one, deploy code that can read both, switch traffic, then remove the old structure once nothing depends on it anymore. This is what lets blue-green actually work when both environments run against the same database briefly during a switch.

How the included hours work

DevOps hours come with the plan: 1–8 hours a month on VPS tiers, 5–10 hours a month on dedicated servers depending on the plan, 10 hours a month on GPU servers. Use them for the initial pipeline set-up, adding canary gating to an existing deployment, or investigating why a rollback didn't behave as expected. Request the work from the client panel under DevOps Services. Hours don't roll over, so most teams build the pipeline in one month and refine the metric gates over the next.

How we work

1. Request the work from the panel

   You describe your current deployment process and the release cadence you want to hit, and propose a deadline under DevOps Services.

2. We scope the switch and the migration strategy

   We confirm blue-green or canary, the metric gates for canary, and how database migrations will be handled expand/contract style.

3. We build and test a real rollback

   We set up both environments and the switch mechanism, then deliberately trigger a rollback to confirm it works before go-live.

4. We hand over the deploy runbook

   You receive the pipeline configuration, the rollback command, and the checklist for shipping a schema change safely.

Use cases

Technology stack

• Traefik
• NGINX
• Argo Rollouts
• Kubernetes
• Prometheus
• Grafana
• Flagger