Release trains and their discontents

The release train is a scheduling metaphor with a specific promise: the train leaves at a fixed time, whatever is ready boards, whatever is not waits for the next departure. It was a genuine advance over what preceded it, which was the release-when-ready model, under which nothing was ever ready and releases were quarterly arguments with a build step.

The train fixed real things. It decoupled "is my feature done" from "can the org ship," which ended the era of one team's slippage holding forty features hostage. It made cadence a property of the system rather than of heroics. For its native habitat (many teams, one integrated deliverable, expensive validation), it remains the correct tool; nobody sensible wants firmware or a banking core released when any engineer feels lucky.

The discontents begin when the train outlives the constraints that justified it. Continuous delivery quietly removed most of them for most web software: if a change can be deployed alone, behind a flag, in minutes, then batching it with two hundred strangers' changes is not coordination, it is added risk wearing a hi-vis vest. A batch integrates the failure modes of everything aboard. The train, in this habitat, manufactures exactly the integration problem it was invented to manage.

The tell is what happens between departures. Healthy trains carry work that was genuinely finished on independent schedules. Unhealthy ones generate a two-day "hardening sprint" before each departure, a freeze calendar, and a class of engineer whose full-time job is train conductor. When the ceremony around the batch costs more than the batch saves, the process has become commemorative: the org is performing the memory of a constraint.

Batch size has been the underlying variable all along. The DORA research program keeps finding, year after year, that smaller changes deployed more frequently correlate with both speed and stability, not as a trade but jointly. The train is a batch-size decision made organizationally; every departure interval is a statement about how much risk you prefer to accumulate before finding out.

The degenerate case makes the point by contrast. A single person shipping a personal site, running one engineer's deployment pipeline, runs a release train with a departure every push and a passenger manifest of one; nobody calls it that, because the coordination cost being solved is zero. Coordination cost is the entire justification. Measure it before scheduling around it.

None of this condemns cadence itself. Predictable rhythm is kind to marketing, to support, to enterprise customers who validate releases, and those constraints are as real as any compiler error. The discipline is to name the constraint each departure serves. "Compliance validates quarterly" justifies a quarterly train. "We have always done the Thursday release" justifies an archaeology project, of the kind this journal keeps finding under old processes. Trains are infrastructure. Infrastructure should exist because something rides on it.