If so, at what granularity?
Rolling back is achieved by simply deploying an older Release (i.e. the last version that was known to be in a healthy state). This is approach is common to most modern CI/CD tools (Bamboo, Jenkins, etc…). For a user of Bamboo (using MettleCI’s plugins for that system) it is a two-click process. To answer the “granularity” question:
- MettleCI maps each DataStage Project to a corresponding Git Repository
- A check-in of a Job via MettleCI updates the version of that Job in the corresponding Git Repository
- Any change to a Git Repository automatically triggers the the MettleCI-supported continuous integration (CI) testing activity
- If CI completes successfully, this generates a new Release. A Release is a snapshot of the DataStage Project assets that were provided from Git to the successful CI process.
- When MettleCI deploys a Release it compares the contents of that new Release with the older Release that is currently in the target DataStage environment (e.g. "DataWarehouseProject_1" in the DataStage Pre-Production environment). Using the the comparison results, MettleCI pushes only the differences (deltas) between the two Releases into the target DataStage environment. This is an efficiency-focused approach.
So, a Release does correspond to the whole of a DataStage Project but the actual assets (Jobs, etc) that get delivered to a target DataStage Environment during the deployment process are usually a smaller subset, consisting of only those assets that have changed.