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:
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.
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.