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).
Tom, this is a great question and it seems like this and another thread on the forum are heading to where I want to go -- for RAMP clients, how are you managing version control in general? Does v16 change anything/the need to make your process more straightforward?
I've gone through a number of version upgrades with Tess since 2006, both self-hosted for 10 years and now on RAMP. I'd like to say I have this down to a T by now but given how much is changing in v16 I'm sure there will be some new adventures to figure out. There always are, but that's part of the fun! :)
In terms of deploying changes for v16, I will be deploying as many as I can before v16 is deployed to PROD. (This would be for standalone customizations that don't rely on data structures that are changing in v16.) Anything that needs to wait until v16 has been deployed will be saved into separate files, each named with their object name (i.e. procedure name, view name, etc.) and numbered where necessary so that dependent objects are deployed in the necessary order.
In terms of upgrade planning, the other thing I would suggest, if your organization is self-hosted or can afford a third (or fourth) instance in RAMP, is to have a Development instance of Tess. My process for any upgrade, including service packs (because those really are upgrades), is to deploy to DEV, test/review database structure changes internally and make changes as needed, then ask my staff to look over the front-end, and then only when we are comfortable with the entirety of DEV do we upgrade TEST so that our end users can check it out. For v16 I anticipate that DEV portion taking 2-3 months, but check back in with me after I've actually worked on it for a real timeline. :) My point here is that when you have an extra system to work in, your users can still use the TEST system without butting against any possible upgrade issues, and you can work comfortably at whatever pace you need to in DEV.
I also think this would be a great TLCC discussion but alas, I don't think I'll be getting to go this year. Perhaps a lean coffee for this group is in order?
Katie Lachance-Duffy
It is always a pleasure to hear from you, and learn from your experience,
We both have been through countless upgrades and SP over the years.
I completely agree with you about having a separate dev environment with V16 while holding a V15 test for day to day maintenance, It makes all the difference in the world. I also completely agree that deploying anything that can be made compatible with both V15 and V16 and putting that into the V15 environment before the upgrade is a great solution
I’d add to your list deprecating, archiving and removing any customization that are not being used. This significantly cuts down the amount of work involved with the V16 upgrade, as well as future SP and Upgrades. And do this in the production system prior to the actual day of the upgrade.
Love your idea about naming your files with the database object name. I’ve recently started that practice. I had not thought about the numbering of these files to manage order dependency on objects. Simply Brilliant! I may start to do that when needed.
I’m also using directories to gather files together related to the same customizations. I’ve thought about using shortcuts to files that are common across customizations. (However, I’ve not taken that step yet.)
I’m wondering what’s the approximately number of customization you have in your system. And of those how many you think you are going to have to change to support v16.
The point of my question above was really about tools for managing versioning of the code files when they can’t be in the production database. Are you using file directories on a backed up shared volume some where or something like git. Second for those files that can’t be deployed to production until after production has v16. How do you store and manage those files?
Yes, I'm definitely interested in hearing what others are doing for versioning. (And my upgrade recs in my last reply are by no means an exhaustive list of what we do, but that's another conversation for a different thread. :))
In terms of the number of customizations, how do you count that? We have 160+ custom reports, 40 custom screens, but that doesn't count TNEW forms with their custom parsing scripts or any of the backend functionality in the database. I'm not sure that the number is as important to me as how much it relies on canned structures that might be changing, and that's something I'll tackle once we get v16 in our DEV environment and I can see the actual database structure changes.
For versioning, my current tactic is pretty simple and low-tech, which is why I'd also love to hear about other Hosting clients' solutions to versioning. (What are you all using?) Since I've been the solo programmer here since 2006 I used a method that works well for a small number of people. I do have another colleague who is taking on some programming as well now, so that's another reason I'd love to hear about other methods.
What we do to track changes is: keep a task in the project on our help desk (so really just a file) that lists all of the objects that will be changed along with their change number. That change number is listed in the object itself with the date, the initials of the coder, and a short description of the change, and then any changes made to the code are also labeled with that change number. The objects are saved in their own files in one folder for the project; I wouldn't want to separate them by functionality unless some of the code could be deployed separately. When it comes time to deploy the changes to PROD we also log the changes in an Access database with the database object name, change number, and that brief description I mentioned above. Before we deploy anything, though, we check the objects in PROD to make sure that no subsequent changes were made after we "checked out" the objects. It's not elegant but it works well enough.