In the database I’m currently working with I know that there are hundreds of customizations that have been created and deployed into my database by my predecessors.
As I look to the job of migrating to V16. I already know that about 1/2 of those customizations will have to be updated or deprecated in some way because they rely on Membership or other items changed in version 16.
How are folks managing the code and documentation for your local customizations? In my case this could be hundreds of files.
How are you planning to track which customizations have to be changed or modified in some way when you go to V16? Which ones are done and which ones still need work?
How are you planning to do the deployment of these changes in a quick and reliable way on the day of your v16 upgrade.
I’ve been looking into using a git repo to manage these 2-3 sets of files(current v15 production, v15 test/development, v16 staged changes). However, I’ve not found a good way to work with multiple repo branches for Tessitura instances in Tessitura Hosting Services (RAMP).
Thoughts? How big is your challenge going to be migrating to V16?
Hi Tom,
We're using our help system to create a Project that will assign a milestone and tasks per customized item that needs to be addressed before we can upgrade. I try to keep it to one task per item (but if you have hundreds, that could get cumbersome) because I can assign it to specific individuals for review/repair/deprecation and we can assign the amount of time it has taken to correct this issue. We can then attach the Project to a Change and will use that as our source of best practice for annual auditing.
Deploying these changes are a little simplistic: Once a task is completed, tested and approved, it is staged in a SQL script that will be executed after we run the upgrade, and a Visual Studio project that will deploy relevant updates. The script and project get attached to our Change, also in case of audit review.
Our migration to v16 is going to be a huge challenge. I don't anticipate making the switch until early 2023. Our team has already put in over 100 hours in beta testing.
Hope that helps,
Nancy
Nancy Sheleheda,
So it sounds like you run one long SQL script with all of the database changes. I have an inclination that I want to keep each database object in it's own seperate file with it's own very basic testing code. However, I've not figured out how to go through a long list of these making the needed changes and noting any problems.
You have spoken about SQL changes what about SSRS .rdl report file changes; .pbl changes if you are still making those; or even parameter changes .xml. Also we loose the SOAP api and will need to stage and update the RAZAR Templets as well.
I'm trying to think now about being organized about all of this.
SSRS reports are part of the Visual Studio project I mentioned. We made it a priority to convert all of our calls from SOAP to REST and that has already been done. If there are HTML templates that need to be updated, we coordinate with our web team at the same time so that gets deployed during our outage. Parameter changes are part of our big SQL script. We just handle the delete/insert/updates directly in the tables via T-SQL.
For a large update like this, we will have a run plan and it involves key members of our team who are all available at upgrade time.
It would be great to have a slick master button that does all of this automagically, but the time and effort it would take to develop that isn't in our best interests right now. We prefer to spend that time beta testing.... finding those 'monsters in the closet', if you will. Our team meets regularly to discuss known and imagine the unknown. We take backups and give ourselves a long maintenance window.
How do you plan to version in Visual Studio?
For example you have on SSRS report for V15 and something about the report has to change for the version you will use in V16?
If you are willing to share I'm also wondering:
At the Pittsburg Cultural Trust you are self hosted. I'm also wondering if this is giving you some additional control over your environment that I may be missing on Tessitura Hosting Services (RAMP).