Table of Contents

Article

Deploying application changes to your staging or production environment

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 environments. As a Pega Cloud 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 and Pega Cloud service level agreement.

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

The user who imports the archives must have the zipMoveImport and SchemaImport privileges on the target system.

  1. Ensure that you have connectivity to both the target system and to the location where the archives are stored.
  2. Use the prpcServiceUtils command line utility to import the archives to the target system:
    • Deploy the Rules archive by following the steps in Importing archive files (service-enabled). Your changes are sent to the system, imported to the database, and ready for activation.
    • Deploy the Data archive by following the steps in Rolling back and committing tracked data. When you deploy the Data archive, you use the same tool that you used to deploy the Rule archive but with different properties. You can roll back these changes if required.

For information about allowing automatic schema changes, see Editing administrator privileges for importing archives with schema changes into production.

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.

  1. On the target system, create a copy of the access group for your application. This step is a one-time process, because now this access group is available anytime you deploy changes.
  2. Update the copied access group so that it references the new Application version.
  3. Find the Operator record for a test user and give that Operator record access to the access group that you just created.

You can now safely test your changes in the system at the same time as other users who are running on the previous version.

When you are satisfied that your release was deployed successfully, Release Engineering can activate the release for all users in the production environment.

If you experience any issues, refer to Rolling back a problematic deployment.

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.

Data changes, including schema changes, take effect immediately after being imported to the system. Your application might be able to access these fields immediately. After testing and when you are sufficiently comfortable, you should commit these changes. To commit data changes, follow the steps in Rolling back and committing tracked data.

To activate rule changes, you need to update the access groups that point to the prior version of your Application rule:

  1. In Designer Studio, open the Records Explorer.
  2. Navigate to the Access Group item in the Security category.
  3. Search for the access groups to be updated by specifying your application name in the search box and filtering the list.
  4. After you locate the access group, open the record and increment the version number for your application to the new release version.
  5. Click Save.
If you deploy code changes that need to be compiled, you must restart the system. Code changes cannot be made without downtime, and your System Administrator must perform a system restart. For information about the types of changes that you can make within a release, the release types, and the release management process to follow, see Application release changes, types, and processes.

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.

  1. Ensure that no new operators can access the problematic application. You can temporarily disable access to the entire system. For more information, see How to temporarily disallow new interactive logins with a Dynamic System Setting.
  2. Roll back the problematic rules changes. You can roll back changes by updating the access group for your application and specifying the previous version of your application.

Roll back the data instances that you changed to their previous version. To roll back data changes, use the prpcServiceUtils command line utility. For more information, see Rolling back and committing tracked data. This process replaces those modified data instances with their prior definition, rolling back your data changes to the last known, good state.

Published December 19, 2016 — Updated November 28, 2017


100% found this useful

Related Content

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.