Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Deploying application changes to your staging or production environment

Updated on April 5, 2022

As part of the Standard Release process, after you set up and package a release on your shared development environment, you can deploy your application changes to your staging or production environment.

This Standard Release process applies to both on-premises and Pega Cloud Services environments. As a Pega Cloud Services customer, if you use this self-service process to release changes to your application, you are responsible for those changes. For more information, see Change management in Pega Cloud Services and Service level agreement for Pega Cloud Services.

This process involves completing the following steps:

  1. Deploying the application archives
  2. Testing the deployment
  3. Activating the release for all users

In the event of any issues, you can roll back the deployment and restore your system to a state that was previously known to be working.

Before you deploy application changes, you must know about the types of changes that you can make within a release, the release types, and the release management process to follow based on the changes you want to deploy. For example, SQL changes that remove columns from database tables or remove data types can interrupt service for users of the application. You must deploy these types of changes during scheduled downtime when users are offline. For more information, see Understanding application release changes, types, and processes.
  • Deploying the application archives

    After you create the application archives, deploy them to your target system. This process is the best way to deploy changes into your staging or production environment, control their activation, and recover from problematic deployments.

  • Testing the deployment

    After you deploy the changes, the release engineer and specified users can test the changes. For the staging environment, test the performance and the user interface, run automated tests, and do acceptance testing. For the production environment, perform validation tests.

  • Activating the release for all users

    After your Rules archive and Data archive are successfully deployed, changes are activated in various ways. Activation is the process by which a category of changes becomes usable by appropriate users of the system, if they have access.

  • Rolling back a problematic deployment

    In the event of a problematic deployment, the first goal is to prevent further issues from occurring. Then you can roll back the deployment and restore your system to a state that was previously known to be working.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us