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 are 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 release management meta process consists of several steps.
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).
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 programming 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.
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.
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.
The deployment itself is getting the release to the customer and implementing it.