Skip to content

Release Management

This chapter presents an overview of release management concepts.

Goals

The goal of release management is to provide you a way to organize and manage the release of your software applications; you establish a repeatable process to move applications to production so they are available to users.

These applications can range from simple applications to large complex systems with dependencies between components within applications.

Requirements

For effective release management, you must:

  • Identify applications and their associated release dates, noting applications releasing concurrently.

  • Understand the key relationships between application components. This becomes more difficult as the number of components increases.

  • Accurately manage the dependencies among the applications and various releases of the applications.

  • Ensure the proper components are available for any given release of an application.

  • Provide environments for thorough testing by appropriate personnel.

  • Ensure no collisions occur among applications during the testing and release schedules and during deployment, especially with applications releasing concurrently.

  • Integrate and manage application changes into a larger system. For example, Accounts Payable and Accounts Receivable applications need to be migrated into the Finance system.

  • Schedule release dates, identify resource constraints, and obtain management approval for upcoming releases.

Considerations

Release management affects personnel across your organization:

  • Managers want to minimize the risk involved with placing new releases into production while maintaining timely release schedules. They need to consider software quality, time, and cost when determining what applications will be released, and when. For example, if software quality becomes critical, then release schedules and costs need to be adjusted.

  • Developers need to accurately document complex and changing dependencies among their applications and their various releases. They need to evaluate these relationships to determine the impact of any changes to components.

  • Users are involved in the installation and appropriate configuration of the application to their particular environment. They want applications that are easy to install, test, and deploy quickly. Quality, usability, and robust features are important when the application is available to end users.

Objectives

To mitigate risk and ensure properly tested applications are placed into production, the objectives of effective release management are to:

  • Test applications together in a consolidated environment.

  • Manage the dependencies among the applications and releases.

  • Support multiple changes to the same component in various releases of an application.

  • Resolve obstacles prior to production.

Strategies

Release management can be implemented in a physical manner. You establish separate sets of libraries at the application level for the development and testing of components.

These libraries of changed application components are then funneled, or consolidated, until only a single set of libraries exist with all changed components. The final deployment to production takes place from this single set of libraries.

The following topics consider each objective listed above.

Test Applications Together in a Consolidated Environment

Developers change components in development libraries belonging to individual developers or teams. The components are then moved to and tested in libraries belonging to their applications. With multiple changes to multiple applications occurring simultaneously, there is a good chance that the same components are changed in multiple places.

Concurrent development of these components is detected when you consolidate libraries, as applications are tested along their designated release migration path. The different versions of the same component have to be resolved to prevent overlays of the changes or loss of new function as these components move forward in the migration path.

For example, in the following diagram, Accounts Payable and Accounts Receivable applications are consolidated and migrated into a set of Finance libraries. When you consolidate libraries at the Finance level, you have to resolve different versions of the same component. From Finance, you migrate components to Integration, then to Final. You deploy to production from these Final libraries.

Figure 2-1. Release management includes consolidating libraries.

Manage the Dependencies among the Applications and Releases

Developers need to document the dependencies among applications, and evaluate the relationships between application components and other components they include. With multiple releases, there may be different versions of the same component with different dependencies. It can be a tedious process to document these relationships.

You can use utilities to help automate the documentation of component relationships. These utilities examine the relationships between source programs and copybooks and the relationships of load modules to the composite load modules that call them.

With a physical implementation, you can use these utilities to examine the components in libraries for a particular application, as well as libraries up and down the established migration path to determine relationships. You can also look across releases to evaluate the relationships between releases or in the contents of a release.

Resulting component relationship information can be stored in a repository. You can use this information for analysis purposes, and to detect and report issues in related applications and releases.

Support Multiple Changes to the Same Component in Various Releases of an Application

Components may be changed in each release, and these releases may be in motion simultaneously. Fixes for component defects in one release may need to be applied to all corresponding components in other releases.

With a physical implementation of release management, parallel development takes place in the application libraries for each release. These changes are isolated from any other application’s or release’s changes.

Concurrent development of these components is detected when you consolidate libraries as applications are tested along their designated release migration path. The different versions of the same component have to be resolved to prevent overlays of the changes or loss of new function as these components move up the migration path.

Resolve Obstacles prior to Production

As you are testing applications together in a consolidated environment, you may encounter application discrepancies. Components may produce unpredictable results. You may encounter operational issues with hardware and operating system incompatibilities. You need to remove these obstacles before components can be properly tested, approved, and moved forward in the migration path.

You can identify checkpoints along the way as consolidation occurs. When obstacles are encountered, you can block forward movement with applicable rules in place. You can establish rules to allow only successfully tested components to be moved forward. You can also require appropriate approvals from development, management, and users to ensure that correct changes are implemented at the appropriate times.