Challenge
In selectively migrating objects from one repository folder to another, there is a need for a versatile and flexible mechanism that can overcome such limitations as confinement to a single source folder.
Description
Regulations such as Sarbanes-Oxley (SOX) and HIPAA require tracking, monitoring, and reporting of changes in information technology systems. Automation of change control processes using deployment groups and pmrep commands provide organizations with a means to comply with regulations for configuration management of software artifacts in a PowerCenter repository.
Deployment Groups are containers that hold references to objects that need to be migrated. This includes objects such as mappings, mapplets, reusable transformations, sources, targets, workflows, sessions and tasks, as well as the object holders (i.e., the repository folders). Deployment groups are faster and more flexible than folder moves for incremental changes. In addition, they allow for migration rollbacks if necessary. Migrating a deployment group involves moving objects in a single copy operation from across multiple folders in the source repository into multiple folders in the target repository. When copying a deployment group, individual objects to be copied can be selected as opposed to the entire contents of a folder.
There are two types of deployment groups - static and dynamic.
- Static deployment groups contain direct references to versions of objects that need to be moved. Users explicitly add the version of the object to be migrated to the deployment group. If the set of deployment objects is not expected to change between deployments, static deployment groups can be created.
- Dynamic deployment groups contain a query that is executed at the time of deployment. The results of the query (i.e., object versions in the repository) are then selected and copied to the deployment group. If the set of deployment objects is expected to change frequently between deployments, dynamic deployment groups should be used.
Dynamic deployment groups are generated from a query. While any available criteria can be used, it is advisable to have developers use labels to simplify the query. When generating a query for deployment groups with mappings and mapplets that contain non-reusable objects, in addition to specific selection criteria, a query condition should be used. The query must include a condition for Is Reusable and use a qualifier of either Reusable and Non-Reusable. Without this qualifier, the deployment may encounter errors if there are non-reusable objects held within the mapping or mapplet.
A deployment group exists in a specific repository. It can be used to move items to any other accessible repository/folder. A deployment group maintains a history of all migrations it has performed. It tracks what versions of objects were moved from which folders in which source repositories, and into which folders in which target repositories those versions were copied (i.e., it provides a complete audit trail of all migrations performed). Given that the deployment group knows what it moved and to where, then if necessary, an administrator can have the deployment group undo the most recent deployment, reverting the target repository to its pre-deployment state. Using labels allows objects in the subsequent repository to be tracked back to a specific deployment.
It is important to note that the deployment group only migrates the objects it contains to the target repository/folder. It does not, itself, move to the target repository. It still resides in the source repository.
Deploying via the GUI
Migrations can be performed via the GUI or the command line (pmrep). In order to migrate objects via the GUI, simply drag a deployment group from the repository it resides in onto the target repository where the referenced objects are to be moved. The Deployment Wizard appears and steps the user through the deployment process. Once the wizard is complete, the migration occurs, and the deployment history is created.
Deploying via the Command Line
Alternatively, the PowerCenter pmrep command can be used to automate both Folder Level deployments (e.g., in a non-versioned repository) and deployments using Deployment Groups. The commands DeployFolder and DeployDeploymentGroup in pmrep are used respectively for these purposes. Whereas deployment via the GUI requires stepping through a wizard and answering a series of questions to deploy, the command-line deployment requires an XML control file that contains the same information that the wizard requests. This file must be present before the deployment is executed.
The following steps can be used to create a script to wrap pmrep commands and automate PowerCenter deployments:
- Use pmrep ListObjects to return the object metadata to be parsed in another pmrep command.
- Use pmrep CreateDeploymentGroup to create a dynamic or static deployment group.
- Use pmrep ExecuteQuery to output the results to a persistent input file. This input file can also be used for AddToDeploymentGroup command.
- Use DeployDeploymentGroup to copy a deployment group to a different repository. A control file with all the specifications is required for this command.
Additionally, a web interface can be built for entering/approving/rejecting code migration requests. This can provide additional traceability and reporting capabilities to the automation of PowerCenter code migrations.
Considerations for Deployment and Deployment Groups
Simultaneous Multi-Phase Projects
If multiple phases of a project are being developed simultaneously in separate folders, it is possible to consolidate them by mapping folders appropriately through the deployment group migration wizard. When migrating with deployment groups in this way, the override buttons in the migration wizard are used to select specific folder mappings.
Rolling Back a Deployment
Deployment groups allow the last deployment to be rolled back. This allows for a documented method for backing out a deployment if it should be necessary. To do this:
In the target repository (where the objects were migrated to), go to:
Versioning>>Deployment>>History>>View History>>Rollback.
The rollback purges all objects (of the latest version) that were in the deployment group. Initiate a rollback on a deployment in order to roll back only the latest versions of the objects. The rollback ensures that the check-in time for the repository objects is the same as the deploy time. Also, pmrep command RollBackDeployment can be used for automating rollbacks. Remember that you cannot rollback part of the deployment, you will have to rollback all the objects in a deployment group.
Deployment Group Enhancements
Non-versioned repository.Non-versioned repositories provide the ability to create and edit deployment groups. Additionally, deployment groups can be copied between versioned and non-versioned repositories. When a dynamic deployment group is copied, the Repository Service converts it to a static deployment group. In non-versioned repositories, if objects that exist in the deployment group also exist in the target repository, the existing objects are deleted by the deployment operation and new objects are created.
Execute Deployment Groups privilege. The Execute Deployment Groups privilege provides the ability to copy a deployment group without having write permission for the target folders. However, read permission for the source folders and execute permission for the deployment group is necessary in order to copy the deployment group.
Post-deployment validation.After a deployment group is copied, the target repository can be validated to verify the legitimacy of objects and dependent objects.
Managing Repository Size
As objects are checked in and objects are deployed to target repositories, the number of object versions in those repositories increases, as does the size of the repositories.
In order to manage repository size, use a combination of Check-in Date and Latest Status (both are query parameters) to purge the desired versions from the repository and retain only the very latest version. Also all the deleted versions of the objects should be purged to reduce the size of the repository.
If it is necessary to keep more than the latest version, labels can be included in the query. These labels are ones that have been applied to the repository for the specific purpose of identifying objects for purging.
Off-Shore, On-Shore Migration
In an off-shore development environment to an on-shore migration situation, other aspects of the computing environment may make it desirable to generate a dynamic deployment group. Instead of migrating the group itself to the next repository, a query can be used to select the objects for migration and save them to a single XML file which can be then be transmitted to the on-shore environment through alternative methods. If the on-shore repository is versioned, it activates the import wizard as if a deployment group was being received.
Code Migration from Versioned Repository to a Non-Versioned Repository
In some instances, it may be desirable to migrate objects to a non-versioned repository from a versioned repository. Note that when migrating in this manner, this changes the wizards used, and that the export from the versioned repository must take place using XML export.