Question
Labb Ltd
GB
Last activity: 27 Jul 2022 6:40 EDT
Pega Patch Upgrades
Hi all,
Given that Pega 8.4 is launched, we are starting to think of streamlining the process of the Pega patch upgrade with our release cycle.
I understand that with patch releases, the idea is to upgrade the platform frequently to leverage all the latest features and product fixes. But to perform a risk-free upgrade, it's better if upgrade dev first at the beginning of the release cycle and as the release build code moves to each environment as a prerequisite we can upgrade each Testing/Pre prod/Prod environments so that testing would mitigate any regression issues caused with the upgrade.
But in the above process, the main limitation is when a production priority issue comes while Dev is on 8.4 but Production can be on 8.3.1. To provide a fix we will end up building jar from 8.4 and deploy it in Prod 8.3.1.
Though it technically works for bug fixes, I am not fully convinced.
Is building jars from higher version to lower version of same major release fully supported by Pega?
Is there any other risk-free approach for patching environments?
Thanks & Regards,
Murali
Accepted Solution
Updated: 27 Jul 2022 6:40 EDT
Pegasystems Inc.
US
This is a great question and the thought given to a standardized upgrade process is much appreciated.
To your direct question, this type of forward compatibility is not supported and is highly risky. Rules developed in later platform versions could have data model changes and more importantly implicit dependency of features introduced in the later versions which are simply incompatible with older platform version. These types of implicit dependencies are not easily identified and can cause significant issues.
Based on the ask, which is how to streamline the upgrade process, there are really two types to be considered, Patch upgrades, ex 8.N.next and Minor release upgrade, ex 8.Next. Patch upgrades are significantly lower risk and the recommendation is upgrade as frequently as possible. Patch upgrades are designed to be full backward compatible and only address critical bugs and security related issues that would otherwise require a hotfix, they do not include feature enhancements. Minor version upgrade include feature enhancements but are designed to be backward compatible. Patches could likely be applied directly with minimal validation, for example by patching Staging, is smoke testing is successful to patch Production and then all lower environments. Minor upgrades will typically require more validation even with the emphasis on backward compatibility and hence starting with lower environments is the right call. However as you noted starting with Dev can be problematic.
This is a great question and the thought given to a standardized upgrade process is much appreciated.
To your direct question, this type of forward compatibility is not supported and is highly risky. Rules developed in later platform versions could have data model changes and more importantly implicit dependency of features introduced in the later versions which are simply incompatible with older platform version. These types of implicit dependencies are not easily identified and can cause significant issues.
Based on the ask, which is how to streamline the upgrade process, there are really two types to be considered, Patch upgrades, ex 8.N.next and Minor release upgrade, ex 8.Next. Patch upgrades are significantly lower risk and the recommendation is upgrade as frequently as possible. Patch upgrades are designed to be full backward compatible and only address critical bugs and security related issues that would otherwise require a hotfix, they do not include feature enhancements. Minor version upgrade include feature enhancements but are designed to be backward compatible. Patches could likely be applied directly with minimal validation, for example by patching Staging, is smoke testing is successful to patch Production and then all lower environments. Minor upgrades will typically require more validation even with the emphasis on backward compatibility and hence starting with lower environments is the right call. However as you noted starting with Dev can be problematic.
Here is our recommendation if you wanted to standardize the process, both for patches and minor upgrades. The steps below captured by the diagram below is the one implemented on Pega cloud and is the process that Pega recommends all customers follow.
- Clone and upgrade Staging as this is the closest approximation to Production
- Test client applications on upgraded staging and make any necessary fixes
- After testing is complete, upgrade Production
- Migrate any necessary fixes to upgraded Production
- Once Production upgrade is successful, then upgrade all lower environments
- Migrate necessary fixes to Development and promote to other environments as needed
Following this process, and using an upgraded staging clone, ensures that the standard production pipeline is available for emergency production fixes while upgrade validation is ongoing. Then upgrading Production first before lower environments ensures that if additional fixes are needed in Production before lower environments are upgraded, you have the upgraded staging clone pipeline to do that. This entire process avoids the issue of forward compatibility for rules.
Hope that helps