DevOps Automation

Rollback Process Design for zOS Deployment in UrbanCode Deploy

UrbanCode Deploy ships with a zOS Utility plugin which contains Deploy Data sets and Rollback Data sets steps to perform deployment and rollback on environment target datasets respectively. This blog will not talk about how these steps work instead, we will focus on how to design the Application Process and Component Process for Rolling back a deployed component version.

Component Process Design

Before we jump into process design, let's understand Environment Inventory and Compliance, Inventory management, and Component Process Type and their relation.

Environment Inventory and Compliance

The inventory for an environment shows the component versions that are intended to be deployed to an environment. The compliance level shows the component versions successfully deployed to that environment. A component version is set as non-compliant in the inventory when deployment is failed.

For example, the below picture shows UAT environment has two successfully deployed component versions, hence seen as compliant (Green) whereas the TEST environment has a successfully deployed version and a failed version due to which we see the environment as non-compliant (Red)


Read more on environment inventory and compliance here

Inventory Management

When you create application processes, you can either allow the UCD server to manage the environment inventory and compliance automatically or manage the inventory and compliance yourself.

You can change Inventory management at an application process level under the configuration tab as shown below.



If the Inventory Management is set to Automatic (default), the server automatically updates the inventory and compliance for each environment. When you run an application process, the server adds the selected component versions to the environment inventory. Similarly, when component processes run, the server updates the inventory to show which component versions were deployed and which component versions were not.

To manage the environment inventory and compliance manually. You add steps that make specific changes to the inventory and compliance as below

1. In the settings for the application process, set Inventory Management to Advanced.
2. In the application process, add steps to install, uninstall, or configure component versions as usual.
3. Add the Component Inventory Update utility step, and then specify the properties for the step as described in Inventory Update. For example, to add a component version to the inventory and set the compliance to active, specify the following properties: select the component from the Action list, select Add Desired Inventory; and from the Status list, select Active.

Component Process Type

There are five process types -

1) Deployment
2) Configuration Deployment
3) Uninstall
4) Operational (With version) and
5) Operational (No version needed)

For z/OS Deployments and Rollback, Deployment and Uninstall process types are used respectively.
When an application process with automatic inventory management invokes the component process of types Deployment, Uninstall, and Operational (With version). It alters inventory as shown below.


As shown above, we will have a problem with the z/OS rollback process with the process type uninstall. During a failure in the rollback process, the component version is removed from inventory. This causes problems with preventing risky rollback for component versions.

Switching to a new design to fix the issue with uninstall process type

Following changes needs to be made in your current rollback application process
1) Under process configurations, set inventory management to Advanced to later manage the inventory in the application process for rollback.
2) Under process design, add the Component Inventory Update step before the Finish step as shown below.
       a) Select component
       b) Set Action to Remove Desired Inventory
       c) Set For Which Versions? to All selected (Manual uninstall)
       d) Status is kept Active

 
In case of any failure in the rollback component process, the version will not be removed from the environment inventory. We can rerun the rollback process after the issue is fixed and only when the component process is executed successfully the last step of the application process Component Inventory Update removes the version from the environment inventory.