DevOps Automation

DevOps Automation

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Introducing Smarter z/OS Rollbacks in DevOps Deploy

By Bharath Kumar posted 2 days ago

  

In the world of DevOps, deploying applications on z/OS involves managing different component versions. You have two main types: FULL versions, which contain the entire application, and incremental versions, which package a specific set of file changes. These incremental versions are great for speed and efficiency, as they typically represent a developer's latest committed changes. However, this can lead to situations where different versions share some common files while also having their own unique ones.

This brings us to a critical aspect of application deployment: Rollbacks.

Why Do We Need to Rollback?

Let's face it, sometimes things go wrong. A deployment might introduce a bug, or a planned feature might be pulled from a product release. In a shared environment, stability is key. When a deployed version causes issues, you need a quick and reliable way to remove it and restore the environment to a known good state.

The Challenge of "Risky" Rollbacks

To handle this on z/OS, the Rollback Datasets plugin step in DevOps Deploy is your go-to tool. It’s designed to restore the artifacts that were present right before the problematic version was deployed.

To avoid accidentally undoing necessary changes, the plugin includes a fantastic feature called "Prevent Risky Rollback." This feature stops a rollback if the version you want to remove contains files that have since been updated by a newer deployment.

So, what exactly is a risky artifact?

Imagine you deployed Version 1 with a file named FILE-A. Later, you deployed Version 2, which included an updated version of that same FILE-A. If you now try to roll back Version 1, FILE-A is considered a risky artifact. Why? Because rolling it back would mean deleting the newer, active version from Version 2, potentially causing a whole new set of problems.

This explains a risky artifact

While the "Prevent Risky Rollback" feature is a great safety net, it presents a new challenge. If it blocks the rollback, the problematic version remains in your environment, which isn't ideal. So, how can you safely remove a version when some of its files have been overridden, while others are still active?

The Solution: Rollback Non-Risky Artifacts

We're excited to introduce the "Rollback Non-risky" artifacts feature, now available in DevOps Deploy v8.1.2! This new option gives you the precision to roll back only the parts of a version that won't cause conflicts.

This feature enhances the 'PreventRiskyRollback' input in the Rollback Dataset plugin step. While the default behavior remains the same (to prevent risky rollbacks), you can now choose to roll back only the non-risky artifacts – that is, the files from the version that are still the active ones in your environment.

This powerful new capability works seamlessly for both MVS and HFS artifacts. If your version was deployed to multiple target datasets, the rollback will be handled correctly across all of them.

A Look at the Rollback Options in Action

Let's break down how each rollback option works with a simple setup.

Scenario: Rollback with 'Prevent risky rollback' set to false

When you disable this safety feature, the rollback proceeds without any checks. This can be dangerous as it will remove all artifacts from the version being rolled back, even if they have been updated by a newer version.

The set up of the environment
Action: Rollback Version-1 from the Dev environment
Result : The rollback process succeeds removing the FILE-A and FILE-B from the environment as they were non-existent before Version-1. This action has inadvertently removed the file FILE-A of Version-2
Environment after rolling back version-1

Scenario: Rollback with 'Prevent risky rollback' set to True

With this option, the rollback process is safer. If any risky artifacts are detected, the entire rollback is stopped, and your environment datasets remains unchanged. This prevents accidental deletion of newer files but leaves the problematic version in place

The environment setup for 'Prevent risky rollback to True'
Action: Rollback Version-1 from the Dev environment
Result : The rollback process fails as ‘PreventRiskyRollback’ Feature as there are overlapping artifacts in Version-2
Result of 'Rolling back with Prevent Risky rollback set to True'
Scenario: Rollback with 'Rollback non-risky' artifacts

This is where the magic happens! With this new option, only the non-risky artifacts are removed. The risky artifacts are left untouched, ensuring that your newer deployments continue to function as expected. This allows you to cleanly remove the inactive parts of the old version without destabilizing your environment.

Set up for 'Rollback with Rollback-Non-Risky artifacts'
Action: Rollback Version-1 from the Dev environment
Result : The rollback process succeeds and ‘RollbackNonRiksy’ feature ensures only FILE-B belonging to Version-1
Result of 'Rolling back Non Risky Artifacts'

We're thrilled to bring this enhancement to our z/OS users. This new feature provides a more granular and safer way to manage deployments, helping you keep your environments stable and reliable. Happy deploying!

0 comments
1 view

Permalink

https://community.ibm.com/community/user/blogs/bharath-kumar3/2025/06/25/introducing-smarter-zos-rollbacks-in-devops-deploy