Release Management

Figure 4: Release Management Table Structure

How Release Management Works

Background

Release Management was designed as a more error proof way of promoting and tracking configuration changes in OIPA from the development environment all the way to production. Prior to OIPA Version 9, configuration was migrated between environments using a Migration Tool. It simply pushed the configuration from a source database to a destination database. The configurors tracked their changes using spreadsheets and then a Release Manager used the spreadsheets to perform the migration. This was a very error prone process as the configuror or the Release Manager could easily miss a rule.

Release Management was designed to fix these problems by tracking changes in a database using Configuration Packages, which have a one-to-one relationship with a development issue. When Release Management is enabled, a configuror is required to add all changes to a Configuration Package, which means that all changes are tracked in Release Management. When the time comes to migrate the changes, the available Configuration Packages are displayed in the Rules Palette and added to a Migration Set by a Release Manager. The Migration Set is then added to a Release Package, along with other non-configuration components, to be deployed to the target environments.

Definitions of Release Management Functionality

Configuration Packages

Configuration Packages represent a unit of work, or an issue in an issue tracking system (e.g. JIRA). A Configuration Package can contain several rules that were modified as part of an issue. It can also contain non-rule items such as SQL Scripts (DML or DDL), stored procedures, and reports. All Configuration Packages are represented in the database by the IvsConfigPackage table, and the rules that are part of them are represented by IvsConfigPackageContents (see Figure 4). This is a one-to-many relationship.

Use of Configuration Packages by configurors is required when Release Management is turned on. A Configuration Package prompt will be displayed in three different scenarios, assuming the rule is not already in an open Configuration Package. If the Configuration Package is not owned by the person trying to access the rule, then a message will appear saying that the rule is locked by an open Configuration Package. The owner's name will be listed in the dialog box and the check-out action will be cancelled. Configuration Package prompt scenarios include Rule Checkout, Check-in of a New Rule, and Rule Deletion.

Once a configuror has added all modified rules to a Configuration Package and completed work, the Configuration Package is marked as "Ready to Migrate". At this point, the configuror is done with the Configuration Package and will move onto the next issue. When the configuror marks the package Ready to Migrate, the system populates the VersionGUID column of each IvsConfigPackageContents record.

In some cases, a configuror may need to release the rules in a Configuration Package due to higher priority issues. The Put On Hold feature allows the rules within the package to be released to other configurors. When a rule is released, the changes made to that point remain in the rule. The next configuror can add the needed changes and then migrate his Configuration Package. Now the rule can be re-added to the original Configuration Package and work can resume. It is very important that the rule be unit tested before configuration begins again. This is necessary to ensure the newest rule changes don't conflict with the original configuror's intent for the configuration.

The following type codes related to CPs correspond to the following IvsCode Code Names:

IvsConfigPackage.StatusCode: IvsCode.CodeName = "IvsCodeConfigPackageStatus"

A list of statuses available for a Configuration Package appears in Figure 5 below.

Figure 5 - Configuration Package Statuses

The Configuration Lead is responsible for reviewing all Configuration Packages to make sure there are no conflicts. Any rules that were deleted should reside in an Orphan Rules Configuration Package. All these rules should be reviewed to ensure the rules are not needed in any other configuration.

Migration Sets

Migration Sets represent a collection of Configuration Packages that will be associated with a release and migrated from a Development environment to different environmental levels of a company, generally ending in Production. All Migration Sets are represented in the database by the IvsMigrationSet table, and the Configuration Packages that are part of them are represented by IvsMigrationSetContents (see Figure 4). This is a one-to-many relationship. The IvsMigrationSetContents:IvsConfigPackage relationship is one-to-one. While IvsMigrationSetContents looks similar to a link table, the relationship cannot be many-to-many because a Configuration Package may only be in one Migration Set.

Because Migration Sets have a one-to-one relationship with a Release Package, a common question is, "Why don't you just add Configuration Packages to the Release Package?" We were looking to separate the duties of organizing configuration into a release. Creating a Migration Set requires in-depth analysis of what changed in the configuration as well as what will be changing in the target environment. This will usually be performed by a Business Analyst or someone with detailed knowledge of the system and configuration. Creating a Release Package requires no knowledge of the configuration and can be performed by an IT department or anyone designated as a Release Manager.

Migration Sets are created in the Rules Palette from the Admin Explorer only when all issues expected to be in the release are complete and their Configuration Packages are in the "Ready to Migrate" status. Migration Set creation is completed using a simple UI that at the present time only has the ability to enter a Migration Set name and select Configuration Packages for inclusion in the release. In the future, we plan to provide a suite of analytical tools for use by the Business Analyst at this step.

The following type codes related to Migration Sets correspond to the following IvsCode Code Names:

IvsMigrationSet.StatusCode: IvsCode.CodeName = "IvsCodeMigrationSetStatus"

A list of statuses available for a Migration Sets can be found in Figure 6 below.

Figure 6 - Migration Set Statuses

IMPORTANT: Configuration Packages cannot be removed from a Migration Set. SQL Scripts must be used to perform this operation.

Release Packages

Release Packages represent a release of configuration changes, application files, SQL scripts, and other files critical to a release. The Release Package is stored in the database, but the system is also designed to generate an archive file (zip or jar) to represent the release. Currently a Release Package can only be deployed from the IVS database, but functionality to deploy directly from the file is in the planning process.

All Release Packages are represented in the database as the IvsReleasePackage table (see Figure 4). There is a one-to-one relationship with the IvsMigrationSet table. The ReleasePackageManifest column stores an XML CLOB that serves as a readable version of the contents of the Release Package. ReleasePackageManifest is for users who don't have access to the database, but want to know what is in the Release Package. It can also be used for the planned "file deployment" functionality described above.

All Release Packages are created using a Release Package Wizard in the Rules Palette Admin Explorer. Options in the wizard include choosing file type (.zip or .jar), naming the Release Package, adding comments or SCM Labels, attaching executables (WAR files), attaching properties files (SystemInformation.properties), and verifying (but not removing) SQL scripts, stored procedures and report files. The verification steps are simply a confirmation that non-configuration items need to be added to the Release Package. They cannot be removed in this wizard because along the way the Business Analyst who created the Migration Set decided they were required as part of the release.

The following type codes related to Release Packages correspond to the following IvsCode Code Names:

IvsReleasePackage.StatusCode: IvsCode.CodeName = "IvsCodeReleasePackageStatus"

A list of statuses available for a Release Package is shown in Figure 7 below.

Figure 7 - Release Package Statuses

Promotion mentioned in statuses 03 and 04 has to do with external Source Control Management (SCM) systems. The idea was to have SCM environments that corresponded to the OIPA environments, then to set a Release Package "Ready to Promote", check the Release Package into the SCM environment, "Promote" the Release Package to the target SCM environment, and then deploy the Release Package to the target OIPA environment. This process was part of an "external approval procedure," which was an offshoot of Sarbanes Oxley legislation. All of these steps must be performed manually as the Rules Palette currently does not interface with any third party SCMs.

Release History

Release History provides an audit trail for all actions that take place in the Release Management process. Release History is represented by the IvsReleaseHistory table (see Figure 4). The Release History table shows that action that occured (ActionCode), when it happened (LastModfiedGmt), the user who executed it (LastModifiedBy), where it happened (Environment AND Track), what type of Release Management component the action is being performed against (ReleaseCode), and the identifier for the component (ReleaseProcessGUID).

Every time the status changes on a Configuration Package, Migration Set or Release Package a record is written to IvsReleaseHistory. The same status codes are used from IvsCode that are used for each individual Release Management component.