Ways to release
Rolling, blue/green and canary — and when each fits.
Part 1: The problem
QuickCart’s releases work like this: stop the API servers, copy the new code on, start them again. For about two minutes, every order fails. The team deploys at 11pm, when it hurts least.
One Tuesday, the new version has a bug in the delivery fee. The moment it starts, every customer is charged the wrong fee. Rolling back means doing the whole stop-copy-start again: two more minutes of failures, then the old bug-free version.
Leo asks the obvious question: why does every customer have to get a new version at the same moment?
The fix is the same for QuickCart as for anyone: stop giving everyone a new version at the same moment.
Part 2: The idea
Deploying means replacing the running version with a new one while customers keep using it. There are a few standard ways to do the replacement. They all end in the same place, with everyone on the new version. They differ in how traffic moves from old to new, and that decides what happens when the new version is bad.
The four ways
| Strategy | How traffic moves | If the new version is bad | Extra cost | Undoing it |
|---|---|---|---|---|
| Recreate | Stop everything, then start the new version | Everyone gets it, after a gap with no service | None | Do it all again |
| Rolling | Replace servers a few at a time | A growing share gets it until someone notices | None, or one extra server | Roll back, a few servers at a time |
| Blue/green | Build a full copy with the new version, then switch all traffic at once | Everyone gets it, but only until you switch back | A second full copy, for a while | Instant: switch back |
| Canary | Send a small share of traffic to the new version, then grow it | Only the small share gets it, and the release is stopped | Small: one extra server, or none | Instant: send the share back |
QuickCart’s current method is recreate. It’s the simplest, and the only one with downtime built in.
What each one needs
| Strategy | You need |
|---|---|
| Rolling | A load balancer that stops sending traffic to a server before it’s replaced, and health checks so it only sends traffic to servers that work |
| Blue/green | A way to switch all traffic at once, usually a load balancer or DNS, and room for a second copy |
| Canary | A way to split traffic by percentage, and monitoring that compares the canary with the old version, and rules for when to stop |
The canary’s rules are called abort criteria, and they’re written down before the release starts. For example: if the canary’s error rate is more than double the old version’s for five minutes, send all traffic back. The best pipelines apply them automatically. Canary from a pipeline builds exactly that.
Old and new run side by side
In rolling and canary releases, and briefly in blue/green, both versions answer requests at the same time, and both use the same database. So every database change has to work with both versions:
| Safe | Breaks the version that doesn’t expect it |
|---|---|
| Adding a new column or table | Renaming a column |
| Adding a column with a default value | Removing a column |
| Removing a column, in a later release, once nothing uses it | Changing a column’s type |
This pattern is called expand, then contract: add the new thing, move the code over, and remove the old thing only when nothing uses it any more.
Choosing one
| Situation | A good fit |
|---|---|
| A small internal tool where a minute of downtime is fine | Recreate |
| Most services, most of the time | Rolling, with good health checks |
| A risky change you want to test fully before anyone sees it, with an instant way back | Blue/green |
| A change to something customers depend on, like checkout | Canary |
Part 3: See it
The three strategies release the same version side by side. Release a good version first. Then switch to Bad and release again. Watch how traffic moves, and how many customers the bad version reaches.
Rolling
Blue/green
Canary
What to notice: blue/green undid the bad version fastest, but it had already reached every customer. The canary reached only one in ten, because it was stopped while it was still small. Speed of undoing and number of customers hit are different things.
Part 4: Do it
Pennies — a few calls to a tiny Lambda function. Well under a cent, and inside the free allowance on most accounts.
You’ll run a real canary release on AWS, without any servers. You’ll put two versions of a small function behind one name, send 10% of calls to the new version, watch the split, then promote it, and finally switch back instantly. About 20 minutes.
The function runs on Lambda, which runs code without you managing a server. You don’t need to know Lambda yet: it’s just the simplest thing on AWS that can split traffic by percentage. The same ideas apply to servers and containers later in the course.
Check the region selector says N. Virginia (us-east-1), and that you’ve set up the AWS CLI in Set up your computer.
Create the function
In the AWS console: LambdaFunctionsCreate function
Field Enter Create function Author from scratch Function name quickcart-menuRuntime The newest Node.js version in the list Architecture arm64 Permissions Leave the default: Create a new role with basic Lambda permissions Choose Create function.
You should seeThe function’s page, with a Code tab showing a file called
index.mjs.Write version 1 and publish it
In the Code tab, replace everything in
index.mjswith:index.mjsexport const handler = async () => { return { version: "1", menu: "Margherita, Pepperoni" }; };Line What it does export const handlerthe function Lambda calls. It must be called handler, because that’s what the default settings look forasync () =>it takes no input we need, and may do slow work return { version: "1", menu: "Margherita, Pepperoni" }the answer, including which version sent it Choose Deploy. Then fix this code as a numbered version that can never change:
In the AWS console: LambdaFunctionsquickcart-menuActionsPublish new version
Field Enter Version description v1Choose Publish.
You should seeA message saying Version 1 was created. You’re now looking at version 1’s page.
Point a name at version 1
An alias is a fixed name that points at one or more versions. Callers always use the name; you change what it points at. That’s what makes the release strategies possible.
In the AWS console: LambdaFunctionsquickcart-menuAliasesCreate alias
Field Enter Name liveVersion 1Leave Weighted alias empty. Choose Save.
You should seeThe
livealias, pointing at version 1.Write version 2 and publish it
Go back to the function (Lambda → Functions → quickcart-menu), open the Code tab, and change
index.mjsto:index.mjsexport const handler = async () => { return { version: "2", menu: "Margherita, Pepperoni, Veggie" }; };Choose Deploy, then Actions → Publish new version with the description
v2, and Publish.You should seeVersion 2 created. Nobody is calling it yet:
livestill points at version 1. That’s deploy without release.Start the canary: 10% to version 2
In the AWS console: LambdaFunctionsquickcart-menuAliasesliveEdit
Field Enter Version 1Weighted alias: Additional version 2Weight 10Choose Save.
You should seeThe alias shows version 1 at 90% and version 2 at 10%.
Call the alias and watch the split
Now call
livethe way a real caller would. The console’s Test button is built for trying one version; to see which version answers each call through the alias, the terminal is simpler, because it prints that for you.Terminalaws lambda invoke --function-name quickcart-menu:live response.jsonPart What it means aws lambda invokecall a Lambda function once and wait for the answer --function-name quickcart-menu:livethe function, and after the colon the alias to call through response.jsona file to save the function’s answer in. It’s created in the folder you’re in You should see{ "StatusCode": 200, "ExecutedVersion": "1" }ExecutedVersionis the version that answered. Run the same command ten or twenty times: press ↑ then Return to repeat it.You should seeMostly
"ExecutedVersion": "1", and now and then"2". Over many calls, about 1 in 10 is version 2. With so few calls, you might see none or several; that’s chance, not a fault.Promote it
The canary looks healthy, so give version 2 everyone. Edit
liveagain:In the AWS console: LambdaFunctionsquickcart-menuAliasesliveEdit
Field Enter Version 2Weighted alias: Additional version Remove it, so there is none Choose Save, and run the
invokecommand a few more times.You should see"ExecutedVersion": "2"every time. The release is complete.Switch back instantly
Say version 2 turns out to be wrong. Edit
liveonce more and set Version to1. Choose Save, and invoke again.You should see"ExecutedVersion": "1"every time. Version 2 still exists, so switching forward again is just as quick. This is the blue/green idea: two complete versions, and one pointer that moves between them.Clean-up step: Clean up
In the AWS console: LambdaFunctionsquickcart-menuActionsDelete function
Type
confirmif asked, and choose Delete. This removes every version and the alias.Lambda also created a log group for the function’s logs. Delete it too:
In the AWS console: CloudWatchLog groups/aws/lambda/quickcart-menuActionsDelete log group(s)
Finally, remove the answer file from your laptop:
Terminalrm response.jsonPart What it means rmremove a file response.jsonthe file aws lambda invokewroteThe IAM role Lambda created, named like
quickcart-menu-role-followed by random letters, costs nothing. You can delete it in IAM → Roles if you like to keep things tidy.
Part 5: Check yourself
A new version has a bug that only shows up with real customers' data. Which strategy lets it reach the fewest customers before it's stopped?
What does blue/green need that rolling doesn't?
During a rolling release, old and new versions answer requests at the same time. What does that mean for a database change?
A canary is showing an error rate ten times higher than the old version. What should happen?
In the App Store, you release an update to 1% of users on day one, then more each day. Which strategy is that?
Part 6: Cheat sheet
| Strategy or idea | In one line |
|---|---|
| Recreate | Stop everything, start the new version. Downtime built in |
| Rolling | Replace servers a few at a time. No extra cost; bad versions spread until noticed |
| Blue/green | Full second copy, then switch all at once. Instant undo; everyone hit if bad |
| Canary | Small share first, grow while watching. Fewest customers hit |
| Abort criteria | The rule for stopping a canary, written before you start |
| Expand, then contract | Database changes that work with old and new versions at once |
| Rolling back | Undoes code, not what the bad version already did |
| Lambda alias | A name pointing at one version, or two with weights |
aws lambda invoke --function-name NAME:ALIAS out.json | Call through an alias; ExecutedVersion says who answered |