Release Management: Where to Start?
Many read the full-fledged description of RM in a book on ITIL and become convinced that it is too esoteric and advanced a concept for them. Such is not the case, though, because most IT organizations already boast many RM-related activities; they are simply located in other groups and other names.
1. Patch Management. Many IT shops, especially those with extensive Microsoft platform deployments have developed elaborate processes for Patch Management to the Production environment. Their scope usually includes operating systems software, database upgrade, and even firmware upgrades to hardware components (e.g. storage arrays and network switches). Figure 2 below shows a standard Patch Management deployment lifecycle, which contains many tasks found in a formal Release Management operation.
Figure 2: Patch Management Cycle
2. Software Development Lifecycle (SDLC). SDLC describes the complete set of processes that govern development, testing, delivery, maintenance, and sun-setting of application code.
Whether an organization is using a formal SDLC methodology, a framework such as Carnegie Mellons Software Engineering Institute (SEI) Capability Maturity Model (CMM) or ITILs Applications Management, or a systematic code deployment scheme like IBM/Rationals Unified Process Framework (RUP), they likely have evolved a set of procedures to govern the movement of code from one operating environment to the next (i.e. Development to Testing to Quality Assurance to Pre-Production to Production).
Figure 3 below shows a generic Applications deployment lifecycle with the functional testing step capturing the final deployment (from pre-Production to Production) event, which itself contains the majority of Release Management-like activity.
Figure 3: SDLC Management Lifecycle
3. Quality Assurance (QA). When organizations lack a formal pre-Production environment (usually due to a lack of funds necessary to maintain a physical and logical duplicate of Production), much Release Management activity can be found in the formal QA discipline. Figure 4 at right depicts the set of interdependent activities which are required of most QA departments irrespective of whether hardware or software modifications are undergoing test. In these cases, a significant portion of what is known as QA work would be re-labeled as Release Management and managed accordingly.
Figure 4: Quality Assurance Activities
4. Change Management. Many, if not most, ITIL implementations start with Change Management (so as to "stop the bleeding" in IT Operations). Over time, the process design and policies begin to take on more than just Change Control disciplines. Organizations are tempted to avoid launching "ITIL another process" and just amend the existing Change Management guidance to include pre-Production testing requirements prior to authorizing a Change.
The results of this approach are predictably poor. Changes fail in Production, testing blurs with deployment, no risk assessment techniques are used, and nothing exists to arbitrate access to pre-Production resources. Fingers begin to point and accountability is blurred because the Change Manager is trying to accommodate the dictates of a Release within the confines of a Change Management system.
Organizations with undifferentiated Change Management processes similar to this will see improvements shortly after extracting the Release-related activities.
5. Software Configuration Management (SCM). SCM refers to tools that manage application code and enable modifications to be released to Production. Oftentimes, these tools have been in place for long periods of time and elaborate procedures have been built up around them that resemble, quite closely, many Release Management disciplines. Some SCM tools are anticipated in an SDLC approach, but others are legacy products that pre-date adoption of an SDLC methodology.
Organizations with active SCM systems and supporting databases should inventory the formal policies and informal practices which have grown up around them to better appreciate how much Release Management-like activity they contain.
6. Advanced Testing Groups. Other organizations that lack formal pre-Production environments may yet boast advanced testing facilities and have staff dedicated to the process of vetting future technology. Such groups are typically found in enterprise IT operations and their mandate can stretch far, especially if technology deployment is considered a strategic differentiator by the business.
Although the purpose of these Advanced Testing groups is to look at components, systems, and sometimes applications that are not yet in Production, they usually are not formally linked to the Change Management process. Nevertheless, they tend to develop formal procedures to govern access to facilities, development of rollout and rollback plans, application of testing matrices (regression, unit, performance, exception, etc.), and training of personnel. Much of this can be re-purposed for a Release Management process implementation.