Hey Mike,
When it comes to application upgrades, there are only two possibilities. You either recreate the customizations, or you recreate the changes the product team has made. The process you are describing is the traditional upgrade approach where you stand up a new instance of the version you are going to, and then you recreate customizations to the customized out of the box objects and you also migrate over the dependent custom objects so that everything stays connected. So not everything custom gets migrated. An OM package is then created and the new objects are move back in to your dev environment. One of the drawbacks of this approach is the high probability for human error that could impact customizations. I no longer use this approach and I don't have to recreate any customizations to do an application upgrade. Using proprietary tools that I've created I'm able to very quickly and accurately see all the changes made by the product team. I can then merge in those changes where there is overlap, and object migrate those objects that are net new. The advantage of this approach is it allows me to do application upgrades much quicker and more accurately.
Regardless of the approach that is used though, the most important things that can be done to make upgrades easier and more accurate is to use naming convention inside of workflows and to utilize object labels for customized objects. The naming convention will give the best bang for the buck as it can greatly reduce the amount of analysis necessary when merging workflow logic. Since the analysis portion of an application upgrade is the longest and therefore most expensive part. The other thing that you can do is to maintain accurate test scripts for your functionality. That way when you do upgrades you can validate that your custom functionality still works and did not get broken in the process.
I'm very passionate about application upgrades and I have spent a lot of time improving the process and creating best practices. So I could go on for hours talking about them. I'll save you from that though. If you do have any questions, around application upgrades or best practices, I'd be happy to have a chat.
All the best in your TRIRIGA journey.
--Mark
------------------------------
Mark Johnson
Senior Architect
Wipro
------------------------------
Original Message:
Sent: Wed June 22, 2022 02:22 PM
From: Mike Aleski
Subject: Strategies for tracking TRIRIGA customizations and applying to future upgrades?
I've recently learned that when upgrading TRIRIGA, that there is no way to install a TRIRIGA upgrade and preserve all the various customizations that have been applied to the TRIRIGA environment over time. You basically have to start with a new OOB build of TRIRIGA and manually apply every customization to the new environment to ensure it provides the same needed functionality as the old environment. So I'm curious what strategies do the more experienced admins use to track all the various customizations requested by the business over time to ensure that they can be recreated every time TRIRIGA gets upgraded to a newer version? My current strategy has been to create an implementation plan for every change request that I receive from the business owners and apply to the TRIRIGA system. But when it comes time to upgrade, it's going to be a hassle for me to review a hundred different implementation plans to ensure they all get applied to the environment. So I'm thinking maybe I should try to create a single master document that tracks every change made to the system, and group the information by type of change within TRIRIGA (such as by query, portal, navigation, business object, etc.). But that's also going to be a lot of work, and I've never actually upgraded a TRIRIGA system before, so I'm interested to hear your ideas for addressing this issue before I proceed.
------------------------------
Mike A.
------------------------------
#TRIRIGA
#AssetandFacilitiesManagement