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
Release management process is the bridge that moves assets from development into production.
Figure 5.5: Release management process is the bridge between two high-level IT life cycles: development and production.
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 applications 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 approval 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 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.
It goes without saying that 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 prior to release, but realistic data loads are not always possible in test environments.
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 prior to 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 rollback. 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 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 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 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 or 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 are 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 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.
Service delivery depends on a mosaic of interdependent processes, including incident management, problem management, configuration management, change management, and release management. These processes constitute core operations within the SOM model.
The focus here, as with other SOM elements, is to define management tasks in terms of generic operations that apply to a wide range of assets and can be adapted to new technologies as they emerge. The center of management is not desktops, servers, and network hardware but the operations that deploy, maintain, and secure them.
This chapter has introduced the first part of systems management services. Chapter 6 will continue the discussion by examining management issues in service delivery, including service-level management, financial management of IT resources, capacity management, and availability management.
Download Additional eBooks from Realtime Nexus!
Realtime Nexus -- The Digital Library provides world-class expert resources that IT professionals depend on to learn about the newest technologies. If you found this eBook to be informative, we encourage you to download more of our industry-leading technology ebooks and video guides at Realtime Nexus. Please visit http://nexus.realtimepublishers.com.
Implementing System Management Services
Home: Deploying Service Support
Part 1: Elements of Service Support
Part 2: Incident Management
Part 3: Problem Management
Part 4: Configuration Management
Part 5: Change Management
Part 6: Release Management
The above tip is excerpted from Chapter 5, "Implementing System Management Services, Part 1: Deploying Service Support" of The Definitive Guide to Service-Oriented Systems Management by Dan Sullivan. Get a copy of this ebook at Realtime Publishers.
About the author: Chief Technology Officer of Redmont Corporation. Dan's 17 years of IT experience include engagements in enterprise content management, data warehousing, database design, natural language processing and artificial intelligence. Dan has developed significant expertise in all phases of the system development lifecycle and in a broad range of industries, including financial services, manufacturing, government, retail, gas and oil production, power generation, and education. In addition to authoring various books, articles and columns, Dan is the leader of The Realtime Messaging and Web Security Community where he posts to his Messaging and Web Security weblog and produces his expert podcast.
This was first published in February 2007