Lesson 15.1015.10 After the merge

In everyday life. A restaurant adds a new dish to the kitchen's recipe book on Monday, but puts it on the menu only on Thursday. It offers it first to one table of regular customers, and keeps the old dish ready in case the new one fails. Adding the recipe, offering it, and serving it to everyone are three separate decisions.

What you will learn. How to get a merged change to its users safely, and how to undo it.

Why it matters. A merged change is not yet delivered, and a mistake after the merge reaches real users and real money.

What is left after the merge?

Delivery. Review decides whether a change may join main. Getting it into production is the last part of the bottleneck from the chapter's opening, and often the slowest. Four practices make that step safe without making it slow.

What is a merge queue for?

A merge queue stops pull requests from breaking main together. Two pull requests can each pass their checks and still break it, because each was tested against an older main. For example, one renames a function, and the other still calls the old name. The queue lines up approved pull requests and tests each one on top of the latest main plus the changes ahead of it. Only a change that passes there is merged. It matters most on a busy repository, where many changes merge each hour. On GitHub, the required workflows must also run on the queue's own event, merge_group. Any check that compares with the base branch must read the base from that event, or the queue tests nothing.¹

What does a feature flag do, and what does it not do?

A feature flag is a setting that turns new behavior on or off without changing the code. Merging a change behind a flag that is off puts the code on main, where it is reviewed, tested and kept up to date. It reduces the risk of the merge when the new code is isolated and a test shows the old behavior unchanged with the flag off. It does not remove the risk: imports, new packages, changes to shared code and data migrations, which change stored data, all take effect when the merged code runs, whatever the flag says. Turning the flag on is a separate decision, by the person who owns the policy. Two warnings come with flags. Every flag doubles the cases to test, on and off. And a flag that stays forever becomes clutter, unused code that gets in the way, so give each one an owner and a date to remove it.

What is a staged rollout?

A staged rollout turns new behavior on for a few users first, watches what happens, then turns it on for more users. Software that others install can do the same with release channels: a latest channel that gets changes first, and a stable channel that gets them later.

How do I get back?

With a rollback you have rehearsed, or practiced. A rollback is a return to the last good state. For a flag, it is turning the flag off. For code, it is a revert. That is a new commit, or a new pull request, that undoes the merged one and keeps the history (15.2).² Rehearse it before you need it, on a branch, and check that the branch gives the old answer afterward. Some things cannot be rolled back this way. A payment already sent stays sent, and a message already delivered stays delivered. That is why turning on a flag that sends money is its own high-tier decision.

Who watches it after the merge?

You land it, you own it. To land a change means to merge it. The person who merges a change, or who directed the agent that wrote it, watches it after the merge and is the first to fix it if it breaks. Review shares understanding. It does not hand the responsibility to someone else.

In the case study. The team's merge queue reruns every check against main with the change applied. New behavior ships behind flags, to Anthropic's own staff first, and flags turn off without a new release. Public releases go to the latest channel before stable. When something breaks, whoever landed it usually fixes it.³

At work. The weekend rule merges with PAY_WEEKEND_RULE off. On main, npm run due -- 2027-03-05 still prints 8 invoices, $19,229.53, the Chapter 12 answer. The test "with the rule off, the answer is unchanged" checks exactly that on every change. With the flag on, it prints 10 invoices, $33,109.53. Ana rehearses a revert of the merge on a scratch branch. The weekend code disappears, every check still passes, and the answer is still 8 invoices. Dave Kowalski, the controller, will decide in April whether to turn the rule on. The person who turns it on owns the first Friday run with it.

The operating rule: merge risky behavior behind a flag that is off, turn it on as a separate decision, and rehearse the way back before you need it.

Figure 15.16. From merge to everyone. Merged is not deployed, and deployed, which means running in production, is not turned on. Each stage is a separate decision, with a way back.

Practice it. Practice: after the merge, in your own tool, ten minutes.