As part of the Standard Release process for migrating your application changes from development to production, you set up and package the release on your shared development 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:
- Creating the release target (ruleset version)
- Locking the release
- Creating the application archives
After you set up and package the release, you are ready to deploy the changes to your staging or production environment.
Creation of the release target
When developers merge changes by using the Merge Wizard, they must select the ruleset version to which to merge them. The Release Engineer is responsible for ensuring that each release has an unlocked ruleset version that acts as the release target and into which these merges can be performed. Developers are responsible for merging their branches into the correct, unlocked ruleset version and addressing any conflicts.
Locking the release
After all merges are completed, the Release Engineer locks the applications and rulesets to be released. They are also responsible for creating the new, higher-level ruleset versions and higher-level Application rules for the next release.
- In Designer Studio, click
- Click Lock & Roll.
As a best practice, lock your built-on applications first, and then work your way up the stack to your top-level application. This way, as each higher version Application rule is created, you can open that rule and update the version of the built-on application.
- For each ruleset:
- Click Lock and provide a password.
- Click Roll.
- Click Create a new version of my Application.
- Click Run.
As a result, the Application rules and ruleset versions for the current release are locked and require passwords to make changes. Also, you will have created the higher-level ruleset versions and Application rules that will be used for the next release.
For more information, see Ruleset Stack tab - Application Structure landing page.
Creating the application archives
For each release, you create one or two RAP archives, depending on the changes you made to your application. The user who exports the archives must have the zipMoveExport privilege.
These RAP archives include:
- The Rules RAP, which contains the Rules portion of your release, instances from Rules- types only, and all rules changes.
- The Data RAP, which contains the Data portion of your release, instances from Data classes only, and all data changes.
Splitting the release into a Rules RAP and a Data RAP provides you with more control over the deployment and activation of your changes on other systems.
More RAP archives might be created during the development process. Import these RAP archives to a single system from which the Rules RAP and Data RAP will be created. This method provides the greatest level of control over the release by separating the release process from the development process.
- Define the RAPs by using the Application Packaging wizard or by copying an existing RAP rule.
- Export each RAP as an archive:
- Use the Export gadget.
- Provide a standard name for the archive, such as Application-01-01-02.zip.
- Store these archives in a standard location to which you have access, and that will be accessible during deployment.
A Rules archive and a Data archive are created as the result of this process.