How do roll back features work on Deployment Manager?

Rollback relies on the Restore Points feature of the Pega platform. The Rollback option is presented to the user only when a step errors out in a deployment. A restore point is automatically generated every time an import happens. Any changes that happen after the import and before the next restore point is generated by any application will be rolled back is the rollback action is triggered. Consider this an alternative to database level restore and rollback for every import at this point in time.

• For pega versions 8.3 and earlier the rollback execution impacts the entire system and is not scoped to the application. Be careful about using restore when there are multiple independent applications on the system.
• For pega version 8.4 and later with PegaDevOpsFoundation 4.8 and later, this will be an application level rollback which will have no impact on other applications.

How do I rollback a successful deployment?

​The rollback feature of Deployment Manager is currently only available for deployment tasks that have failed in some way. When a task fails, the deployment pipeline will pause and let an authorized user, skip the task, rerun the task, abort the task or rollback the current deployment.

• If you would like the rollback option to be available even in situations where the deployment is technically successful, perhaps there was a business decision to rollback, then the best solution is to the do the following
  • Insert a manual step as the final task in the stage where you wish to have the ability to rollback
  • Ensure that the the manual task is assigned to an user who will make the decision to approve/reject the deployment
  • If the deployment is meant to be rolled back, then reject the deployment either through email or directly in Deployment Manager
  • This will now present you with the options as shown above to either abort or rollback a deployment
  • You can now successfully rollback the deployment

When should a deployment be aborted and when should it be rolled back of a candidate environment?

​The decision to abort is really a deployment best practices or business decision, but it is worth clarifying the outcomes between these choices.

• Abort
  • if you think there is no harm in keeping in the current deployment that failed in the environment (perhaps this is true in QA or other isolated testing environments)
  • if there are other applications being deployed into that environment and you want to avoid rolling back those application changes as well. Currently rollback is environment wide and will affect all users and applications.
  • if there are other users using the environment or is otherwise being used outside of the pipeline tasks (see point above)
• Rollback
  • if you do not want to have the failed deployment potentially impact any future deployments, this should be rare, but there is a potential
  • if the deployment was corrupted in some way and it is safest to rollback
  • if you do not want any user to accidentally use the invalid deployment which could have unknown side effects, particularly critical in Production and perhaps Staging

Are schema changes rolled back?

No. The schema changes that the platform will apply automatically are only additive. At this time rolling back schema changes is not supported, with the expectation that having additional columns or expanded column widths would not drastically impact the system. If something like this were required to be rolled back, it would require a manual intervention to prevent data loss.

This is a frequently asked question about Deployment Manager. Find more answers here.