Release Management method

From Wikipedia, the free encyclopedia

Release management describes the practices for bringing software items to the operations environment, its users. It contains both implementation and distribution activities.

Contents 1 Introduction 2 In the past 3 Nowadays 4 Challenges 5 Benefits 6 The process 6.1 1. Gathering and description 6.2 2. Release Building 6.3 3. Acceptance Test 6.4 4. Release Preparation 6.5 5. Release Deployment 7 Example 8 Release manager 9 See also 10 References 11 Appendix

[edit] Introduction

Release management is the process of releasing new software items. 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.

[edit] In the past

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.

[edit] Nowadays

With the Internet, new possibilities rose. 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 arose the last few years. Many times, software is no longer developed by one central team but distributed among teams and even among companies. Designers must take into account the pre-existing components, and the dependencies between them, especially in geographically displaced development teams. The software must be described accurately. One of the most important aspects are the dependencies 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] 1. 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.

[edit] 2. 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. .NET). The pieces of code, classes etc. are joined together, compiled into working subsections, and finally put together in a working program, a built.

[edit] 3. Acceptance Test

When the build is ready, it is sent to a testing department for further acceptance testing, checking the built to the testing standards. The program is reviewed to verify is 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] 4. Release Preparation

Now having a correct, verified release, it is prepared to be released 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] 5. Release Deployment

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

A description of all the concepts can be found in the appendix in table 1. A description of all activities can be found in the appendix in table 2.

[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 gathering the requirements of the new release. This consists of technical error reports, bugs and user feedback and a request for a 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 built 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 a:

• Facilitator – a release manager serves as a liaison between different business units to guarantee smooth and timely delivery of software products or updates.
• Gatekeeper – a release manager “holds the keys” to production systems and takes responsibility for their quality and availability.
• Architect – the release manager helps to identify, create and/or implement the processes or products to efficiently manage the release of |code.
• Server Application Support Engineer – the release manager is often expected to help troubleshoot problems with an application.

[edit] See also

• Release Management
• Process Lifecycle management
• Change management
• Configuration management
• Software Release Decisions.

[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

Reference websites:

Microsoft TechNet, Microsoft Solutions for Management: Release Management March, march 26h 2004. [online knowledge database] viewed on February 14th 2006. Available through: http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfrelmg.mspx

SM Foundation: ITIL Release Management, create date unknown. [online IT infrastructure library], viewed on February 8th 2006. Available through: http://www.itil-itsm-world.com/itil-5.htm

[edit] Appendix

Table 1: List of Concepts

Concept	Explanation	Source
RELEASE	The release consists of a software item, (most of the time a new version of a program), ready to be exported to the operations environment.	Van der Hoek 1997&2003
REQUIREMENTS	Requirements describe the standards to which the new release much comply and the functionalities.	Van der Hoek 1997&2003
DEPENDENCIES	The dependencies describe what the new release must comply to.	Van der Hoek 1997&2003
RELEASE SCHEDULE	The release schedule consists of a planning how the release process will be completed.	SM Foundation 2006
DESIGN	The design is a (physical) description of how the release should work.	Beck 2000
CODE	The code is the computer language describing the program.	Beck 2000
COMPILED MODULES	Compiled modules are pieces of code, classes etc. joined together into working subsections.	Beck 2000
BUILT	A built is a working program consisting of the compiled modules.	Beck 2000
RELEASE REVIEWS	Reviewing or testing is the process of verifying the correct working of the built and lives up to the requirements.	Erenkrantz 2003
SECURE LIBRARY	The steps of the design, dependencies, constraints and explanations are documented as a future knowledge base.	SM Foundation 2006
TESTING STANDARDS	One of the last steps is to verify the new release and to update the testing standards for the new release.	SM Foundation 2006
RELEASE PACKAGE	The package will be verified against the requirements of specific customers, resulting in audit reports.	Erenkrantz 2003
AUDIT REPORTS	The audit reports give a last verification of the release.	SM Foundation 2006

Table 2: Activity table

Activity	Explanation	Source
Gathering requirements	When a new release is being prepared, requirements are gathered, e.g. what improvements are needed comparing to the previous release.	Van der Hoek 1997&2003
Gathering dependencies	Programs often consist of many modules that depend on each other to work. Changing one will affect the other.	Van der Hoek 1997&2003
Release planning	The next step is to plan the complete release process. What needs to be done, when, etc.	Van der Hoek 1997&2003 Microsoft TechNet 2004
Design	When it is clear what needs to be released, what the dependencies are and the time constraints, the design of the new release begins. This can any technique e.g. UML.	Beck 2000
Coding	After the design of the new release the actual coding is done. (e.g. .NET code)	Beck 2000
Compiling	The pieces of codes, classes etc. are joined together into working subsections.	Beck 2000
Built	The working subsections are put together in one working program.	Beck 2000 Microsoft TechNet 2004
Reviewing	Reviewing or testing is the process of verifying the correct working of the built and lives up to the requirements.	Microsoft TechNet 2004
Documenting	The steps of the design, dependencies, constraints and explanations are documented as a future knowledge base.	Erenkrantz 2003
Verifying standards	One of the last steps is to verify the new release and to update the testing standards for the new release.	Microsoft TechNet 2004
Assemble package	Finally the release will have to be packaged, meaning	Erenkrantz 2003
Verifying	The package will be verified against the requirements of specific customers, resulting in audit reports.	Microsoft TechNet 2004
Release deployment	The deployment itself means getting the release to the customer and implementing it.	Krishnan 1994 Microsoft TechNet 2004