Part 2 — Deployment Strategies
On this page 4 headings
Section point: Deployment strategies are ways of pushing code from the staging environment to the production environment. The lecture covers three: Blue/Green, Canary and Versioned deployment.
2.1 Blue/Green deployment (Staged deployment)
Idea: create a new, separate production environment for the new version, without affecting the current one.
How it works:
- The Blue environment is the current live production environment. A router sends all users to it.
- The new version is deployed to a second, identical production environment called Green. No users are sent there yet.
- Green is tested thoroughly (integration testing and other testing).
- The router switches all incoming requests from Blue to Green. Green is now live, and Blue sits idle.
Main advantage — easy rollback. If something goes wrong after the switch (errors, or the system crashes), the router simply sends users back to Blue, which is known to work.
Regular cycling. The two environments take turns. If Green is live now, the next update is pushed from staging to Blue, and then the router switches to Blue. Blue and Green keep alternating between “real (live)” and “previous version”.
2.2 Canary deployment (Phased rollout / Incremental rollout)
Idea: instead of sending all users to the new version at once, slowly roll out the change to a small subset of users first, and increase the share step by step.
The name comes from the “canary in a coal mine”: a small early warning before everyone is exposed.
How are the users for the new version chosen? The lecture lists these options:
- Randomly
- By user profile or demographics
- By region: if there are servers in different locations, roll out to one region first, check that it works properly there, then roll out to other regions incrementally.
Drawback: you must manage multiple instances at once. Some users are on the old version and some on the new one, so both have to be run and supported at the same time.
2.3 Versioned deployment
Idea: allow users to choose which version to use, and keep all versions alive.
This is common in mobile apps (the lecture’s examples are Paytm and Instagram). You get a notification that an update is available:
- if you update, you are routed to the new version;
- if you don’t, you continue on the previous version.
Drawback: the company has to maintain multiple versions, because not all users update regularly. Companies therefore announce that only certain versions are supported up to a given date, after which older versions stop receiving support.
Summary of Parts 1 and 2
| Topic | Key facts |
|---|---|
| Development | Developer’s local machine, IDE, working copy, local DB; commit to mainline/master |
| Testing | Integration and system testing; on failure: remove code, find module, notify developer, roll back |
| Staging | pre-production; exact replica of production on a remote machine; release rehearsal, previews, performance/stress testing |
| Production | Live environment used by all real users |
| Blue/Green | Separate new production environment; router switch; easy rollback; environments cycle |
| Canary | Phased/incremental rollout to a subset (random, profile/demographics, region); drawback: multiple instances |
| Versioned | Users choose version; all versions alive; drawback: maintaining many versions |