Continuous Integration

When several people change the same product, their working copies drift apart. The old approach was to close that gap once, at the end: cut a branch per feature, work on it separately for a few weeks, and merge everything together shortly before release.

Merge day was the problem. When five people have edited the same files over three weeks, the machine can't decide which version is right and has to ask a human. A few hundred of those questions take three days rather than one, and nobody writes new code while they're being answered. The worse moment comes after the merge, the first time anyone runs the result. Everything worked on each individual branch; combined, it doesn't, and the cause is somewhere inside five people's three weeks of changes.

Early Pagedeck releases looked exactly like this. Theo saying "give me two days just for merging" was routine, and those two days added no functionality. Sometimes a merge went badly enough that days of work were thrown away and redone. The delay also hid ordinary mistakes for weeks: a rename that broke someone else's code was only discovered at the end, long after the person who made it had moved on to something else and forgotten the reasoning behind it.

Continuous integration deals with the gap by never letting it grow. Merge a small piece at least once a day instead of one large chunk every three weeks, and a conflict only has yesterday's changes to hide in. The cost of merging grows faster than the time you delay it, which is why doing it constantly is easier every single time.

The whole idea is attaching an automated check to every merge. In practice it runs in four steps.

1. Cut work into pieces small enough to merge within a day. Waiting until an entire feature is finished recreates the multi-week branch. Slice by screen or by function, and leave the unfinished parts in a state that isn't switched on yet.
2. Pull the latest shared trunk, then put your change up for a code review by a teammate. A day's worth of change takes thirty minutes to read properly. Three weeks' worth gets skimmed and approved.
3. The pipeline builds and tests automatically. Unit tests, which check one function or module in isolation, carry most of the load here, and the whole run is kept near ten minutes — past that, people stop waiting for it.
4. When it fails, the person who broke it fixes it right then. A broken trunk hands the failure to everyone who merges afterward, so the fix outranks new work. If it isn't fixed within twenty minutes, the change gets reverted and prepared again. Reverting isn't a judgment on the change; it just keeps the cost of one mistake from spreading across the team for the rest of the afternoon.

Many teams pair this with a rule against long-lived branches. That's trunk-based development, which is step 1 written down as a policy rather than a habit.

Wherever more than one person edits the same code, it pays off regardless of team size. On a solo project there is nobody to integrate with, so the effect is smaller — though the automated tests still run and still catch things. And a team aiming at the later stages, continuous delivery or continuous deployment, can't reach them without this one working first. Shipping automatically without checks isn't automation, it's neglect.

Three conditions decide whether adopting it does anything.

1. The tests have to be trustworthy. Mix in a few flaky tests — ones that pass and fail on identical code — and the team starts re-running red builds instead of reading them. From that point the result carries no information.
2. The check has to be fast. A forty-minute run means people move on to the next task rather than wait, which pushes the discovery of a failure back to the next day and undoes the point.
3. The team has to agree to stop on red. Keep merging onto a broken trunk and within days nobody can tell which failures were already there, and the suite turns into a list of known-bad items people scroll past.

It's worth being clear about what adoption does not do. This tells you quickly where things broke; it does not raise code quality. Anything the tests don't examine stays exactly as it was behind a green check. A team that reads green as proof of correctness, rather than as proof that a specific set of checks ran, will be surprised by the first bug that lands in an untested corner.

"The build is red right now. Hold off merging until it's fixed."

The shared trunk is broken, and stacking on top of it mixes the causes together.

"I'll merge this as soon as CI passes."

Human approval is done; only the automated result is outstanding.

"You've been on that branch for two weeks. Merge something in the middle."

A suggestion to pay the integration cost in installments before it grows.

Pagedeck turned this on with exactly one rule: the shared trunk has to be green at six in the evening. The first month it went red several times a day, and Theo spent it tracking down whose change did it. People responded by running the tests on their own machines before pushing, and two months later red builds were down to a couple a week.

The bigger change showed up in meetings. Two weeks before a release the team used to debate how long merging would take. That question is simply gone now, because the code is already merged. Once Mia stopped padding schedules with integration days, the variance in her release dates dropped with it.

The most common mistake is thinking the tool is the practice. Push one configuration file and checks start running on their own, so it does look that way. But the substance here is the habit of merging at least once a day, not the software that watches for it. Leave three-week branches in place and add automated checks on top, and merge day is as painful as it ever was — the only difference is that tests now run inside each branch.

Reading "CI" as the name of a build tool is the second one, and it follows naturally from sentences like "can you run CI on this." The cost is that "we use CI" comes to mean "we have a build server" rather than "we integrate often," and branches quietly living for weeks never register as the problem they are.