Deployment automation vs. release management automation

In a previous blog, I compared deployment automation to build automation. I wrote about the differences between the build and the deployment process and I explained why different features are required from the respective automation tools. In this blog I will explain the difference between release management and deployment and why release management tools that claim they do deployment automation are actually doing something different. And why that is a good thing.

Let's start by defining release management. While Wikipedia might define release management as a relatively new discipline in the application lifecycle management space, it has actually been a part of ITIL v2 since its release in 2000. It concerns itself with the management of software releases. Courtesy of the ITIL Open Guide, the key activities of release management are:

1. Conduct release planning
2. Coordinate design, building and configuring of releases
3. Coordinate release acceptance
4. Conduct rollout planning
5. Coordinate release communications, preparations and training activities
6. Coordinate distribution and installation of releases
7. Provide management information about Release Management quality and operations

As you can see, release management is very much about managing the software releases, not about the actual work involved. Activity #6 is only the management of the actual deployment! As my colleague Robert van Loghem has described in his blog So what is a deployment really?, the key activities of deployment are:

• Installing applications
• Configuring installed applications for the target environment (test/acceptance/production)
• Configuring resources
• Configuring middleware components
• Starting/stopping/restarting server and applications

Not only are the activities different, different people are responsible. While, depending upon the organization, a release manager or project manager is responsible for the release management process, the actual deployment will be carried out by a system or application administrator.

Because application deployment is a complex process which tends to be unreliable and costly if handled manually, there is more and more pressure on companies to look at deployment automation product such as Deployit. That also explains why release management tools such as ThoughtWorks Go and Rational Build Forge are now being marketed as supporting deployment. But if you look closer at what they actually support, it boils down to just invoking a deployment script. And that is not what deployment automation is really about. It's about installing applications, configuring resources and restarting servers!

But this is not necessarily a bad thing: I would also not expect a release management system to include a build automation system because a release manager is not responsible for actually building the source code. I'd rather use Ant, Maven, or Gradle. In a similar vein, I'd rather have the release management system invoke a proper deployment automation system to perform the actual deployment.

That way, each tool can focus on the process it wants to support and provide the right feature set for the right target group. Release management system for release managers, build systems for developers, and deployment automation systems for system and application administrators.