Release deferral
Ping Identity lets you defer regular channel releases to your production tenant environments for up to 7 days. This gives you the opportunity to test and validate new regular channel releases in your lower environments (development, UAT[1], and staging) using your most up-to-date configuration.
Each scheduled major release is eligible for deferral. The deferral period has the following characteristics:
-
It begins when the major release is deployed to your lower environments.
-
It ends 7 days later, or sooner if you choose.
-
It isn’t extended for minor version updates (for example,
15158.1to15158.2). These incremental updates are part of the same scheduled major release and don’t restart the deferral period.
As part of your Advanced Identity Cloud onboarding, you can specify a preferred upgrade time in UTC. This is the exact time of day that the release upgrade is deployed to your production environment at the end of the 7-day deferral period, allowing alignment with your preferred maintenance or change window. You can change the automatic upgrade time for future releases by creating a support case in the Ping Identity Support Portal.
Release upgrade options
During this 7-day deferral period, you have several options for managing the release upgrade to production:
-
Default option: At the end of the 7-day deferral period, at your UTC preferred upgrade time, the release upgrade is automatically deployed to your production environment.
-
Self-service option: Trigger the deployment of the release upgrade to your production environment at any time by running a promotion from your staging environment to your production environment.
The deployment of the release upgrade to your production environment is triggered by the first promotion to that environment during the 7-day deferral period. This means that you must pause promotions to your production environment until you have validated the new release in your lower environments.
-
Support-assisted options:
-
Upgrade without a promotion: Apply the release upgrade to your production environment without promoting any changes from staging. To do this, create a support case in the Ping Identity Support Portal to request an upgrade.
-
Promote without an upgrade: Promote configuration changes to production but wait to apply the release upgrade. To do this, create a support case in the Ping Identity Support Portal to request the configuration promotion. This option is only available if the configuration changes you’re promoting are compatible with the release version currently in your production environment.
Learn more about configuration promotion and version compatibility
If your changes were made after your staging environment was upgraded, they might depend on the new release and can’t be promoted without also upgrading production.
Scenario 1: Compatible changesYou made configuration changes before your staging environment was upgraded to the new release.
The changes can be promoted to production without the release upgrade because they’re compatible with the older version.
Scenario 2: Incompatible changesYou made configuration changes after your staging environment was upgraded.
The changes can’t be promoted to production without the release upgrade because they could depend on features only available in the new version.
-
Additional considerations
-
If you’ve recently promoted an upgrade to production on a deferred release, you can roll back both the upgrade and the promotion by creating a support case in the Ping Identity Support Portal.
-
In the rare event that Ping Identity applies a hotfix to the major release while you’re testing it in the lower environments, only the minor version changes, so the 7-day deferral period in your production environment isn’t extended. This ensures that Ping Identity can apply security updates quickly and effectively, without impacting the cadence of scheduled regular channel releases.
-
You can use the release information from your production environment to track the 7-day deferral period.
Release upgrade schedule
Release deferral changes the schedule that release upgrades follow when they are deployed to your tenant environments.
Example upgrade scenario
The following example illustrates the upgrade sequence. It assumes the following:
-
A 7-day deferred release period.
-
The current version is 12300.1 and the new version to be deployed is 12345.1.
-
Version 12345.1 becomes available on May 1.
-
You choose not to promote the release manually to production during the deferral period.
| Date | Main region |
|---|---|
May 1 |
|
May 8 |
|