The CMDB is updated and referred to throughout the Release Managment process concurrently with updates to the DSL. It should contain the following information in support of the Release Managment process:
The software and or hardware components that compromise a new Release of an IT service should be assembled in a controlled manner to ensure a reproducible process. For Software, the standard approach is to receive new sources code from developers and then to generate the executables using controlled procedures on a dedicated build hardware. This process is called build management and is the responsibility of Release Management. It is quite common to automate the build procedures and automation should be controlled as additional CIs themselves. These may be generic or specific to the release. Hardware components may also need assembling and configuring. This should be performed in a controlled and documented way. It is quite common to write scripts to automate the installation of systems and application software onto servers and workstations. depending on the implementation plan, this may be able to be performed in advance (for example, if the equipment is being replaced) or it may have occurred in situ in the live environment. Build management the responsibility of release management from the controlled test environments onwards.
Before a Release can be rolled out to the live environment, it should undergo stringent testing and User Acceptance. This should include functional testing, operational testing, performance testing and integration testing. Change Management should ensure that there is a formal user acceptance and sign-off before Release Management can continue to roll out the Release. Insufficient testing is the most common single cause of failure of all Changes and Releases.
A back-out plan should be produced to document the actions to be taken to restore the service should the rollout of a Release fail, either partially or totally. The production of back-out plans for each Change is the responsibility of Change Management, but Release Mangement has a role in ensuring that the back-out plans for each change within a release operate together to create a Release back-out plan.
These are two approaches and a combination
A backout plan should be verified as part of the risk assessment of the overall rollout plans, and it should be agreed with the end users as sufficient. For example, a service might not be critical, in which case it might be agreed that manual procedures can be used whilst the rollout is completed successfully. Back out plans should be tested as part of the process of verifying the rollout process.
As organisations become more dependent on IT, the effective control and security of their computer systems assume greater importance. Organisations should be able to cope with a high frequency of software and hardware Releases across the organisations without sacrificing IT service quality. The controls and mechanisms within release management help support this requirement in an efficient and economical manner.
The principal benefits of Release Management, when combined with the effective Configuration Management, Change Management and operational testing functions are:
As the efficiency of Release Managment grows, the productivity of IT services staff is likely to increase. More importantly, productivity benefits are likely to be realized amongst end users, as releases should be fewer and better planned, with appropriate training and documentation of higher quality.
The potential problems in implementing Release Management are:
In all cases, the Release Management plan and the principles and policies on which it is based may be subject to a publicity campaign at the outset and periodically thereafter in order to set expectations and goals.