|
|
The term 'Release' is used to describe a collection of authorised Changes to an IT service. A Release is defined by the RFCs that it implements. The Release will typically consist of a number of Problem fixes and enhancements to the service. A Release consists of the new or changed software required and any new or changed hardware needed to implement the approved Changes. Releases are often divided into:
There are normally dependencies between a particular version of software and the hardware required for it to operate. This will drive the packaging of software and hardware together to form a new Release of the service, along with other functional requirements. For example a new version of an application software system may require an upgrade to the operating system and one or other of these two Changes could require a hardware change, e.g. a faster processor or more memory.
Release Management is concerned with changes to defined IT services. These can be implemented by rolling out a combination of new applications software together with upgraded or new hardware, or simply changes to the service hours or support arrangements.
The main roles and responsibilities in Release Management should be defined to ensure that everyone understands their role and level of authority and those of others involved in the process.
The Release policy covers Release numbering, frequency and the level in the IT infrastructure that will be controlled by definable Releases. The organization should decide the most appropriate approach, depending on the size and nature of the systems, the number and frequency of Releases required, and any special needs of the Users - for example, if a phased rollout is required over an extended period of time. All Releases should have a unique identifier that can be used by Configuration Management.
A Release policy may say, for example, that only strict 'emergency fixes' will be issued in between formally planned Releases of enhancements and non-urgent corrections.
'Release unit' describes the portion of the IT infrastructure that is normally released together. The unit may vary, depending on the type(s) or item(s) of software and hardware.
Figure 9.2 gives a simplified example showing an IT infrastructure made up of systems, which are in turn made up of suites, comprising programs, which are made up of modules.
Figure 9.2 - Simplified example of an IT software infrastructure
The general aim is to decide the most appropriate Release-unit level for each software item or type of software. An organisation may, for example, decide that the normal Release unit for its Transaction Processing (TP) services should be at system level. Such a policy means that each time a Configuration Item (CI) forming part of the TP service is changed, a Full Release of the whole of that system is normally issued. The same organisation may decide that a more appropriate Release unit for PC software should be at suite level, whilst the Release unit of a batch application should be at program level.
The following factors should be taken into account when deciding the appropriate level for Release units:
Releases should be uniquely identified according to a scheme defined in the Release policy. The Release identification should include a reference to the CI that it represents and a version number that will often have 2 or 3 parts. Example Release names are as follows:
The major advantage of full Releases is that all components of the Release unit are built, tested, distributed and implemented together. There is no danger that obsolete versions of CIs that are incorrectly assumed to be unchanged will be used within the Release. There is less temptation to short-circuit testing of supposedly unchanged CIs and of the interfaces from changed CIs to unchanged ones.
Any problems are therefore more likely to be detected and rectified before entry into the live environment. The disadvantage is that the amount of time, effort and computing resources needed to build, test, distribute and implement the Release will increase. Although in some circumstances the testing of a delta Release (see below) may need to be as extensive as that for an equivalent full Release, the amount of building effort required to test a delta Release is normally less than for a full Release.
Regression testing as part of the process of implementing a full Release allows a large number of components to be retested to ensure that there is no degradation in system function or behaviour.
An example of a Full Release could consist of the complete Release of a new version of client desktop software, or client desktop hardware, or both.
A delta, or partial, Release is one that includes only those CIs within the Release unit that have actually changed or are new since the last full or delta Release. For example, if the Release unit is the program, a delta Release contains only those modules that have changed, or are new, since the last full Release of the program or the last delta Release of the modules.
There may be occasions when Release of a full unit cannot be justified. In such cases, a delta Release may be more appropriate. A decision should be made on whether delta Releases are allowed, and under what circumstances. There is no single 'correct' choice. It is recommended that delta Releases be allowed, with the decision being taken case by case.
In each case the Change Advisory Board (CAB) should make a recommendation, based upon all the relevant facts, on whether the Release unit stipulated in the Release policy is appropriate or whether a delta Release is preferable. In making its recommendation, the CAB should take into account:
To provide longer periods of stability for the live environment by reducing the frequency of Releases, it is recommended that, where appropriate and where the resulting larger amount of Change can be confidently handled without problems, individual Releases (full units, delta Releases or both) are grouped together to form 'package Releases'. For example, Changes to one system or suite will often require Changes to be made to others. If all these Changes have to be made at the same time, they should be included in the same package Release.
A package can, for example, contain an initial version of a new TP service, several new versions of batch programs, a number of new and initial versions of individual modules, together with the Release of a complete new desktop system (both hardware and software). Both full and delta Releases may be included.
The use of package Releases can reduce the likelihood of old or incompatible software being wrongly kept in use. It can encourage organisations to ensure that all Changes that should be made concurrently, in different suites and systems, are actually made concurrently. It can also encourage organisations to test the interworking of these suites and systems fully.
Care should be taken, however, not to exceed, in any particular package Release, the amount of Change that can be handled comfortably. When making a decision on what to include in the package, care should be taken to ensure that the full impact of all individual parts on each other part is understood and has been properly assessed.
The 'Definitive Software Library' (DSL) is the term used to describe a secure compound in which the definitive authorised versions of all software CIs are stored and protected. This one storage area may in reality consist of one or more software libraries or file-storage areas that should be separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organisation. The DSL should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site. Master copies of controlled documentation for a system will also be stored in the DSL in electronic form.
The exact configuration of the DSL that is required for Release Management should be defined before development commences. The DSL forms part of the Release policy or Change and Configuration Management plan for the organisation. The definition should include:
Figure 9.3 - DSL and CMDB relationship
Figure 9.3 shows the tight relationship between the DSL and the CMDB. It also shows how the CMDB holds a secure record or index of the exact contents of each given Release.
An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the live environment. Details of these components and their respective builds and contents should be comprehensively recorded in the CMDB. These can then be used in a controlled manner when needed for additional systems or in the recovery from major Incidents. Once their (temporary) use has ended, they should be returned to the DHS or replacements obtained.
The CMDB is updated and referred to throughout the Release Management process concurrently with updates to the DSL. It should contain the following information in support of the Release Management process:
The software and/or hardware components that comprise 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 source code from developers and then to generate the executables using controlled procedures on 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 to reduce the reliance on human intervention and so make it more reliable. 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 equipment is being replaced) or it may have to occur in situ in the live environment.
Build management becomes the responsibility of Release Management from the controlled test environment 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 Management 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.
There are two approaches and a combination of both can be used:
A back-out 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.
|
|
