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.

for quiet periods:

• 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.

My approach for dealing with this conflict is to attack the (perfectly reasonable) advantages of quiet periods so that they become less important. For example

• 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.

Of course you should strike a balance. I like the idea of releasing into production every half hour, as flickr is supposed to, but in reality few enterprises can invest enough to make this practical. I think releasing once a day is often achievable though.