Release management

From Wikipedia, the free encyclopedia

Wikibooks has a book on the topic of

Release Management

Release management defines the mechanisms of building and releasing software, and is included as a component of the Service Support Set in ITIL. The practice of Release Management continues to evolve while being applied to complex distributed software services such as in the SOA realm.

Release Management is proactive technical support focused on the planning and preparation of new services. Some of the benefits are:
• The opportunity to plan expenditure and resource requirements in advance
• A structured approach to rolling out all new software or hardware,which efficient and effective
• Changes to software are ‘bundled’ together for one release, which minimises the impact of changes on users
• Testing before rollout, which minimises incidents affecting users and requires less reactive support

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.

[edit] Introduction

The goal of release management is to protect the live environment. Release management controls the release of new configuration items into that environment.

This can apply to software and hardware. The process is more than creating a new version or update of a program. When a new release is needed there are various steps to follow. Gathering the requirements and gathering the dependencies with the existing components must be checked out in advance. After that a new version can be built, tested and the release can be prepared. Finally the release that is brought to the operations environment consists of a software file ready to be installed, complete with manuals. The company itself also saves the design and testing documents. A release rollback plan is also available on standby to safeguard against surprises during the release, or non-acceptance by the end users.

[edit] History

In the past it was common for a single organization to develop a software system. Simple configuration management was used to support software release management. When a new system needed to be released, all components were frozen. Users were notified how to obtain the new release. The Internet changed this process.

With the Internet, new possibilities arose. FTP sites and Web pages give easy access to customers. This provides new release possibilities, making the software available to the whole Internet, to provide information about products, and to distribute both free trial versions and licensed versions of the software.

[edit] Challenges

Many new challenges have arisen in recent years. Software may be developed by geographically dispersed teams, and development may be distributed amongst fragmented teams and even across different companies. Designers must take pre-existing components into account, and the dependencies between them, especially with geographically dispersed development teams. Documentation must describe the software accurately. One of the most important aspects of this is the documentation of interdependencies with other systems. Locating, receiving and tracing various components can result in errors. Hoek (1997&2003) describes that software release management forms a bridge from the organizations where components are authored and released, to the organizations where the components are assembled into an application.

[edit] Benefits

Improvements are necessary within software to keep up with requirements, bugs and technology. When one uses release management, a structured process, several benefits can be found over ad hoc programming of improvements. Release management:

Gives the possibility to plan resource requirements in advance
Gives a structured approach, leading to an efficient and effective process
Changes are bundled together in a release, minimizing the impact on the user
Helps to verify correct usability and functionality before release by testing
Provides version control and central storage, which ensures correct version use.

[edit] The process

The release management meta process consists of several steps.

[edit] Gathering and description

When a new release is prepared, requirements are gathered. These are for example improvements that are needed to fix the current product. A parallel step is to look at the dependencies. Programs often consist of many modules that depend on each other to work. Changing one will affect the other. Once the requirements and dependencies are known, the next release process can be planned. This planning consists of what steps need to be taken, the time constraints etc. In figure 1 the entire process is visualized, using the meta modeling technique.

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).

[edit] Release Building

When the requirements, dependencies and planning are known, the building process of the new release begins. The first step is to design the new release. This can be done with the use of various software development techniques for example UML. The design is worked out into code in a software language (e.g. Java, C#, C++). The pieces of code, classes etc. are joined together, compiled into working subsections, and finally put together in a working program, a build.

[edit] Acceptance Test

When the build is ready, it is sent to a testing department for further acceptance testing, checking the build against the testing standards. The program is reviewed to verify if it works correctly and lives up to the requirements and dependencies. During this time the entire process is documented to serve as a future knowledge base. After a final verification of the program the testing standards are updated.

[edit] Release Preparation

Once a correct, verified release has been achieved, it is prepared for release to the production environment. The release is packaged, meaning preparing a final product to be sent to a specific customer. This can be an Internet download, a CD, or a specific language etc. A final step is the verification of this package against the requirements resulting in audit reports. These audit reports give a last verification before the entire package is released.

[edit] Release Deployment

The deployment itself is getting the release to the customer and implementing it.

[edit] Alternate process

Outline of the basic steps that constitute a "Release Management" process

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.

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.

[edit] Patch Management

Patch Management Cycle

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 standd in a formal Release Management operation.

[edit] Software Development Lifecycle

Software Development Lifecycle

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).

[edit] Quality Assurance

Quality Assurance

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.

[edit] 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.

[edit] Software Configuration Management

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.

[edit] 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.

[edit] Example

To make the release management process clear, this example describes a new release of a text editing program. The first step is to gather the requirements of the new release. This consists of technical error reports, bugs and user feedback and a request for new functionality. The dependencies are mainly the previous used programming with its limitations due to programming language, structure, team composition, platform and other sorts of limitations. When both are known the process can be planned. This consists of the steps to be taken, how the bugs are going to be fixed, how the new functionality is going to be added and in what timetable. After the gathering and description is complete, the building begins. Programmers work on designing, coding, and compiling to create a new release for the text editor. When this build is complete it is tested by a test team, trying out the new version of the text editor. They review, document and verify the program to see if it complies with the initial requirements and standards. If accepted, the text editor is packaged, in this case the company’s internet site, where the program can automatically download the new version, as soon as the user has been notified and accepts. This phase is described as deployment.

[edit] Release manager

The need exists for a resource to oversee the development, testing, deployment, and support of these systems. This resource must have a general knowledge of every aspect of the software development lifecycle, various operating systems and software application platforms, together with an understanding of the different business functions and perspectives. Release Management addresses this need.

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
Organizational Politics

[edit] 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:

A High quality Releases
Repeatable process for deploying Releases
Quick and accurate Release builds
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.

[edit] See also

[edit] References

Beck, B., Fowler, M. (2000). Planning Extreme programming, Addison Wesley.
Erenkrantz, J. R.(2003) Release Management Within Open Source Projects. In: Proceedings of the 3rd Open Source Software DevelopmentWorkshop. Portland, Oregon, USA, May 2003, S. 51–55.
Hoek, A. van der, Hall, R. S., Heimbigner D., Wolf, A. L. (1997) Software release management, Proceedings of the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineering, p.159-175, September 22-25, Zurich, Switzerland.
Hoek, A. van der, Wolf, A. L. (2003) Software release management for component-based software. Software—Practice & Experience. Vol. 33, Issue 1, pp. 77-98. John Wiley & Sons, Inc. New York, NY, USA.
Krishnan M. S., (1994). Software release management: a business perspective, Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research, p.36, October 31-November 03, 1994, Toronto, Ontario, Canada

[edit] External Links