Is it possible to rollback deployments?

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.

Is it possible to automatically rollback when a deployment fails?

It's certainly possible to configure this in your build and deployment pipeline, however a failed deployment will normally indicate an infrastructure or some other non-code-related error which will not be resolved by re-attempting the deployment of a different version of the code.  Remember that the only place that a deployment could be potentially expected to fail is during its deployment to the Continuous Integration environment which does not require an automated recovery process.  In the case of CI you simply fix the code which caused deployment to fail and re-submit to Git to invoke another CI build.