|
|
To be effective, Release Management is heavily dependent upon Configuration Management, Change Management and operational acceptance testing. If these functions do not already exist, they should be planned in conjunction with Release Management.
Planning Release Management should include:
Procedures should be documented for:
Representatives of the IT staff affected should review the procedures. Amendments required to documentation to reflect changes in procedures or policy should be subject to normal Change Management control and properly authorised. Superseded versions of documentation should be withdrawn from use.
A Release policy document for an organisation should be produced to clarify the roles and responsibilities for Release Management. There may be one document per organisation, or an umbrella set of guidelines and specific details for each supported system or IT service. The Release policy normally forms part of an organisation's overall Change Management plan.
A Release policy is revised or extended when an organisation adopts a new technical infrastructure. Piloting of new Release Management procedures should form part of a project to implement a new infrastructure. For example, a new approach to releasing software may need to be developed when an organisation decides to adopt a new hardware or software platform. This may be something as small as a new programming language or as major as a completely new hardware platform with its own operating system, or a network management system.
A Release policy should include:
Sample rules for adding software to the DSL:
Procedures, templates and guidance should be planned to enable the central Release Management staff to take products from application groups and projects, and then to release the software and hardware efficiently and effectively. Documentation should be developed to assist with:
Procedures and documents for purchasing, installing, moving and controlling software and hardware that are relevant to Release Management include:
A project can cover development and Release of the end product. In that case, communications between Release Management and Project Management needs to be clearly defined. For products developed under the control of PRINCE2, Release authorisation requires Operations Acceptance and User Acceptance letters. As a project is a temporary thing, the acceptance documentation should be formally handed over to Release Management for future reference and maintenance.
The distribution of hardware and the creation of the necessary environment for a Release should be carefully planned. The detailed issues relating to these activities are included in the ICT Infrastructure Management book.
Standard procedures should be documented for distributing software Releases from test-build environments into the live environment(s), and for bringing them into use in these environments. Where the build environment is not resident on the same computer as the appropriate test or live environment(s), it is necessary to use a communications link or some form of portable magnetic medium (removable disk or tape).
All reasonable steps should be taken to obviate the possibility of software corruption during distribution to the target environment. Any technical aids available (e.g. checksums on the data transmission), should be used to detect errors so that corrective action can be taken.
As well as transmitting the content of the build to its target environment, it is often necessary to execute some additional processes on the target machine so as to enable operation of the new software to commence. This may involve such actions as the archiving of superseded software versions and the loading of existing live data into a new database structure; and it almost always involves some 'switch-on' action such as a library switch or unit reload.
If a software Release is to be distributed to a large number of locations, it may be essential for all Users to start using the new Release at the same time - for example, if a legal change is to be introduced nationwide at start of business on a specific day, or if a distributed corporate database is involved. If the Release is to be implemented in many locations concurrently, special steps may be necessary. Scale may determine that distribution of the Release to all locations has to be spread over a period of time. The dormant Release can then be installed at each location in readiness for live implementation, with some form of 'switch' triggered to bring all Releases into use at the appropriate time. The switch may involve issuing a command at either a central control site or at a number of distributed sites; alternatively, some form of software switch may be embedded in the Release itself, to be activated upon some predefined event. A Release such as this is a major activity with a potentially significant impact on the business. Therefore it should be the subject of careful and extensive testing, planning and management.
All necessary scripts and parameters for use at implementation should be controlled in essentially the same way as those for build time. The objective is to make the implementation process as simple, foolproof and secure as possible. Ideally, the Release Management team should only need to issue a single command from a terminal or console to initiate the implementation process, once distribution of the Release has been successfully completed. It should also be possible to check from the distribution centre that the implementation has been successful. If transmission is via magnetic media, then some 'local' actions are unavoidable, although ideally this should be limited to physically mounting the tapes or disks, updating local procedures and manuals, etc.
Unless the distribution and implementation process can be controlled automatically, or from the centre using software tools, human procedures should ensure that distributed software arrives when expected and is checked in whatever way is practical for authenticity; and that the software is brought into use when required. These procedures should include the following activities:
The Release record on the CMDB states which installations are to receive the Release. The CMDB should be updated to reflect the receipt and implementation of the Release at each remote site.
Change Management procedures require that back-out plans be made in advance for all Changes that are to be implemented. In the case of new software Releases, this will normally involve withdrawal of the new Release and reversion to the previous, trusted, Release. This may not, however, be possible (e.g. the new Release implements a mandatory legislative change, and so it is obviously not possible to use the old program versions). In such cases, alternative back-out plans need to be made. In all cases the back-out plans should, where possible, be tested and proved to be workable.
Software Releases often involve the use of a hierarchy of distribution or staging servers. It is essential before a Release is attempted that all software and hardware environments used within the distribution are checked to ensure that there is sufficient spare space to contain the intended Release. Once the Release has either been accepted as successful or been rolled back, all environments involved within the process should be reviewed again, to ensure that redundant hardware or software components are removed.
Releases that consist of many different types of software and hardware may involve many people in the Release and control processes. The typical responsibilities for accepting components of a Release should be defined centrally, and then this can be modified as required for specific Releases. Typical roles are the Change Manager (see Chapter 8), the Release Manager and the Test Manager.
Where there are standard build and installation procedures that are predefined and approved, it is feasible to allow further activities without specific reference to Change Management each time - for example, standard installation of a desktop application to a new workstation. The CMDB should be updated, preferably automatically, each time to reflect the Changes. This method can only be allowed where each installation satisfies any documented prerequisites and conforms to agreed operational constraints, such as a limit on the number of additional workstations at a given location.
If there are no common roles, responsibility for the acceptance and handover should be documented within a specific responsibility table for the organisation. An example of a responsibility matrix for an organisation that supports client-server applications is shown in Table 9.1. Such a matrix will help to identify gaps and overlaps and typical roles can be planned for the future.
| Release | Development | Controlled test Environment | Live | ||
| Responsibilities | |||||
| Class of Object | Released from | Accepted by | Authority to | Accepted and | Control |
| Release to Live | Supported by | Records | |||
| Bought-in | Development | Test Manager | Change Manager | Operations | CMDB |
| package | Manager | Manager | DSL | ||
| Customised | Development | Test Manager | Change Manager | Operations | CMDB |
| modules | Manager | Manager | DSL | ||
| Physical database | Development | Database | Change Manager | Database | CMDB |
| changes | Manager | Administrator | Administrator | DB | |
| script in DSL | |||||
| Server | Server Builder | Server Manager | Change Manager | Server Manager | CMDB |
| Desktop build | Desktop | Test Manager | Change Manager | Desktop | CMDB |
| (e.g. a new | Development | Support | DSL | ||
| application) | Manager | Manager | |||
| Desktop | Desktop | Desktop | Desktop | Desktop | CMDB |
| Application | Development | Support | Support | Support | DSL |
| (already built and | Manager | Manager | Manager | Manager | |
| within operational | Change Manager | ||||
| constraints) | |||||
| Desktop | Logistics | Desktop | Desktop | Desktop | CMDB |
| computers | Support | Support | Support | ||
| Manager | Manager | ||||
| Change Manager | |||||
| Release | Development | Test Manager | Release Manager | Service Desk | CMDB |
| Authorisation/ | Manager | Change Manager | Users | ||
| Change Record | Test Manager | ||||
| Operations | |||||
| Manager | |||||
| Desktop Support | |||||
| Service Desk | |||||
| User at each site | |||||
| Table 9.1-Example responsibility matrix | |||||
Figure 9.4 shows the involvement of Release Management and Change Management in a request for something new or outside agreed operational constraints. It also shows that the Service Desk team can build additional workstations to the same specification without referring to Change Management explicitly for each and every request - so long as it conforms to the predefined operational limits and the CMDB is updated. The same can apply for installing an application on an existing workstation using authorised instructions. Table 9.1 helps to explain some of these roles by example. Desktop build (e.g. a new application) is released from the 'Desktop Development Manager' - who is NOT part of Release Management or Computer Operations. Release Management is about overseeing the process and Operations Management is concerned with running the current live systems, but 'Desktop Development' is concerned with designing and building the next Release of a system - which in this case is a desktop build (i.e. a particular configuration of system and application software).
Figure 9.4-Release Management and Change Management
The number of Release Management staff needed depends on the scale of operations. Because Release Management is on the critical path between applications development and live operations, and is involved in all important Changes to live systems, there should be enough trained staff to cover for annual leave and absences.
Larger projects should consider the resource loading on central staff and provide additional resources (preferably using secondment from other areas, such as the Service Desk) or funding to perform Release Management, Change Management and Configuration Management activities.
Release Managers require a sound technical background, with a good understanding (or an ability to get it) of the IT infrastructure and the services it provides. A good working knowledge of support tools and utilities, and a good grasp of the principles and practices of IT Infrastructure Management - especially Change Management and Configuration Management - are essential. An awareness of the organisation's business strategy and its priorities is also needed. Staff management and project management skills are highly desirable.
In a small company the Release Management function can well be combined with several other Service Management disciplines, in particular Change Management and Configuration Management. In a larger organisation there may be dedicated Release Management staff for particular systems, assuming that there is not too much need to coordinate Releases. In these cases, there may also be a central software distribution function to support all of that work, i.e. a team dedicated to this specialised task.
Release Management staff should be given technical training in the principles and practices of Change Management and Configuration Management and of software maintenance and development, and in the use of support tools and utilities. A more general awareness of the IT infrastructure and the services it provides should also be imparted, together with an appreciation of the organisation's business issues.
Application development managers and project managers should be trained in the Release policy, procedures and tools. Procedures and guidance should be published and made available to all staff involved in Release and rollout management.
Training may also be required for the operational Users who release the service to the business, and for business Users who need the 'new service' to meet business needs.
When the necessary staff, procedures, hardware and support tools are in place and all necessary training has been completed, the DSL and build environment(s) should be physically created and the necessary security permissions established so as to limit access to authorised Release Management staff. The DSL and test/build environments should be tested in accordance with criteria defined at the planning stage.
In particular, applications development staff should be told when to start delivering Release material for inclusion in the DSL, and arrangements should be made for all bought-in software to be delivered directly to Release Management for lodging in the DSL and passed to Configuration Management for recording in the CMDB.
Build management and software distribution procedures should be tested before they are brought into use. If a gradual approach has been adopted, as recommended, the first Release build will be when the deliverables from the selected development project or from the chosen supplier are to be subject to operational acceptance testing. By the time Releases to the live environment are needed, the build and Release control procedures will have been used for putting software into the operational acceptance testing environment, thereby providing another chance for many classes of potential problems with procedures and tools to be found and corrected.
Plans should be made in case the new procedures or tools fail. If software Releases are urgently required, it may be necessary to revert temporarily to previous procedures until the new procedures are corrected. Where possible, it is recommended that the procedures or tools for distributing software to remote sites be tested separately from those for implementing the software at the remote sites, thereby allowing problems with each of these phases to be isolated and corrected separately.
Although the procedures should be thoroughly tested before being brought into live use, time should nevertheless be allowed to resolve any teething problems in the early stages of live use.
To ensure that the procedures are fully adopted, the central Release Manager should:
The costs associated with Release Management include:
In almost all cases, the costs associated with implementing Release Management will be outweighed by the benefits it brings. For example, many organisations cannot function satisfactorily unless they can handle a high volume of software and hardware changes without sacrificing quality. Release Management gives them that ability.
Without adequate control, organisations are at risk from such things as computer fraud, inadvertent software corruption, software viruses and other malicious software. The damage caused by these can require an enormous sum to rectify.
It is good practice to record existing costs as soon as possible, so that improvements through good practices can be tracked.
It is possible to fund Release Management centrally or on a project-by-project basis. A common approach is for projects to pay for the initial costs of implementing Release Management in a new area and then to pass the ongoing support work onto a centrally funded group.
|
|
