Normal releases are consistent and predictable. Scheduled releases benefit developers, testers, support and PR. Unpredictable releases can cause communication problems, stress and fatigue. Those can lead to poor software quality and developer turn-over.
Sometimes we need to deal with unexpected issues that can’t wait for a normal release. Some examples include:
- High volume crashes
- Broken functionality
- Security issues
- Special date-based features
Anyone should be able to suggest an off-cycle release, so make sure there’s a straightforward, simple process for doing it. Identify that a special release is really necessary. Maybe the issue can wait for the next normal release. Consider using an approval process to decide if the release is warranted. An approval process creates a small hurdle that forces some justification. An off-cycle release is not cheap and has potential to derail the normal release process. Don’t put the normal release cycle at risk.
Some things to keep in mind:
- Clearly identify the need. If you can’t, you probably don’t need the release.
- Limit the scope of work to just what needs to be done for the issue. Be laser focused.
- Make sure the work can be completed within the shortened cycle. Otherwise, just let the work happen in the normal release flow.
- Choose an owner to drive the release and a set of stakeholders that need to track the release.
- Triage frequently to make sure the short cycle stays on track. Over-communicate.
- Test and verify the code changes. By limiting the scope, you should also be limiting the amount of required testing.
Be ready for the unexpected. Get really good at it. The best releases are boring releases.
Also published on Medium.