Principle
Shrink the change before shrinking the review
A giant change does not become small because the ticket fits on one screen.
When it fits
- A planned deployment or migration bundles many independent changes because one release window is available.
When to avoid it
- Small is not automatically safe; a one-line permission or schema change can still have wide consequences.
Why it matters
Reduce the number of independent things that can fail together. Split changes along reversible, testable boundaries and ship or migrate them in smaller units when dependencies permit. Smaller increments make failures easier to localize, limit impact and simplify rollback. Keep tightly coupled changes together when splitting would create an invalid intermediate state.
An example
Separate a configuration change from an unrelated data cleanup instead of combining both into one production window.
Check your result
A failure implicates a smaller set of changes and a smaller affected scope than the original bundled plan.
Keep this limit in mind
- Small is not automatically safe; a one-line permission or schema change can still have wide consequences.
Connected ideas
Useful withCanary the batch before scaling it
Evidence and sources
AWS recommends reducing release size to reduce the potential business impact and shorten recovery from unsuccessful changes.
Smaller changes can still be high risk if they alter a critical invariant or irreversible state.
OPS06-BP01 Plan for unsuccessful changes · Reduce the potential impact by making the change smaller