This post is from the XebiaLabs blog and has not been updated since the original publish date.
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:
- Conduct release planning
- Coordinate design, building and configuring of releases
- Coordinate release acceptance
- Conduct rollout planning
- Coordinate release communications, preparations and training activities
- Coordinate distribution and installation of releases
- Provide management information about Release Management quality and operations
- Installing applications
- Configuring installed applications for the target environment (test/acceptance/production)
- Configuring resources
- Configuring middleware components
- Starting/stopping/restarting server and applications
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 XL Deploy. 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.
XL RELEASE FREE TRIALXL Release makes it easier to manage complex, multi-level and interdependent software release pipelines, no matter where you are in your Continuous Delivery journey. Sign up for a free 30-day trial and get better control, visibility, and automation for your release pipelines today.