With minimal disruption, you can safely migrate your application changes throughout the application development life cycle, from development to deployment on your staging and production environments. 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.

The process that you use to release changes to your application is different depending on the types of changes that you are making. This article describes the Standard Release process that you can use to deploy changes to rules, data instances, and Dynamic System Settings. The Standard Release process is a self-service way to deploy changes without downtime. Other methods for releasing changes to your application are not covered in this article. For more information, see Application release changes, types, and processes.

For Pega Platform^TM 7.2 and later, the Standard Release process includes the following steps and is scalable to the number and types of environments that you have:

1. Set up and package the release on your shared development environment:
   1. Create the release target.
   2. Lock the release.
   3. Create the application archives.
2. Deploy the changes to your staging or production environment:
   1. Deploy the application archives.
   2. Test the deployment.
   3. Activate the release for all users.

Requirements

Your environments and applications must meet the following requirements:

• You have at least two existing Pega Platform environments. These environments can be any combination of sandbox and production environments, and can be on-premises or in the Pega Cloud virtual private cloud (VPC).
• You have the ability to log in to a machine from which you will complete the release process outlined in this article, such as your organization's laptop, workstation, or server.
• You have a location on a file system with enough available space to store the RAP archives. You must be able to download the RAP archive to this location and upload a RAP archive to another system from this location.
• You have complied with stated application guideline and guardrail requirements.
• Your Application rule must specify rulesets that have a patch version. Most Application rules have the ruleset version in the stack set to 01-01, such as "RuleSet: 01-01". You must change this to specify your rulesets to the patch level of their version, which is "RuleSet: 01-01-01". This is required for your top-level Application rule and all built-on applications, except the base PegaRULES built-on application. This application structure gives you greater control over the release of your software, minimizes the impact of the release on application users, and provides for the smoothest recovery path in case of a troubled deployment.

Supported development scenarios

This release process supports the following scenarios:

• All developers in the organization use a single shared development environment (recommended by Pegasystems).
• The organization follows a distributed development model, where individual developers or development teams have their own isolated development environments.

The release process works for either development scenario, because it begins after changes have been merged into the appropriate ruleset versions. Regardless of development scenario or team size, development teams must use branching and merging for releasing applications. Otherwise, you cannot take full advantage of the tools and capabilities of the Pega 7 Platform. For more information, see Using branch rulesets and merging branches for parallel development.