How to release software

The wrong way

• Have no master plan
• Practise nothing ahead of release day
• Prepare only on release day
• Build release packages on release day
• Have dissimilar production and test environments
• Hand edit configuration during release
• Keep no backups of previously working configuration
• Use trial-and-error to fix configuration

The right way

Do the opposite of everything done the wrong way. Wasn't that simple?

Some elaboration

As much as possible, clone the production environment to your test environment. Any number of weird, unexpected, troubling problems will crop up. Fix them all. Do not release if your test environment is not pristine.

Make complete release packages as early as you can, and release them to the test environment just as you would to production. Do not release if you cannot deploy smoothly.

Keep the entire test environment under release control: everything including binaries, symlinks, logs. Do not release if there are uncommitted changes; do not release if you do not understand the changes since last release.

Above all, have a plan! Discuss it with your team, assign roles and check that everyone understands what they do. Practice the release; practice rollback should something break. Obey the Scout motto: Be prepared.

Postscript

What is the penalty for the wrong way? Eight hours spent with your cell phone glued to your ear during vacation while you fix a slow-moving train wreck of a release. Your family will thank you for the right way.

UPDATE:

And in the comments:

• Release very seldom with a big bang approach

This is very apropos. Management prefers a few large releases to smaller, more frequent releases. My opinion is that large releases look better to upper management (demonstrates you can deliver large widgets) even though it hurts in cost and quality.