Software Release Management - A Problem Overlooked (Part 1)

(Originally published by me on www.servicevirtualization.com)

This is the first of two parts discussing the problem of software release management and how automation can be properly used to alleviate these problems.
 
ITIL has Release Management. There are also Six Sigma and CMM. These are all process-oriented "libraries" that deal with the development and release of tangible products or business services.  Yet ask any application development professional if any of these deal with the actual problems of software release and they will unanimously answer "no."

After CA Technologies announced that it had acquired Nolio, the leader in software release automation, I started taking a closer look at the actual problem that Nolio addresses.  And what I found is this: current literature on software release addresses the process-related problems but none has yet discussed how to address the realities of the actual movement of software from one environment to the next.

Remember: Environments Vary

For example, take a look at this excellent case study written about a British telecommunications provider. In the article, the authors describe seven steps they took to turn around the Release Management process at their client. And even though they give a nod to automating the deployment of the software (step 5, entitled Automate and standardize as much as you can), they gloss over one important point in software release.

That point is this: environments vary. A single server might be fine to house a web server, application server, and database server for a single developer, but it'll never do for QA, Performance Testing, and Integration Testing, much less UAT or a Disaster Recovery environment or even Production. And so the process of deployment requires uniquely designed scripts that are unto themselves applications that must be tested and validated for correctness. Ultimately, they are complex enough to require maintenance, and in the event that the infrastructure architecture changes beyond the trivial, changes must be coded, tested and validated again.

Do you want fault tolerance, i.e. rollback capabilities? You need to code that. Do you want auto-configuration of your WebSphere environment? You need to code that too. In fact, for most operations beyond simple file transfers, administrative programs need to be invoked with complex configuration parameters that vary from environment to environment.

Survey: Most Respondents Unhappy With Release Processes

How bad is the problem?  According to a 2008 study by IDC, 30 percent of all defects are caused by incorrectly configured application environments. For the remaining 70 percent, things don't look much better. Forrester's Q4 2010 Global Release Management Online Survey suggested that the time needed to roll out a single change to an application was between a day and a week for 39 percent of respondents. For 11 percent of respondents, the time was between a week and two weeks. For 18 percent, it was two weeks to a month.

Here are some other eye-opening statistics from the Forrester survey:

• 64 percent of respondents were dissatisfied with the level of automation in their software release processes.
• 54 percent of respondents were dissatisfied with their ability to recover in the event of a problem either during release or with the application.
• 50 percent of respondents were dissatisfied with the speed of each iteration of the release process.

With the need to code individualized and highly tailored scripts for each application per environment, it should be no surprise that the numbers are so high. In fact, when you consider that it takes a developer-class professional to author and test these release scripts, you have one of two problems that ultimately need to be considered:

1. You are forced to split the time of a developer on the application team so that part of their time is dedicated to creating and maintaining these scripts, or;
2. You are forced to hire someone, paying them the same FTE rate for the sole purpose of release management.

With operating budgets as tight as they have been since the global meltdown in 2008, it is my suspicion that option 1 is the more common choice. This detracts from application quality as the time the developer should be spending writing new code or fixing defects discovered during test is spent instead doing operational work.

In Part 2 of our discussion, I'll cover how Nolio addresses the problem.