Home 
CM Journal Articles Release Management
CM Journal Articles Release Management
|
Conventional software development tends to define Release Management as either the deployment of product to a production team or download area, or the creation of releasable product. ITIL considers Release Management to be the entire process of developing a releasable product. Each group that tries to define the term is generally the sponsor or proponent of a process, a methodology or a tool suite. There is really nothing wrong with this phenomona; it is the way words evolve in any language. What gets to me is that we frequently complain about the confusion this causes, and then proceed to do it ourselves. In the past, I have presented several articles dealing with software development lifecycles in general (see figure 1) and Release Management in specific.  Figure 1
From a Software Engineering perspective, I show Release Management as the tail-end process that occurs after Build Management produces product and Quality Control has tested and approved it. There are generally other approvals that need to occur between when a release candidate is produced and when it is actually released. Once all approvals have been received, the product is, in our case, modified to contain the actual release identifier and date, packaged along with supplemental documentation and delivered to a controlled production staging area where it can be pulled by the end-customers. The actual deployment is trivial compared to the task of making sure all of the approvals are in place and that all of the pre-release checks have been performed. In contrast, Benny Westaedt from Serena presented a view of ITIL’s Release Management in a recent webinar that indicated process steps of Create Release, Add Changes, Add Release Tasks and Development, Lockdown the Release Content and finally Deploy to UAT and Production. He went on to state that this sequence has Process Dependencies on Change Management, Defect Tracking, Resource Management, Test Management, Configuration Management Database, Version Management and Build Management. While there was a fair amount of Serena tool-specific information in the webinar, what I came away with is that there is yet another viable definition of Release Management which, taken by itself, is a reasonable definition. I guess it all goes back to what one considers a Release to be. Then there are the Automated Lifecycle Management (AML) and Application Lifecycle Automation (ALA) tools that allow the release mechanism to be integrated into a workflow framework. These tools allow for the capture of electronic signatures along with approval or deny status information and prevent any actual release from occurring until all pre-conditions are satisfied. In the meantime, it is almost 104 Fahrenheit, we may have a rolling blackout this afternoon and I was just informed that, since everything is looking good, I will need to perform an early release around 5 P.M. today (Friday). I hope your July is a good one… Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Users Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).
Set as favorite
Bookmark
Email this
Hits: 6213 Trackback(0)Comments (5)
|
This month's article is a short one, primarily because I am tied up in an accelerated series of releases. Ironic, isn't it.
TrackBack URI for this entry
Subscribe to this comment's feed |
... First, thanks for the comments. I agree that ITIL most likely views things from more of a service persiective (see the closing paragraph), but I can see its application to classical software development as well. We have to keep in mind that the product is the main thing - this is where the money comes from. In terms of Product, a release can be considered a revenue source. This makes it really important, so managing releases becomes critical. One of the reasons that I don't think we treat software releases as the primary focus from either a development or an SCM standpoint is that we often are working on changes that may or may not become part of a specific release. Even more so in an Agile development model. This is why I consider Change Management to be a composite of Version Control and DIET (Defect, Issue & Enhancement Tracking) where it is the Process that governs how and when a change is integrated into a potential release (and when and why a change is backed out of a potential release). I consider Build and Release Management to take the results of Change Management (updated codebase, documents, etc.) and produce testable deliverables. ITIL started out trying to version and track changes to sets of deliverables, along with where they are installed and how they are configured. Even though there are great similarities, ITIL really picks up where SCM's Release Management leaves off. |
Amit Gupta
said:
|
... I think the reason ITIL has created confusion around the term "Release Management" is because of the way it views "IT as a service" which essentially means that Release is no longer limited to Software Release but is also concerned with Assets, Training and everything that goes into "using" a particular release rather than just "making it available" |
Geoff
said:
 |
... Ben, I agree with your statements in reference to that ITIL sees the 'release' to extend further into the 'change' bailiwick. In ITIL's defense: It is the "IT" Infrastructure Library. I am still curious as to whether a corrosponding "Business Infrastructure Library" framework will ever be built  (right now I suggest to our business areas to take the ITIL foundation and use what they can) I would also note that ITIL is a framework - a starting point. Given the low level of maturity in many organisations I am happy to have a starting point. We can always improve.. but we need to start somewhere. (quoting Demarco) "You can't control what you can't measure." Right now just being able to measure is a very good start. First step out of chaos. Speaking of ITIL: no doubt you've read about the "ITIL Fairy". I totally agree with the Vendor problem. It is a real pity that software vendors feel the need to use language to try and change what does not need to be changed. In relation to this; my head hurts trying to read the latest Endevor documentation where they have replaced "Endevor" for "CA SCM for Mainframe - the mind boggles. |
Ben Weatherall
said:
|
... I have my own definition of Change Management and Release Management. Change Management is the process of controlling and tracking changes. Depending on your focus, a change may be file based or "change set" based. In other words, if you are looking at "Change" from a Version Control perspective, it is controlling who, when, why, etc. a file was changed. If you are looking at "Change" from a DIET perspective, it is what elements were changed, by whom, why, etc. that implement the change specified in the DIET record. It is this last that is the more common view of "Change Management." My definition of "Release Management" is the control and tracking of all Changes that are aggregated into a Release of a product. This release may be to a testing organization, to an internal customer (for use or validation/demo) or to production. Since this definition relates to changes, it too can be viewed from the perspective of either files/elements or Change Sets; and again it is most common today to use the aggregate of Change Sets as the preferred definition. My concern is that ITIL turns this upside down and treats the process from initial element versioning through final release as "Release Management." Their view is that a Release is the important thing and that all else constitutes steps to get to that point. While I can understand this definition, I believe that it causes confusion. The ITIL seems to have taken the IT viewpoint and terminology and tried to integrated Development and CM terms into it. Since there is not a one-to-one match, they went with their own definitions. If one comes from an IT background, it makes sense, but if one comes from a CM background it doesn't. And of course, the reverse is true too. I will state that CM tool vendors contribute to this confusion as well when their Marketing departments try to distinguish their products from their competitors' products by using buzzwords that try to change, overload or otherwise modify the meaning of CM Process/Role terms. Feel free to respond... -Ben Weatherall |
Geoff
said:
|
... I have found that the most confusion (deliberate or not) is distinguishing Change Management from Release Management. When you ask the question 'are you rejecting what the change is, or are you rejecting how, when and where the change is going to be deployed' it is possible to start a thought process that divides a Change from a Release. It is surprising how often people speaking about 'change management' mean 'release management' or a combination of both. Just a thought. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
