What does batching twenty dependency bumps into one change cost you when it breaks production?

## What batching actually buys Grouping twenty routine bumps into a single change is the standard answer to update fatigue, and the benefits are real rather than cosmetic. - **One review instead of twenty.** Attention is the scarce resource. Twenty separate items get skimmed; one dense item with twenty version lines has a chance of being read. - **One CI run instead of twenty.** On a slow suite this is the difference between a policy that runs and one that starves. - **One coherent resolution.** Twenty independent proposals against the same lockfile conflict with each other: each merge invalidates the rest, which then rebase, re-resolve, re-run. A batch resolves the graph once, as it will actually exist. - **One release note.** Downstream consumers and change records get a single entry rather than twenty lines of noise. So the default for routine currency work should be batched. The question is what you paid. ## What batching sells: attribution The cost is paid only when something breaks, which is why it is easy to miss until it hurts. **Bisect moves inside the batch.** Normally a bad change is found by walking history: each commit is one dependency, so the search is over an ordered list you already have. A batch collapses twenty changes into one node. History-walking narrows to *the batch*, and then stops. From there you are doing manual bisection over the batch's members -- split it in half, rebuild, re-run, split again -- which needs roughly log2(n) build-and-test cycles. With twenty members and a fifteen-minute pipeline, that is over an hour of cycles before you even have a candidate, and you are spending it during an incident. **Revert is all-or-nothing.** The fastest mitigation is reverting the batch, and it works. But it also removes nineteen upgrades you actually wanted, including whatever fixes they carried, and puts them back in the queue. The pressure after a bad revert is to leave them out for a while, so a single batch failure often costs weeks of currency across everything it contained. **Diagnosis is harder before you even bisect.** With a single-dependency change, the symptom and the change usually suggest each other. With twenty, the first useful question -- *which of these could plausibly touch this code path?* -- takes real effort, and under pressure people guess. **One stuck member stalls the group.** A batch cannot merge until every member is green. One package with a genuine incompatibility holds nineteen fine upgrades hostage indefinitely. This is the subtle failure: the team believes batching solved their fatigue problem, while a single blocked member has quietly reproduced exactly the stale, unmerged queue they started with. Any batching policy needs an explicit rule for evicting a failing member and letting the rest through. ## Grouping by the right key The useful heuristic is to **group by rollback unit and blast radius, not by convenience**. - Build, lint, format and test tooling can be one large group. Its failures are loud and build-time, and reverting the whole group costs nothing in production. - Packages from one family that must move together belong in the same group by necessity -- splitting them just produces a batch that cannot resolve. - Runtime libraries on a critical path deserve their own change, or a very small group, because these are the ones where you will want per-package attribution at 3am. - Anything on an authentication, cryptography or deserialisation path should not be batched at all; you want that diff read on its own. ## Sizing A workable test: **if you cannot split the batch in half and re-run the suite cheaply, it is too big.** That ties the batch size to your pipeline speed rather than to a fixed number. A team with a four-minute suite can carry a much larger batch than one with a forty-minute suite, because their bisection is cheap. Improving pipeline speed literally raises the safe batch size. A second rule: **keep per-member information visible inside the change.** A batch that presents only twenty version-number lines has removed the ability to review anything. A batch that carries per-package change summaries is still reviewable, and its diagnosis is much faster later. ## Never batch the urgent one The strongest single rule here. A bump driven by a disclosure against a version you resolve has an externally set clock, and putting it in a group does two bad things: it hides it among cosmetic noise so nobody treats it as urgent, and it couples its ship date to the slowest, most-broken member of the batch. It also makes the eventual evidence question harder -- proving the fix landed is easy for a single-purpose change and awkward inside a twenty-package diff. Urgent changes ship alone. ## The pairing to avoid Large batches and unattended merge are each defensible and, together, are the worst combination available: a change nobody read, spanning twenty packages, landing unattended, with no per-package attribution when it breaks. If you automate merge, keep batches small and their contents narrow. If you want large batches, keep a human in front of them.