Blue/green deployments without drama
Blue/green sounds fancy, but in practice it’s just “have two environments, switch traffic between them safely, and be able to roll back quickly”. The hard part is lining up databases, queues, and background workers so they don’t step on each other.
1. Two stacks, one data plane
I think of blue/green as:
- Two app stacks: Blue (current) and Green (candidate).
- One shared data plane (DBs, queues, external systems).
The goal is to make the app stacks swappable without corrupting data or processing the same messages twice.
2. Make the schema backward-compatible first
I avoid schema changes that require all code to switch at once. For example:
- Add new columns/tables that old code can ignore.
- Keep old columns until both blue and green are updated.
- Do destructive changes in a separate, later deployment.
3. Think about workers and queues
For background services (RabbitMQ consumers, schedulers, etc.), I prefer:
- Only one side (blue or green) actively consuming a queue at a time.
- Gradually cutting over consumers after API traffic moves.
- Monitoring DLQs closely during and after the cutover.
4. Make rollbacks boring
A good blue/green setup lets you roll back with:
- A traffic switch in your gateway/ingress/load-balancer.
- A flag to disable green workers and re-enable blue workers.
- Clear dashboards to see which color is live.