Release Train
A fixed-cadence release where whatever is ready by the departure time ships, and whatever is not waits for the next one.
The train is a coordination device, and it is genuinely useful where releases must be synchronised across teams that cannot deploy independently — packaged software, mobile app store submissions, embedded firmware, or a distributed system whose components share a contract that changes in lockstep.
Its virtue is predictability: a fixed departure removes negotiation, and the pressure of a missed train is deliberately mild because the next one is soon.
Its cost is queueing. A change that finishes an hour after departure waits a full cadence, so lead time is dominated by the interval rather than by the work, and the p90 of lead time is roughly the cadence regardless of how fast the team is. Batching also degrades diagnosis: when a train of forty changes causes a regression, you have forty suspects.
The architectural read: a release train is a symptom of coupling as often as it is a choice. If teams are on a train because their services cannot deploy independently, the train is treating the pain rather than the cause, and the work is in the contracts and the schema, not in the calendar.