A 'promote' action involves moving artifacts from a lower environment to a higher one within a hierarchical structure of environments. Unlike a FULL version, an Incremental version has a collection of files that are built together. It is important to understand that when you’re deploying an Incremental version, you’re deploying a part of the application to the environment.

In this write-up, we’re going to see how to implement the PROMOTE process in DevOps Deploy.  Promoting artifacts is a common way of deploying in legacy SCMs and many mainframe customers are accustomed to this practice and have their environments structured this way.

The PROMOTE process in DevOps Deploy consists of 2 main steps. 

1. Install the version on the higher environment (copies artifacts).
2. Uninstall the feature from the lower environment (removes artifacts)

Therefore, when performing a promotion, it is crucial to ensure that the uninstallation occurs from the correct lower environment, as a version may not be installed in all of them. During the uninstall process, we must ensure that artifacts from the version are removed without risk. The method for doing this is covered in the following blog post: Smarter rollbacks for zos version in DevOps Deploy

Figure-2: Environments categorized into stages

From the hierarchy, it is evident that QA-1 and QA-2 can have versions promoted from the environments in the lower stage which would be DEV-1, DEV-2, DEV-3. For an environment, it’s important  to know which environments are in their immediate lower stage so that the uninstall can be triggered on them. To achieve this, a property named 'lowerEnvironments' is created within the environment to store the names of the lower environments.

Figure-3: The property 'lowerEnvironment' in the QA environment 

So, the property defined in QA-1 and QA-2, would have the values DEV-1, DEV-2, DEV-3 in it. Similarly, the property defined in UAT would have the values QA-1 and QA-2 and the value UAT for the PROD environment property.

Now we know which environments a version could be promoted from during the PROMOTE process. There’s one more aspect that we need to deal with, it is to know which of the lower environments have the version that we are promoting, so that we run the uninstall process only on those environments and not on all environments in the lower stage. Let’s see how we can do that.

We are going to create version statuses by names of the different environments we have, so we would have statuses like DEV-1, DEV-2 etc. Within the 'component-process' of the 'Install Process' the following steps are added after the application deploy plugin steps, 

• Add the environment name as status to the version. 

• Get the statuses in the version that tells us the environments on which the version is installed. 

• A Groovy step to uninstall on environments common to both "lowerEnvironments" property and the "versionStatuses" from the previous step. Link to the groovy script is  UninstallFromLowerEnvForPromoteInZos.groovy

Figure-4: The new steps in the install component-process 

So far, we have devised a way to add the higher environment name to the version status, identify the lower environment on which the uninstall process has to run and also trigger the uninstall process on applicable lower environments.  This process effectively deploys artifacts to the higher environment and removes them from the lower one.

There’s one last step that still needs to be covered. During the uninstall process that is triggered in the lower environment, it is necessary to remove the ‘environment-name’ from the version statuses as it is getting uninstalled from the environment. To accomplish this, we add the below step as the last step in the uninstall component-process.

Figure-5: Add 'Remove version status' step in the uninstall component-process 

This is one way to implement the PROMOTE feature in DevOps Deploy. If you are looking to DEMOTE artifacts in DevOps Deploy, a similar process could be developed to support 'DEMOTE' functionality with a few adjustments.

We encourage you to try this out and enhance it to fit your specific needs. Happy deploying.