Release Management Overview
The Release Management process allows users to control the flow of database information from a source environment to a target environment. It establishes a repeatable release process and provides structure to the configuration experience. Using Release Management also creates an audit trail for both past and future package releases. Changes to rules during this process can be tracked, eliminating the need for manual spreadsheets.
Configuration Packages are created to bundle rules. The use of a specific, defined naming system will help identify the purpose and content of the configuration packages. Once all of the configuration packages are created, they are marked as Ready to Migrate and a Configuration Lead will manually review them to make sure there are no conflicts.
Migration Sets are the second phase of the process. Multiple configuration packages are added to a single migration set. Once a migration set has all the necessary configuration packages, it is added to a release package. A release package can only contain one migration set.
Release Packages are the third phase of the process. A single migration set can be added to a release package. Stored procedures, DML scripts and DDL scripts and other non-Palette items can also be added at this time. A release manifest file is generated in the release package file directory to identify all the components in the package.
Detached Migration
When a source environment doesn't share an IVS environment with the target environment, a detached migration must be performed. The detached migration creates a Release Package that contains the XML data for each of the rules being migrated. This release package can be sent via FTP, email, etc., to any location and deployed to a ‘detached’ IVS environment.
Refer to the Detached Migration section for an explanation of this process.
Enable Release Management Functionality
Release Management is only available to a user when the Release Management functionality is turned on. The build manager determines if Release Management is needed. A user can check to see if this is turned on in a particular environment by right-clicking on the environment node, when logged in, and selecting the Properties option. Then scroll down and check the Release Management property. Only the Main Explorer or the Global Rules Explorer can be used to check the environment properties.
Once the Release Management functionality is on, a user must also have the proper security privileges.
Security
Release Management security is divided into three stages. A user typically has security privileges for one stage of the process, but this is not a limitation. The user can have any combination of privileges, according to what is specified in the security role.
State Approvals and Release Management
Data for state approval is initially maintained in Development environments. The data is then migrated through various test and integration environments to finally reach production.
Release Management must be turned on for state approval record versions to apply to configuration packages. Each set of state approval records is versioned by plan or segment. Each version is a complete snapshot of the persisted state approval records for the plan or segment. Configuration packages containing state approval versions must be deployable to target environments.
Process Overview
There are several steps that must be completed to move through the release process. First, create a configuration package. Once it is complete, mark it ready to migrate and then a migration set will be created. A release package is then created. Next, build the package and promote the package. After all these steps are complete, a release manager will deploy and promote the package in the target environment.
Overview of Release Management Process
Important | Before making any changes and migrations, make sure all environments in the development track are synchronized with respect to the rules configuration. |
Create Configuration Package
After Release Management is set-up in the source environment, begin creating configuration packages. A node for configuration packages will display under the environment name in the Main Explorer. If the node is not present, contact the Security Manager to make sure Release Management privileges were assigned to your role. Release Management will not be visible unless a user has the proper security privileges.
The configuration packages node on the Main Explorer holds the configuration packages that are created. Security controls whether users see their packages only or packages created by other users. When the release management process is initiated, this folder will be empty until the first package is created. Packages are removed from this folder once they have been labeled Ready to Migrate.
Configuration Package Right-Click Menu
-
Ready to Migrate: select this option when the configuration package is complete. The rules and transactions associated with the package will unlock and be available for use.
-
Put on Hold: select this option when the package is not ready to migrate but the rules and transactions associated with the package can be released so other users can access them.
-
Add Non-Palette Items: select this option to attach stored procedures, DDL scripts, or SQL scripts to the configuration package.
Configuration Package Right-Click Options
Create Migration Set
After a configuration package is marked Ready to Migrate, the package is moved to the Migration Sets folder in Release Management, which is located on the Admin Explorer tab. The Build Manager (or BA with administrative privileges) will create a migration set that includes the configuration package as well as any other packages that are relevant.
Release Management Folder Hierarchy
-
Migration Sets: right-click to create a migration set. Select configuration packages to add to the migration set.
-
Release Packages: right-click to create release package. Select one migration set for the release package.
-
Name of Release Package Created: right-click on the name of the release package to build the package. Right-click again to promote the package. The right-click option for the stage that the release package is currently in will be visible. For example, if it has already been built, then the only right-click action available will be Promote.
Once the migration set is promoted, it will move from the Built folder to the Promote folder. The package will continue to move through the folder structure as it advances through the release process.
Release Management Hierarchy in Main Explorer
Create Release Package
After the migration set is created, create a release package. The migration set will remain in the Migration Set folder.
Build Release Package
After the release package is created, the Build Manager will need to go back to the Release Management folder in Admin Explorer. From that folder the release package can be built by right-clicking the package and selecting Build Release Package. Once the package is built, the right-click menu option will change to Promote.
Promote Release Package
After the package is marked ready to promote, log-out of the source environment and log-in to the target environment. From the Admin Explorer, locate the Release Management node. Open the folder and look for Release Packages. The release package should be listed under the Release Package | Ready to Promote node. First, approve the package. The Release Package-ApprovePromotion security privileges must be granted to users who are responsible for approving release packages. Approved packages are moved to the Promoted folder. Open the Promoted folder and deploy the package. After completing these three actions, the right-click menu for the release package will disappear and the package is moved to the Deployed folder. The migration is complete.