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

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.

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.