Reducing Risk: Frequent Releases vs Quiet Periods
Agile methods encourage us to frequently release software into production. However, there is a force pulling in the opposite direction: a desire for gaps between changes, or "quiet periods".
for frequent releases:
- Business value delivered sooner.
- Each release is a smaller change.
- Release process becomes well practiced and understood.
- No new software defects can be introduced during a quiet period.
- If each release requires downtime, keep it to a minimum by making fewer releases.
- If you are worried about introducing bugs every time you make a release, maybe you need to invest more in automated testing, which tests both the code to be released, and that it has been deployed correctly in production.
- If each release requires downtime, maybe you should automate as much of the deployment process as possible, so that the downtime is shortened. Ultimately it might be worthwhile changing the architecture so that a release can be completed without any downtime at all.