A pull request changes only a few lines, but it depends on a database migration, a separate service update and a carefully timed configuration switch. Its diff is small. The release still asks the team to coordinate several moving parts at once.
Choose a useful, independent change
Imagine adding a saved filter to a reporting application. The full feature touches storage, an API and the interface. One possible sequence first introduces compatible storage, then an API that handles both old and new records, then the interface that uses the new capability. The correct order depends on the system’s compatibility constraints.
Each increment needs a behavior that can be checked. Splitting files into separate pull requests without reducing their deployment dependence may make review harder while leaving the release risk intact. Explain which combinations of old and new components remain valid at every step.
Test the behavior being changed
DORA’s small-batch guidance connects smaller units of work with faster feedback and reduced complexity. The useful application is to shorten the distance between a change and evidence about its effect. A line-count target cannot establish that by itself.
For the saved-filter example, storage compatibility can be checked before the interface is exposed. The API can be exercised with synthetic records. The interface can then be evaluated as a user interaction. A failing result points to a smaller decision than a single release containing all three changes.
Source: DORA · Working in small batches.
Plan for feature-flag states
A flag can separate deploying code from exposing a feature. It also creates combinations that need to be supported: old and new data, enabled and disabled behavior, and possibly different settings across environments. Document those combinations before relying on the flag as the recovery plan.
If disabling the interface leaves incompatible writes in storage, the flag has not undone the change. Identify what remains and whether older code can still handle it. Small batches help when they reduce the amount the team must reason about, including during recovery.
Find what makes releases grow
A release requiring several meetings and a scarce operator makes larger batches tempting. Teams may collect unrelated changes to avoid repeating that ceremony. Improving deployment automation, access and verification can make smaller releases practical.
Follow one candidate through the process. Find the step whose overhead makes the team wait for more work to accumulate. Reducing that overhead can be more effective than repeatedly asking developers to make smaller pull requests.
- Can this increment be reviewed with a clear acceptance example?
- Can it run alongside the preceding version?
- Can the team identify its effect after deployment?
- What remains if exposure is disabled or the code is reverted?