Release Management

Release management activities revolve around identifying and distributing software releases. Depending on the circumstances, a "release" can consist of the elements changed during a maintenance effort, or it can represent an entire cross-section of the software inventory. Distribution of a release can be as simple as promoting a change into production, or as complicated as managing multiple concurrent releases of entire software systems.
18-0
 
 
Release management activities revolve around identifying and distributing software releases. Depending on the circumstances, a "release" can consist of the elements changed during a maintenance effort, or it can represent an entire cross-section of the software inventory. Distribution of a release can be as simple as promoting a change into production, or as complicated as managing multiple concurrent releases of entire software systems.
Accurate and current information is a prerequisite for performing every task, from creating a list of exactly what is to be released to verifying that the release was successfully accomplished. This information can only be obtained through an automated, integrated release management system.
Automated Release Management
In many installations, production turnover and release management are performed, often manually, as discrete activities by separate groups. Problems arise when software release packages are created manually "on paper," where there is a chance that the contents are incomplete or inadvertently changed prior to or during execution.
Endevor
provides integrated, automated release management functionality, ensuring that software release packages are built on a solid inventory management structure, created using automated techniques, and implemented as an integral part of the release process.
Additionally, the 
Endevor
 change administration facility provides online release package approval capabilities. Only with these combined capabilities is it possible to accurately create and manipulate a software release, perform change impact analyses, and track changes from release to release.
Change Administration
Endevor
provides change administration, in addition to security, as a means of specifically organizing and controlling change to portions of the software inventory. Through the
Endevor
change administration facilities, it is possible to provide authorization capabilities to the person(s) responsible for portions of the software inventory.
  • Approver Groups
    Endevor
    establishes change administration authorization through the definition of approver groups (named groups of user IDs) and the subsequent relation of those approver groups to portions of the
    Endevor
    inventory. For example, within the Payroll subsystem of the Finance system, you could establish an approver group that approves or denies changes to all elements within that system and subsystem.
    Some of the users within the group could be required to approve changes while the approval of other users would be optional. A quorum or minimum required number of approvers can be established for any approver group. "EMERGENCY" approver groups can be established consisting of those user IDs which must authorize emergency fixes to a portion of the inventory.
  • Change Packages
    Authorized users build change packages, which contain
    Endevor
    action requests. The user specifies whether the handling of that change package will be defined as 'STANDARD' or 'EMERGENCY'. The user also defines a date/time window within which the change package can be executed.
    Once the change package is built, it is then CAST, a process which causes
    Endevor
    to prepare the package for subsequent approval processing.
    Endevor
    automatically builds the list of approvers for a change package based on the previously defined approver groups. The change package then goes through approval processing, followed eventually by execution.
How Release Management Works
Release Management works as follows:
  • Building a Change Package
    Authorized users build change packages consisting of any number of
    Endevor
    action requests. Change packages can be built from online screens, imported from outside data sets and/or copied from existing packages. They can be edited, modified and/or appended to at any point during the build process.
  • Preparing a Change Package for Review
    The change package is CAST. The process of casting a change package causes the approvers for that package to be built based on the previously defined approver groups. Once a package is CAST, it can no longer be modified.
  • Reviewing a Change Package
    Users in the approver group(s) associated with a package can approve or deny the change package. Required users must provide their approval. Once all required approvals have been made, and the established quorum of approvals has been met, the change package can be executed.
  • Executing a Change Package
    At execution time,
    Endevor
    validates that all approvals have been made and that none of the elements have changed between the time the change package was CAST and when it was executed.
    Endevor
    also validates that the change package is being executed within the date/time window established when the change package was built.
    Endevor
    then executes all of the actions in the change package. Checkpoint/restart facilities are available so that change packages that fail execution can be re-executed properly. Change packages can be executed online or in batch.
  • Automatic Package Backout
    Subsequent to execution, it is possible to quickly and easily back out a change package. BACKOUT has the effect of reversing any outputs created by the execution of that package to the state they were in prior to package execution. BACKIN reverses the process.
Managing Production Turnover
Using the Component Lists created by the 
Endevor
 Automated Configuration Manager in combination with the 
Endevor
 logical inventory structure, you can build a change package containing all of the programs and components that make up a maintenance release. Once the package has been built, it can be used to drive production turnover for that maintenance release.
  • Creating a Maintenance Change Package
    When Change Control Identifiers (CCIDs) are used to tag all of the changes which make up a maintenance release, those CCIDs can be used as selection criteria to produce a package that itemizes all of the elements which comprise that maintenance release, as well as all related element components. For example, you could build a package that contains MOVE commands for all of the elements changed for CCID 'FIX01' and all the input components for those elements.
  • Promoting a Maintenance Release
    Once the change package has been constructed and has gone through the appropriate approvals, it can be used to perform the production turnover. In our example, execution of the ' FIX01' change package will automatically perform production turnover, promoting all of the elements contained in the package, as illustrated in the following diagram:
    Manage Production Turnover
    Manage Production Turnover
Managing Software Releases
The 
Endevor
 inventory structure, with ACM Component Lists, can be used to manage all aspects of releasing software. Once a change package has been generated, its contents can be used to drive the distribution of the software release, track changes from release to release, and recreate previous releases.
  • Creating a Software Release Package
    The inventory management structure of
    Endevor
    and the configuration information created by ACM can be used to create complete, reliable, and reusable software release packages. For example, a complete release package could be built containing all of the elements in Release 2 of the Finance system, and all of the components belonging to those elements. The resulting package would contain not only all of the elements that comprise the software release at this point in time, but information about the current versions and levels of those elements.
  • Release Distribution
    Once a release package has been constructed, it can be used to drive the distribution process, regardless of whether the software is to be moved to another
    Endevor
    location in-house, transferred to another
    Endevor
    location at a remote machine or site, or distributed to external files, perhaps for shipping to customers or divisions. In our example, the contents of the package created previously are used to drive the TRANSFER of Release 2 of the Finance system from Site 1 to Site 2, as illustrated in the following diagram:
    Release Distribution
    Release Distribution
Using the contents of release packages to drive the distribution process provides the added advantage of automating the distribution process and the documentation of that process.
Release to Release Comparison
An important aspect of any type of release management system is its ability to track changes from release to release. This broad, system-wide perspective is necessary when managing multiple software releases. Packages are kept in such a way that once created, their contents can be used in a number of ways. They can be compared to find out exactly what has changed from one release to the next. If the contents of the package are extracted and stored in the 
Endevor
 base/delta format, it is also possible to view changes to a software system over time. This capability is especially useful when trying to identify which modules of a software system have been added, removed, or changed prior to distributing a partial release consisting of changed components only.