|
|
Planning a Release involves:
Release planning inputs include:
Release planning outputs include the plan for a particular Release, and high-level test plans and acceptance criteria for the Release. The outputs of Release planning are normally documented in the Change Management plan for a particular project.
Release Management should work with Change Management to agree the exact content of each Release.
Procedures should be planned and documented for building software Releases, reusing standard procedures where possible. A configuration of a particular Release of software and hardware may be based upon a set of available components, some of which may be developed in-house and others bought in. The instructions to assemble a Release in this manner should be considered part of the definition of the Release and treated as a controlled CI.
Conducting the actual build involves, at a minimum, compiling and linking application modules produced in-house and any bought-in software that is held in source form, in each case from the DSL. It may also involve incorporation into the Release of any bought-in software, in object form, that is to be included. It may include generating databases and populating them with test data or, for live builds, static reference data (e.g. the Post Office Address File). Where necessary, it includes the generation (or, minimally, transcription from the DSL) of the operating system, the DBMS run-time components, etc.
It is quite common to write automated installation routines to ensure accurate rollout of a Release. These may include one-off routines to convert data or initialise databases. Any automation or one-off jobs should have equivalent back-out routines to enable the Release to be reversed in the event of problems.
Software licences and training in the use of support tools will be required for central Release Management staff. New health and safety requirements need to be considered when releasing new or changed equipment. New or changed data feeds (e.g. Electronic Data Interchange links) may need to be ordered and tested as part of this activity. Changes to hardware or software support contracts may need to be negotiated.
All software, parameters, test data, run-time software and any other software that is required for the Release should be under Configuration Management control. Quality control checks should be performed on this software before the application is built. A complete record of the build results should be logged in the CMDB. This ensures that a build can be repeated should it be necessary.
The high-level test plans for the Release need to be expanded to include specific tests to verify the successful rollout of the Release, by satisfying critical success factors and exit criteria. For example, an automated installation routine may be developed for a new Release of software component, and this needs to be tested separately from the software application itself.
Design, build and configure inputs:
Design, build and configure outputs:
The testing of the Release should be performed by independent business staff and involve IT staff to verify any changed support procedures. Any back-out procedures should be tested as part of this activity, which should prove that the built Release can be installed and run as required. This includes testing both the installation procedures and the function of the final system.
Testing should cover the installation procedures and the functional integrity of the resultant system. There should be a sign-off for each stage of testing. The final acceptance and sign-off for the Release to go into the live environment should be an agreed stage of the Change Management process. All levels of support should be involved in the testing of major Releases.
Release acceptance should be performed in a controlled test environment that can be reinstated to known configurations of both software and hardware. These configurations should be described in the Release definitions and stored in the CMDB, along with any other related CIs.
If a Release is rejected, it should be rescheduled through Change Management. Rejected Releases should be tracked and reported through Change Management as failed Changes. Failed Releases and their impact on operations and support staff resources should be monitored.
Release acceptance inputs comprise:
The end result of the acceptance activity should be a sign-off on the completeness and accuracy of the whole Release. The outputs should include:
Rollout planning extends the Release plan produced so far to add details of the exact installation process developed and the agreed implementation plan. Rollout planning involves:
Figure 9.5 - Rollout options
Figure 9.5 illustrates a typical sequence of events over time. The Release policy endures across all Releases of the system and defines the overall approach. The sequence of events is as follows:
This scenario illustrates a number of important points:
Figure 9.6 - A phased roll out across several geographical locations
Figure 9.6 shows an example of a phased rollout of a system to a number of different geographical locations. It assumes that new versions of the system will work with at least the previous one. The example used assumes that new functionality is implemented first in the head office of the organisation, then in a pilot branch, and finally in the remaining branches.
If there are a very large number of locations to deal with, it may still take a long time to implement the initial system or later upgrades in all branches, thus increasing the likelihood of needing to support even more versions of the system in the live environment concurrently.
Customer liaison staff, Customers and support staff need to know what is planned and how it might affect them. This is normally accomplished through training sessions, periods of parallel working, and involvement in the Release acceptance stage. Problems and Changes that need to be made during rollout should be communicated to all parties to keep them informed and to set their expectations. This activity normally includes running a series of rollout planning meetings with all of the interested parties to ensure that the plans are properly reviewed, checkpoints are established and all parties agree their responsibilities.
It is important to publicise the Release mechanism.It is also important to publicise any constraints to end Users (for example that it may not be possible to effect an update to all PCs overnight in a large organisation).
Health and safety requirements need to be considered when installing new or changed equipment and handing it over to Users. Checks should be made for any hardware, software, networking, cabling or capacity issues that are outstanding. New or changed data feeds (e.g. Electronic Data Interchange (EDI) links) need to be ordered and tested as part of this activity.
Changes to hardware or software support contracts may also need to be communicated to the relevant staff. The responsibility for this communication clearly rests with the Service Desk, but Release Management may be better placed to undertake the detailed communication.
Inputs to this activity are:
Outputs should comprise the:
Distribution of the software Releases from the build environment into the controlled test environment and then into the live environment should be accomplished with any associated hardware or co-requisite changes.
The processes for procurement, storage, dispatch, receipt and disposal of goods should ensure that equipment is delivered safely to its destination in its expected state. Storage areas should be secure. Checks on the receipt of goods against supporting delivery documentation are required for Configuration Management. Installation, environmental and electrical checks should be planned and completed before connection to the network.
Software distribution should be designed so that the integrity of software is maintained during handling, packaging and delivery. Automated software distribution to remote locations will save resources and reduce the distribution cycle time. After distributing software over a network, it is essential to check that the Release is complete when it reaches its destination.
Bringing application software Releases into active use in these environments is the final step in effecting the Change. It is quite common to distribute a new version of an application to a target installation, but to do so in a way that it remains dormant until activated. This should be accomplished by following the tested installation procedures. These may require running automated installation routines or other one-off utilities to effect the Change. To ensure a smooth rollout, an automated check of the target platform is required so as to ensure that it satisfies hardware and software prerequisites. This would call upon the audit services of Configuration Management, but Release Management drives the process.
The CMDB should be updated following installation or disposal of hardware or software, to ensure that it reflects the final position. It may be necessary to retrieve old versions of software that have been superseded, to prevent software licence rules from being violated.
For some types of Release (e.g. for desktop upgrades) it may be appropriate for the end Users to perform a final acceptance test of the installed software. For substantial Changes, the Customers should develop or be given a checklist of tests to perform. An installation Customer satisfaction survey can be used to provide formal feedback.
After a successful installation, the Configuration Management records should be updated with the location and the owner of the hardware and software. This will assist support staff to locate equipment and resolve subsequent Incidents and Problems more efficiently.
Distribution and installation inputs are:
Distribution and installation outputs should comprise:
|
|
