You can start deployments in a number of ways. For example, you can start a deployment manually if you are not using branches, by submitting a branch into the Merge Branches wizard, or by publishing application changes in App Studio to create a patch version of your application. Your user role determines if you can start a deployment.

When you pause a deployment, the pipeline completes the task that it is running, and stops the deployment at the next step. Your user role determines if you can pause a deployment.

If your role has the appropriate permissions, you can a deployment to prevent it from moving through the pipeline.

A rollback can be performed on any deployment that encounters an error or fails for any reason. The rollback feature relies on restore points, which are automatically generated every time an import happens. Any change implemented after the import but before the next restore point will be lost when the rollback action is triggered.

If a manual step is configured on a stage, the deployment pauses when it reaches the step, and you can either complete it or reject it if your role has the appropriate permissions. For example, if a user was assigned a task and completed it, you can complete the task in the pipeline to continue the deployment. Deployment Manager also sends you an email when there is a manual step in the pipeline. You can complete or reject a step either within the pipeline or through email.

An aged update is a rule or data instance in an application package that is older than an instance that is on a system to which you want to deploy the application package. By being able to import aged updates, skip the import, or manually deploy your application changes, you now have more flexibility in determining the rules that you want in your application and how you want to deploy them.

If a deployment has errors, the pipeline stops processing on it. You can perform actions such as rolling back the deployment or skipping the step on which the error occurred.

If an application package that is to be deployed on candidate systems contains schema changes, the Pega Platform orchestration server checks the candidate system to verify that you have the required privileges to deploy the schema changes. One of the following results occurs:

As a best practice, you should use Deployment Manager 5.1 or newer to automate your business change management process, run CI/CD pipelines to merge a revision package to the development system of record (SOR), and subsequently deploy that package through to your production environment by using a deployment pipeline.