Question
First Citizens Bank
US
Last activity: 11 May 2020 20:11 EDT
Pega 8 upgrade and How it works
Historically, Pega has been providing “Hot fixes” for the existing version of Pega to fix any issues. Vs Now , the solution has been to upgrade to a new version to fix any new issues that arise. As, you now that the Upgrade takes huge efforts and resources, so, trying to gauge their(Pega) views, and confirm if this is the only solution(Upgrade) provided to all the customer, and also check if any alternatives available to fix minor bugs without upgrading.
For example: If we upgrade from 7.2.2 to 8.3.2 version and had a product related issue, Now Pega asked us to upgrade to 8.4.1 to fix the issue , How can we better handle this kind of scenario's. (We don't know what else got changed in 8.4.1 and have to spent same amount of time in respect to regression testing and fixing any functionality issues that identified as a part of this upgrade)
Could you please share your experience and opinions ?
Pegasystems Inc.
US
This is a very important subject at Pegasystems. I only have visiblity into a slice of what is going on... but here's my take. Understanding the current strategy depends on a couple points:
This is a very important subject at Pegasystems. I only have visiblity into a slice of what is going on... but here's my take. Understanding the current strategy depends on a couple points:
- Mass hotfixing causes lower quality software because it is not possible to test (either manually or automated) all the different possible combinations of hotfixes available. Personally, I've seen Pega's quality go up over the 8.x series becaues when you get a specific patch, say 8.3.2: 100% of fixes applied since 8.3.1 have gone through extensive testing in all parts of the product so any bad interactions between fixes have a much higher chance of getting caught now compared to the 7.x hotfix approach.
- In the old world of Hotfixes, when you got one hotfix, you might also be forced to take a small or large number of dependent hotfixes. This means that if you want to just keep up with security patches you are forced to take any hotfixes with dependencies. In 8.x, we are focusing on putting only the most important fixes into patch versions. This reduces the risk associated with keeping your system on the latest patch release for your minor release. For example, going from 8.2.1 to 8.2.2 to 8.2.3 should be significantly safer.
- PegaUnit test automation has improved very significantly in 8.x. So with some investment in the creation of PegaUnits, not only will you have more confidence when introducing your own changes to production, you can also be confident when you upgrade that there are fewer regressions. Of course, test automation is a journey so I'm not suggesting that it's going to solve all your problems, but it is worth noting that it has improved. Even just creating test automation for new features and bug fixes will improve your application quality over time. Before you know it, you'll have a good regression suite.
- Upgrade tools will also continue to improve. Just one example: my team is currently working on some exciting features around adding visiblity to new overrides when upgrading from one 8.x version to another. It's not going to solve every problem ever, but it will address some common pain points.