Release management helps you preserve customers' production systems when new software and hardware are deployed.
The release management process is a demanding operation. The goal of release management is to preserve the integrity and availability of production systems while deploying new software and hardware.
Several processes are included under the umbrella of release management:
· Planning software and hardware releases
· Testing releases
· Developing software distribution procedures
· Coordinating communications and training about releases
The release management process is the bridge that moves assets from development into production.
Planning Releases
Planning releases is often the most time-consuming area of the release management process because there are so many factors that must be taken into consideration. For example, when deploying a new sales support system, the release managers must address:
· How to distribute client software to all current users
· How to migrate data from the current application's database to the new database with minimal disruption to database access
· How to verify the correct migration of data
· How to uninstall and decommission the applications replaced by the new system
· Verifying all change control approvals are secured
Each of these issues breaks down into a series of more granular tasks. Consider distributing client software. Release managers must account for variations in OSs and patch levels of client devices, the need for administrative rights to update the registry if the software is installed, and the possibility of conflicts or missing software on clients.
Testing and Verifying Releases
Release managers can play an important part in the testing phase of the software development life cycle; the key areas for testing and verification are:
· Software testing
· Data migration testing
· Integration testing
In each case, the testing process should constitute the final test and primary verification that the newly deployed applications operate as expected in the production environment.
Software Testing
Software should be thoroughly tested before it is released. In the ideal world, software developers work in the development environment and deploy their code to a testing and quality assurance environment that is identical to the production environment. It is in the test environment that integrated module testing and client acceptance testing is performed. This is not always possible. Large production environments may not be duplicated in test environments because of cost and other practical limitations. It is especially important in these cases that release managers work closely with software developers.
With responsibility for deploying software, release managers can provide valuable implementation details about the production environment that developers should test. For example, release managers will have information about the types of client devices and the types of network connectivity supported as well as other applications that may coexist with the system under development. Release managers may need to address data migration issues as well.
Data Migration Testing
In addition to supporting software developers on application testing and quality assurance processes, release managers may also have to support database administrators who are responsible for migrating data between applications. When the release of a new application entails shutting down one system, exporting data, transforming it to a new data model, and importing it into the new system, release managers will share responsibility for ensuring the data is extracted, transformed, and loaded correctly. Again, this process should be thoroughly tested before release, but realistic data loads are not always possible in test environments.
Integration Testing
Integration testing is the process of testing the flow of processing across different applications that support an operation. For example, an order processing system may send data to business partners' order fulfillment system, which then sends data to a billing system and an inventory management system. Certainly, these would have been tested before deployment, but real-world conditions can vary and uncommon events can cause problems. For example, spikes in network traffic can increase the number of server response timeouts forcing an unacceptable number of transactions to roll back. In this case, it is not that the systems have a bug that is disrupting operations, but that the expected QoS levels are not maintained. Testing and verifying software functions, data migration, and integrated services can be easily overlooked as "someone else's job," but release managers have to share some of this responsibility.
Software Distributions
Software distribution entails several planning steps. At the aggregate level, release managers must determine whether a phased release is warranted, and if so, which users will be included in each phase. Phases can be based on several characteristics, including:
· Organizational unit
· Geographic distribution
· Role within the organization
· Target device
When deploying new software or major upgrades, a pilot group often receives the software first. This deployment method limits the risks associated with the release. (Even with extensive testing and evaluation, unexpected complications can occur—especially with end users' response to a new application).
When distributing software, several factors must be considered:
· Will all clients receive the same version of the application? Slightly different versions may be required for Windows 2000 (Win2K) clients and Windows XP clients.
· Will all clients receive the same set of modules? If a new business intelligence application is to be deployed, power users may need the full functionality of an ad hoc query tool and analysis application, while managers and executives may require only summary reports and basic drill-down capability.
· How will the installation recover from errors or failure? Downloads can fail and need to be restarted. There may be a power failure during the installation process. Disk drives can run out of space. In some cases, the process can restart without administrator intervention (for example, when the power is restored) but not in other cases (such as when disk space must be freed).
· How will the installation be verified? Depending on the regulations and policies governing IT operations, differing levels of verification may be required. At the very least, the CMDB must be updated with basic information about the changes.
Software distribution is the heart of the release management process, but the ancillary process of communication and training is also important.
Communications and Training
The goal of communication in release management is to make clear to all stakeholders the schedule and impact of releases. This is the responsibility of release managers.
Training users and support personnel on the released system is not the responsibility of release managers, but both training and release managers should coordinate their activities. When training occurs too far in advance or too late following the release of the software, it may be of little use; the users may forget what they are taught or have already learned the basics by the time training occurs.
The release management process is a bridge from project-oriented software development and application selection to production operations. Although testing can be a well-defined and well-executed part of the development life cycle, release management still maintains a level of testing and verification responsibilities. In addition, the core operations of planning, software distribution, and communications constitute the bulk of what is generally considered release management.