|
|
Release Management should make use of any tools used by the Change Management process to record information about planned Changes. Release Management requires these tools to be extended to hold information about Releases and links to the Changes that they, either singly or grouped, each implement.
A good system will allow the tracking of the status of both individual Changes and the Releases that implement them, as well as providing facilities for staff to authorise, electronically, various phases in the life-cycle of a Release. Ideally, the final steps should automatically trigger the software distribution into the test and live environments using interfaces to those tools.
Hardware and software CIs should be recorded in the CMDB and, ideally, their status should be amended as the Release progresses. This requires the ability to store proposed Changes to the CMDB and to trigger updates to those records from the Change Management system.
There are many tools available to help manage the different versions of software source code during its development. Of particular value is the ability of the SCM tool to manage relationships. This enables a Change to any one CI to be assessed for impact upon other parts of the system, and thereby to identify what actions are required to ring-fence the Change as complete, and to plan appropriate testing.
Release Management benefits greatly from those SCM tools that can handle packages of Changes linked to an original Change request. This also implies the use of an SCM tool that can integrate with the Problem and Change request information typically held in a Service Desk tool.
A sound Release Management process requires the automated build of new Releases of software applications. This relies on being able to drive program compilations and links, in the correct sequence, under program control using the correct versions of the source code as stored in the SCM tool.
This process (see Figure 9.7) also requires making use of the cross-reference information stored in the software Configuration Management tool to determine which 'parent' objects need to be rebuilt when lower-level units are changed. For example, if a header or 'include' file is changed, then it is necessary to identify all source modules that need to be recompiled. Similarly, the names of the programs to be relinked should be determined, based on the list of modules that were recompiled.
Figure 9.7 - Example module hierarchy diagram for Program PRG1
Some more mature software Configuration Management tools also include build components to help with this process and eliminate the need to record manually dependency information. Where no proprietary tools are available, it is often feasible to script simple build procedures using command languages. However this is not straightforward without any specialised help, because an accurate build requires an understanding of the dependencies between the Changed CIs and so you may be limited to regenerating entire systems. Dedicated tools optimise the build process so that only those components affected are rebuilt. They also ensure that the correct version of the source code is used.
To complete the task (see Figure 9.8), the automated build process should save the generated executables in the DSL and update the CMDB accordingly. Some SCM tools improve upon this by storing 'footprints' containing the source code version used and compile information within the generated executables. The source version of all in-house-developed applications and modules should be stored within the DSL, together with all of the other systems software required to generate and run executable versions, such as compilers and operating systems.
Figure 9.8 - The software build process
Many organisations have large numbers of workstations and servers in the live environment that could require software Changes as part of a Release. Increasingly, this can require updates to software on more than one platform in a coordinated manner. The process of software distribution is not always smooth, whether manual or automated, because things can go wrong. Consequently, it is important to be able to record the progress of a given distribution and record individual failures (where, for instance, a few workstations did not receive a fix because of an error). It may even be required to insist on the back-out of a whole Release if it is only partially successful.
It is becoming increasingly difficult nowadays to achieve software distribution reliably and efficiently using manual processes, which is why there are a number of automated software-distribution tools on the market that can assist with this task. They range from simple file-transfer utilities to modules of large systems-management suites. Nevertheless, the introduction of such tools needs to be evaluated very carefully because they are not at all straightforward to use and they make increased demands on network bandwidth - which is often at a premium.
Being able to install an application automatically requires an understanding of how to do so manually and a general understanding of how software is installed and configured on the appropriate platform. Many applications come with their own installation routines, and sometimes it is a simple job to create a script to drive these in an automated way. However, this is not always sufficient and further Changes are sometimes required. Sometimes, special utilities are required to determine exactly what files are changed by installation routines by use of before-scans and after-scans - especially on workstations.
Features to look for (see Figure 9.9) in electronic software distribution tools include the following:
Figure 9.9 - Features of electronic software distribution
To be able to perform a successful Release it is important to have confidence in the target platform. This can be assisted through the use of automated tools to perform hardware and software audits. Such tools can determine exactly what software is installed and identify most critical aspects of hardware configuration.
Using tools like this, it should be possible to check for sufficient available disk space or some other prerequisite in the live environment a little while ahead of the distribution of the Release and so have time to rectify the situation in advance. As a consequence, there should be fewer failures during Release rollouts.
It is possible to restrict the changes that individual Users can make to client workstations and so make the target destination for new Releases much more reliable. Sometimes this can be achieved through correctly configuring operating system parameters; occasionally, additional software has to be used to increase control.
Whether electronic software distribution tools are used or not, it is a good practice to save standard workstation builds on a server and use some automation to perform the installation. There are a number of scripting languages that can help with this, and there are also dedicated software installation products that can be used.
It is the responsibility of Release Management to implement procedures to ensure that any installation files saved on servers are kept up-to-date when new Releases are lodged in the DSL.
Remote control and remote diagnostic facilities for live servers can aid fault determination and resolution during and after Release rollouts. Typical facilities provided include:
|
|
