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?
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?
Hi Tom,
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.