Overview

The Bundles and Promotion feature is designed to facilitate migrating (promoting) groups (bundles) of workload automation definitions (Triggers, Workflows, Tasks, Calendars, Custom Days, Variables, Business Services, Credentials, Agent Clusters, Virtual Resources, Scripts, Email Templates, Email Connections, Database Connections, SNMP Managers, SAP Connections, PeopleSoft Connections, Applications, and Universal Templates) between Universal Controller instances.

This allows you to develop, modify, and test changes in a non-production environment and migrate them to your production environment in a fully secure and audited manner (with back-out capabilities, if required).
 

One or more Workload automation definitions of the same type can be promoted without going through the process of creating a bundle, or you can use a bundle to group together related workload automation definitions of different types for promotion at the same time.

Bundles can be promoted manually or scheduled to be promoted at a specific date and time. If you choose to schedule a bundle promotion, you can either promote the definitions as they stand at promotion time or use a snapshot of the definitions as they stand when the promotion schedule is created. This can be useful if you have completed changes that need to be promoted out-of-hours but want to allow more changes to be made on the source system without having to wait until the promotion is complete.

CLI (Command Line Interface) and API (Application Programming Interface) functions are provided to allow you to integrate the bundles and promotion feature with your external application life-cycle, source management, and change control systems.

If you plan on using the Bundles and Promotion feature, it is important that you review the recommended best practices for this feature.

Bundle and Promotion Security

Use of the Bundle and Promotion feature requires some thought, based on which users require the feature and what functions they need access to.

Bundle Security

The ops_bundle_admin role, which automatically is encompassed within the ops_admin role, grants the following functions:BundlesPromotion Targetsagent mappingsPromotion Historylist of bundlesPromotion SchedulesAdd a record to a bundleCreate bundles by dateBundle ReportUsers can be granted more granular permissions to Bundles via their User or Group permissions:

• Read - View bundles based on name and/or membership of business service.
• Update - View, and Modify bundles based on name and/or membership of business service.
• Create - Create, View, and Modify bundles based on name and/or membership of business service.
• Delete - Delete bundles based on name and/or membership of business service.
• The Promote command for a bundle can be granted or denied via the Bundle permission.

Users can select definitions only for Bundles that they can at least view.

Promotion Security

The ops_promotion_admin role, which automatically is encompassed within the ops_admin role, grants the following functions:Promotion TargetsBundlesRefresh Target AgentsPromote recordsPromoteschedule the promotionPromotion SchedulesGenerate a Bundle report

Users can be granted more granular permissions to Promotion Targets via their User or Group permissions:

• Read - View promotion targets based on name and/or membership of business service
• Update - View, and Modify promotion targets based on name and/or membership of business service
• Create - Create, View, and Modify promotion targets based on name and/or membership of business service
• Delete - Delete promotion targets based on name and/or membership of business service
• The Refresh Target Agents command for a promotion target can be granted or denied via the bundle permission.

The ability to Promote a Bundle without the ops_promotion_admin role requires:

• Read permission to the Bundle
• Permission to the Promote command for the Bundle
• Execute permission to the Promotion Target
• ops_promotion_accept_bundle role assigned to the target user; specifically, the user specified on the Promotion Target or on the Promote Bundle command dialog.

Bundleless Promotion

With the ops_promotion_admin role, users can promote definitions by clicking Promote... in the Action menu.

The Bundleless Promotion With Execute Permission Permitted Universal Controller system property can be set to true (default = false) to allow promotion of definitions outside of a Bundle without requiring the ops_promotion_admin role if the users also have Execute permission to at least one Promotion Target.

Universal Controller Properties

The following Universal Controller system properties also should be reviewed in accordance with the desired behavior of the Bundles and Promotion feature:

• Promotion Accept Bundle Create/Update Permission Required
• Promotion History Retention Period in Days
• Promotion Read Permission Required
• Promotion Schedule Retention Period In Days
• Promotion Strict Mode

Best Practices

Shared Records

Because workload automation definitions have many inter-related records (for example a single task may reference an agent, a credential, and virtual resources), it is important that care is taken to avoid breaking these links between Universal Controller instances when promoting.

For Agents, you can specify agent mappings on the promotion target definition to translate between an agent connected to the source Universal Controller instance and a different agent connected to the target Universal Controller instance.

For other definitions, you should ensure that each definition's UUID (Universally Unique IDentifier) is the same on all Universal Controller instances involved in your promotion hierarchy (Production, QA, Development, etc.).

One best practice for this is to create the definitions on one Universal Controller instance and promote them to the other Universal Controller instances. In some cases, these definitions will need to be different on each Universal Controller instance; for example, a credentials password will be different between the test and production instances. In these cases, you would need to modify them after the initial promotion, and you will need to take care not to promote the test definition and overwrite the production definition with the wrong password.

Another approach would be to use variables for the related definition; for example, a Task definition could use variables to identify its agent and credential definition. Note that variables can be nested, so you can use an instance identifier within the variable.

For example:

• On the PROD instance, the Agent name is PROD_APP_Server and the following global variable exists: ENV = PROD
• On the TEST instance, the Agent name is TEST_APP_Server and the following global variable exists: ENV = TEST

In this case, for the Agent within a Task definition, you would specify the following variable: ${ENV}_APP_Server.

Follow References

When promoting workload automation definitions between Universal Controller instances, you have the option to Follow References, which automatically includes inter-related records when promoting.

In other words, you do not have to build a bundle definition with all of the inter-related records; you can just specify a high-level item such as a trigger or workflow.

Caution should be used when considering the Follow References feature in relation to the shared records you may have on different Universal Controller instances. As of version 6.4.2.0 of the Controller, you have the ability to exclude certain definition types from the promotion when using the Follow References feature. For example, you can follow references and exclude variables.

Note that for some workload automation definitions, there are references that are followed implicitly, even if Follow References is not specified. For example, a workflow will always also promote the tasks within the workflow.

For additional information on Follow References behavior, see Records Promoted When Follow References is Selected or Not Selected.

Modifying Task Names

When modifying a task name, Universal Controller ensures that the vertex data of any workflow task containing that task is updated, assuming a vertex alias is not being used.

To promote the task name modification to another system, promote both the task and any workflow task that would have been modified by the change. You can use the View Parents operation to determine parent workflow tasks. In the case where you modify a task name and do not promote the parent workflow tasks, the vertex names can become out-of-sync.

Promoting Between Different Controller Versions

Promotion of workload automation definitions between Universal Controller instances at different versions is supported from version 6.3.0.0 and later. Promotion can be performed to earlier or later versions as long as both Universal Controller instances are at least at the 6.3.0.0 version.

Promoting to Same or Later Versions

Supported

Promotion from a source Controller to a target Controller of the same or later version, release, modification, and maintenance level is supported.

For example:

• 6.9.0.0 to 6.9.0.1
• 6.9.0.1 to 7.0.0.0
• 7.0.0.0 to 7.0.0.0

Promoting to Earlier Versions

Supported

Promotion from a source Controller to a target Controller of an earlier version, release, modification, or maintenance level is supported if the target Controller has not reached an End of Support Date.

For example:

• 6.9.0.1 to 6.9.0.0
• 7.0.0.0 to 6.9.0.1

Not Supported

Promotion from a source Controller to a target Controller of an earlier version, release, modification, or maintenance level is not supported if the target Controller has reached an End of Support Date.

For example:

• 7.0.0.0 to 6.6.0.1

Bundling and Promoting Process

The general process for bundling and promoting your data is:

These features use web services calls to communicate when you are promoting Bundles of records from one Controller to another.

Diagnosing Promotion Failures