Comparison
Batch sizevsChange freeze
Batch size
the release contained forty changes, something broke, and the first hour went on working out which one.
How much change moves through the pipeline at once. Almost every delivery improvement is a batch-size reduction in disguise, because small batches are easier to review, faster to test, cheaper to revert and clearer to attribute when they fail. The pressure is always toward larger batches, since each release carries fixed overhead, which is why the sustainable fix is to reduce that overhead rather than to exhort people to ship smaller.
Full entry →Change freeze
nothing may ship for three weeks over the peak period, so a hundred changes go out together on the day it lifts.
A period during which deployments are prohibited, usually around a commercially critical window. It reduces the rate of changes and increases the size of every one that follows, which trades a small chance of many small failures for a large chance of one big one. It is most defensible when the release process is genuinely risky, which makes it a symptom worth reading rather than a practice worth defending.
Full entry →