Put it live

Think of it when a change is about to reach real users, or something broke right after a release.

In everyday life

A city opens a new bridge. Engineers test it first, but they also watch it closely in its first hours of real traffic, and they keep the old route ready to reopen at once.

One case

A shop puts a new version live at 16:55 on a Friday, and the team goes home. A bug on the payment page stops every order: from about 45 an hour to 0. Nobody is watching the numbers, so the problem is found at 19:30, when a customer emails. The old version is back at 19:45.

Orders stopped at 16:55; nobody looked until 19:30
The case, cell by cell1 cell = 1 hour
Orders on a normal Friday
384144464235
Orders this Friday
383800935
Orders lost
126
Minutes until someone noticed
155
Each column is the hour that starts at that time. Orders stopped at 16:55, and the old version came back at 19:45.

Every case

Many outages start right after a change, and a deploy is where changes reach people. Tests before a deploy catch many problems, but some appear only with real users and real data. So a good deploy has two halves: put the new version live, then watch the errors and the key numbers for a while. It also needs a fast, practiced way to roll backPut the previous version back after a bad change..

The word

Engineers call this

deployThe step that puts a new version of the code onto the servers that real users reach. After a deploy, users get the new behavior.

Deploy small changes, at a time when someone can watch, and check the live numbers after each one. Know how to roll back before you need to.

Where this idea leads

Skills that encode it

  • poteto-mode pstackAlways pause for irreversible writes, and it names deploys among them.
  • principle-prove-it-works pstackCheck the real thing, not a proxy: read the actual value after the change instead of assuming it works.