You shouldn’t hate releasing code

You shouldn’t hate releasing software. Especially if your software is a Web site, not something that comes in an installer or disk image. And yet it’s really easy to get into a state where releases suck. I think that the thought of making releases suck less is the one of the main attractions of continuous deployment.

Here’s a partial list of reasons why releases can suck:

1. Releases require downtime. When downtime is required, releases have to be scheduled far in advance, and the release schedule starts to affect other things. It becomes harder to work productively near releases (especially if your source code management is not up to par), and usually downtime releases must occur in the middle of the night or on weekends.
2. The prerequisites for each release are not well documented. I’ve been in situations where the release time rolls around, everybody is online and ready, and the proper build wasn’t tagged. Or the production build doesn’t have the production log settings (a mistake I personally have made a number of times). Or the list of database changes that need to be made wasn’t prepared. Or the new build is deployed and the database changes weren’t applied and so you have to start over.
3. Releases are too large. At some point, releases become large enough that nobody really knows everything that a release impacts. At the smallest level, a release includes a single bug fix. It’s easy to understand the possible risks involved with such a release. A release that includes hundreds or even dozens of changes can become unmanageable.
4. Releases are insufficiently tested. Nothing’s worse than everyone waiting in a holding pattern while developers furiously bang away to fix a bug that slipped into the release and was only found when the code went out.
5. People don’t have enough to do. In many cases, lots of people have to be available for a release, but they spend a lot of that time waiting for things to happen. Frustrating.
6. Releases take too long. Sometimes the release process is just too cumbersome. Getting releases right is important but ultimately the actual release process is just a form of housekeeping. The more people that are involved and the longer it takes, the more resources are used that could be better applied to something else. Plus most of the work associated with a release is really boring.

My theory is that releases don’t have to suck. The releases I’m involved with exhibit few of these problems, but my goal for 2010 is to eliminate the remaining problems to excise the remaining suckiness.

If you liked this, you may also like my post When deployments go wrong from a couple of years ago.