 Release Management (RM) is essential to Application Lifecycle Management (ALM). There are also a number of essentials that are necessary for effectively implementing Release Management. RM requires effective processes and effective communication. The technical details can also make or break any release management process. This is one of the areas of configuration management that involves a great deal of risk and also demonstrates the value of effective Configuration Management practices. Read on if you want to know the essentials that you need to implement Release Management!
The Risk of Failure
Release Management involves a lot of risk and sometimes, considerable rewards too! I have seen projects fail because of poor release management and I have also been stopped by grinning developers explaining how their new procedures had helped them deal with a technical problem with speed and accuracy. What are the essentials of getting the release management process right?
Start at the Beginning
You always need to be careful to start at the beginning of the release management journey. Ask yourself the following questions. What are your goals? What are your risks? If your team is already performing this function, what is going right and what is broken? I always try to start at the beginning and take an honest look at the existing practices in place and whether or not they are acceptable in their current form. In even the worst situations, I have always learned at least one new practice that worked well and should not be impacted by my efforts to improve the release management process. My advice is to avoid fixing what is not broken. CM practitioners usually have to focus on the low hanging fruit and make good choices in terms of setting priorities and risks mitigated. I always start by ascertaining what is being done well and what needs to be improved.
Look for the Gems
There are usually a few pieces of low hanging fruit that I can grab and quickly show the value of good Configuration Management practices. It is easy to get bogged down as there is always lots of work to be done. If you pick the right battles and show some progress then you are more likely to get the support that you need to really make improvements in your CM. Start by focusing on the gems that will really show immediate value.
The One Hour Build and Deploy
Streamlining the build, release and deploy process is often my first choice for showing value. Sometimes, I have to live with existing Ant or Maven build processes that are not perfect. Usually, I automate all of the steps around the existing procedures and try my best to get us to the all-important one-hour build and deploy. I try to not get bogged down in making things perfect when it just does not seem feasible. (Some people would call this Lean, and it is, but I have been approaching my work this way long before Lean and Agile were popular terms in software process.) Making the right choices is essential for your success. Once you get some improvements in place, it is much easier to make the case that you need to devote a couple of weeks to refactoring the release management process for maximum impact. Be practical, pragmatic and lean in choosing which things to tackle first.
What Version is That?
I have seen fancy automated build procedures that lacked just one or two seemingly “minor” details. In one company it was the ability to identify the exact versions of the code being deployed and also automation to promote the code into production (and QA). The programmers writing the build framework had never read any of the standards and frameworks that describe how to do Configuration Management and, as a result, they missed the most basic of CM functions – configuration identification and configuration audits.
The Basics
You should always remember that CM starts with identifying what you have built and deployed (also called configuration items or CIs), controlling changes, tracing all CIs and auditing production (and QA) to verify that you have the correct versions in production (and they are functioning as expected). This is precisely where using IEEE/ISO/EIA standards and/or ITIL/Cobit/CMMI frameworks can help you define what is essential for your RM function. Using industry standards and frameworks is even more critical if you need to pass an audit in the future.
RM As a Service
I always call my group Release Management Services (RMS) because I want to focus on the fact that the RM function should be a service to the developers. This means that we want to support the developers and help make the software development lifecycle as fast and reliable as possible. It is essential that your RM group does more than just rebuild code and deploy it to production (or QA). My approach is to make development more effective while still enforcing all required IT Controls. This means that I focus on improving productivity and quality in all of my process improvement efforts.
What are the Essential IT Controls for RM?
Release Management enforces a separation of controls. Source code is permanently locked down, baselined and then rebuilt as a verification step. Code promoted to production (and QA) should only come from the independent build engineering function (often called Release Management). This addresses a critical requirement to guarantee that all source code has been secured and baselined. It also enforces keeping developers out of production which is a regulatory requirement in many organizations. There are other essential IT controls, but these examples are usually where I get started.
Who Authorized that Change?
Another Release Management Essential is traceability that can show exactly who authorized each change as well as exactly what was changed in a particular release. Some organizations may require a finely granulated tracking of changesets to workitems (e.g. defects) while others will just track a group of Requests for Change (RFCs) to a set of changes in a release. Whatever level of traceability makes sense for your company, you must be able to track changes at least by the release deployed to production (or QA). You also need to know who authorized the promotion of the release to production (or QA).
About the Author
Bob Aiello is the Editor-in-Chief for CM Crossroads and the author of CM Best Practices: Practical Methods that Work in the Real World, Addison-Wesley Professional ( http://cmbestpractices.com). Bob is the Executive Director of Practices and Services at Configuration Management, Inc. ( www.cmi.com) where he specializes in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long-standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he has served as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at bob.aiello@ieee.org or link with him at http://www.linkedin.com/in/bobaiello
Trackback(0)
Comments 
Write comment
 |
Behaviorally Speaking 
TrackBack URI for this entry
Subscribe to this comment's feed