Release Management

Release Management is the relatively new but rapidly growing discipline within software engineering of managing software releases.

As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.

The need therefore exists for dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems. Although project managers have done this in the past, they generally are more concerned with high-level, "grand design" aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects. Release Managers (aka "RMs") address this need. They must have a general knowledge of every aspect of the Software Development Lifecycle (SDLC), various applicable operating systems and software application or platforms, as well as various business functions and perspectives.

A Release Manager is:
* Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.

* Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.

* Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).

* Coordinator – utilized to coordinate disparate source trees, projects, teams and components.

Some of the challenges facing a Software Release Manager include the management of:

* Software Defects
* Issues
* Risks
* Software Change Requests
* New Development Requests (additional features and functions)
* Deployment and Packaging
* New Development Tasks

Where should you start with Release Management?

In its full expression, Release Management can be a complex topic, so any attempt to cover it in a single entry would be a mistake. This outline will provide a “lay of the land” in terms of common day practices and some insight on what makes a good ITIL based Release Management process function effectively. In writing this outline the author assumes the reader has a basic understanding of the related IT Service Support process Configuration, Change, Incident, and Problem Management. The remainder of this outline will fill in the details about the usage and adoption of Release Management for enterprise organizations.

Basic Flow of Release Management

Figure 1 below outlines the basic steps that constitute a “Release Management” process. In this diagram the movement of a Release from left to right depicts progress through various environments (Development, QA and Production), each of which is a distinctive operating environment that progressively seeks to replicate Production conditions and functions separately from the other although they leverage common methods for promoting a Release between them. It is important to note that Figure 1 below does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.

Release Management is already in your organization – “Just Look for it”

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.

One of the first tasks, especially when conducting a process Maturity Assessment, is to look at the following six areas, which can overlap with each other but which also contain many aspects of RM, although in varying degrees:

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.

2. Software Development Lifecyle (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 Mellon’s Software Engineering Institute (SEI) Capability Maturity Model (CMM) or ITIL’s Applications Management, or a systematic code deployment scheme like IBM/Rational’s 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.

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.

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. Often, 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.

Getting to ExecutionMost organizations are pleased to learn that they are already engaging in some form ofRelease Management activities. The next section outlines where to look for releaseinformation and what key success factors to align with for Release Management activities.Figure 5 below outlines the sources and critical success factors that, together, lead to awell-executed Release Management program. Follow a start simple methodology bylocating the sources and consumers of releases. The idea here is to go as far “up stream” aspossible to find out where a Release may begin. Using this approach enables you to findwhere processes exist.

Sources for Success

One of the key paths to success in Release Management is being able to identify what “causes” a Release also known as its original source. Know this enables you to make some critical decisions.

# What business value does the release have? What is its priority
# What systems or applications will be affected by the Release?
# Who will be affected what are the expected results?

Table 1 below depicts the various roles that typically generate the need for a Release. If you find that releases are being “sourced” from many different areas and not through a common process, it is best to start by resolving this issue. In many organizations this is called Demand Management and is commonly referred to as Program/Project management.

Looking at the table there are several places a release can originate from. Each of these areas will have different wants and needs for your Release Management process. Use the table below to speak with each of the functional areas within your company about release management. Ensure that their idea of Release management is congruent with the process design you have formulated.

Often it is helpful to bind release management to an existing project management process. This enables the business to see what is “inside” of each release. Those choosing this path should be cautioned not be to concerned with having a Release for each project. Rather, begin by focusing on the features and functionality to be delivered.

Conclusion

As illustrated in the preceding paragraphs Release Management is not a turnkey process; it relies upon and feeds other processes. Though some organizations spend significant efforts building a Release Management process from scratch, others find more success in leveraging what tasks and abilities they already have and merely redirecting and formalizing them.

In getting your arms around Release Management, start with identifying your goals and ranking their priority. An example might be:

1. A High quality Releases2. Repeatable process for deploying Releases3. Quick and accurate Release builds4. Cost-effective Releases

The goals above are not much different than those you may give to a construction contractor for a construction project. Keep the rule of 2 in mind “You have three attributes to choose from for your project Quick, Cheap and Quality.” You can choose any two in regards to Release Management, choosing all three will not yield good results.

Embarking on a Release Management project is not for the faint of heart. Failing to find a dependable project sponsor will be your ticket to defeat. If you find that you do not have any Subject Matter Experts (SME) in the field of Release Management this is not the time to go it alone. Anyone with an ITIL background helping with Release issues should also be able to demonstrate previous experience with the Software Development Life Cycle, QA disciplines, or Software Configuration.

Some final tips:

# Persistence does payoff; often an organization starts a “Release Management” project as a response to a reoccurring issue or a high profile issue and, even though, programs of this nature usually prove ineffective of their own, if you are persistent you can experience success on a broader approach.
# Chose incremental steps and measured progress, this allows you the ability to select easily consumable goals and establish a baseline to measure from.
# Highlight achievements, don’t allow Release Management to be maligned as non-value or an impediment to promotion to production.
# Place emphasis on time saved and Release measurement be sure to develop a good training and communication plan.
# Don’t forget to post accolades they are sure to come as you provide structure and control where none existed before.

References

[http://books.google.com/books?id=BR9ppkdnIrQC&pg=PA193&lpg=PA193&dq=release+manager&source=web&ots=M-ejUHsZW6&sig=zwuyg_J60Xwcr77VXjReliQ5WEI&hl=en&sa=X&oi=book_result&resnum=9&ct=result Project Management: Best Practices for IT Professionals]

[http://www.itsmwatch.com/itil/article.php/3680776 Release Management - Where to Start?]

[http://books.google.com/books?id=zUTiHzyyDLwC&pg=PT273&lpg=PT273&dq=release+manager&source=web&ots=dJwEC7lz_Z&sig=PXBGdOj_4BURbb98N9RpNk1xf18&hl=en&sa=X&oi=book_result&resnum=1&ct=result Managing Software Projects By Frank F. Tsui]

Release Management Tools

ee also

*Build automation