So I just received an email (from JCA Arts Marketing mind you, not Tessitura) that there is going to be a 15.1 release of Tessitura? Do we know when this is going to be released? I'm frustrated by the lack of communication as we just yesterday set our upgrade plan in action and now that all has to change due to changes for RMA.
Michele
Thanks for asking this question Tom. I'll see if I can help provide some information from Tessitura Network's viewpoint.
The Service Pack model to deliver high priority fixes to the software was started with v14.0. We did this to provide a more industry-standard process and hoped to provide a more consistent method for everyone to keep up to date with fixes. The previous model of stand-alone hotfixes were difficult to support and maintain. Our goal is to provide any fixes that are supplied on a monthly basis for 2 versions at a time. Currently, we are providing service packs for 14.1 and 15.0. We try to release both services pack at the same time and they are usually within the first half of the month. Our process is to determine high priority fixes and if there are any other items that may be low risk yet beneficial to our licensees to include in the service pack. We publish the release notes for each fix that is part of the service pack on the corresponding Service Pack page which can be subscribed in a RSS feed, along with updating the full release notes on the documentation page (here's a link to the v15.0 release notes). The date the service pack is released is noted and all previous service pack included items are available to view on the service pack page. Each service pack that is released is a cumulative, full build of the software so that it contains all previous service pack fixes. Our QA team tests each of the items and we have an internal releases team that installs the service packs and run tests prior to the public release. Our hope and goal is that minimal testing by organizations are needed, yet you should always review what is included to make sure that any possible customizations you have in place will continue to work as expected. As with any update we would expect the service pack to be installed in a testing environment prior to implementing in Production.
As for the RSS feed issue, it was discovered a few months ago that the feeds were not always working for everyone. A fix has been found and ffeds should be updated moving forward.
Karen Sterkowicz can you speak to the process that RAMP users should use for this process?
Do we for example put in a TASK ticket when we have done an initial review of the release notes? For our TEST and DEV environments. Then do our due diligence in those environments? Then put in a separate request for Deployment to Live? As these Patches are full builds? How long will this take out Sites out of action? Of course, we would want to schedule Live SP installations during Off hours.
Karen Sterkowicz, are the list of changes documented for each service pack 100% complete? Or, is there a chance of some fix or coding change to occur that is not captured in the service pack change notice? For example, Service Pack 11 (14.1.11.50966) has three changes documented on this page: https://www.tessituranetwork.com/Support/Help/Service-Packs/v14-1_SP. Are those literally the only three changes made since Service Pack 10? Thanks!
We list all of the changes that are included in the service pack on the service pack page. For v14.1.11 there were only 3 items. Our goal is to list all of the changes so that organizations know what to expect.
For RAMP you would want to open a TASK ticket when you are ready to have a service pack applied. I checked in with Hosting Services and they usually prefer one ticket for both Test and Live. It is a full build just like we supply for self-hosted organizations. It usually takes about an hour, but you would only be down for about 30 minutes. The Hosting Services team will help you through the process.
My hope is that this is more reliable going forward, but I've made it a part of my upgrade process to do an object-level diff just to see for sure what schemas and sprocs are changing. This also helps me to know which of my customizations break, if I'm keeping track of all of my dependencies on built-in objects.
Nick, How are you doing this bit of comparison magic?
Nick Reilingh, we do the same thing and I agree it is useful. But, there are an increasing number of things that won't catch as more resources are built without sprocs behind them. I'm probably going to explore how useful something like Telerik JustAssembly is in comparing Tessitura services DLLs from one version to another.
I'm basically automating the "Script to... new query window" for the entire database with some PowerShell, saving each object to a file, and then doing a diff. The gist of it is in this Bitbucket snippet: https://bitbucket.org/snippets/TN_WebShare/aBn8M/script-impresario-to-files but I think I've made minor improvements since that version, so ping me if you'd like me to post the update.
Nick Reilingh so what are the logistics around these scripts. I'm guessing Windows computer with SSMS & Power Shell. I was wondering how long this takes. How big the files are? And your approach to doing the diff. Then I realized that I'm currently on RAMP. I'm not clear that an approach like this will work for me. Thoughts?
Karen Sterkowicz A thought just occurred to me. I note that there is a new 'Calendar' located at the top of the network website now. A quick glance through this calendar indicates that it is really only being used to indicate TCPD sessions and TUG meetings. Would it be possible to have all network 'events' including webinars, anticipated release dates etc. listed on this calendar so that we have a central place to go to find this information? For me, the November Update was sent when I was fully immersed in our season build and member on sale. It would have been given, at best, a cursory glance as I just don't have the time then to read it. If it were in the calendar, I could easily have found the note that April means 15.1 release with a link to Chuck's dev update.
Hello all! I'm late to the party on this one, but it has been my experience that as detailed as the release notes for each version and service pack are, they aren't entirely complete. They might list the larger issue that was fixed, but the nuances behind that are not laid out, like new triggers that are now firing, foreign keys, etc.. I don't know if we should expect more detailed notes, since that could seriously bog down the documentation and take up more of TN's staff than is reasonable, but it would be helpful to see which db objects have been affected by each of the changes listed.
Our consortium's approach (I'm not with Stratford Festival, so I'm not sure why that is showing up next to my name, but anyways!) is also to wait to only apply service packs when the fixes they're offering affect the functionality we use, however this approach caught us off guard two weeks ago when a TNEW implementer told us we had to apply a patch later than 14.1.7 (our current version) because it was required for TNEW v7 guest checkout. The service pack's release notes mentions guest checkout, but doesn't stipulate that it's a requirement, so I think the messaging surrounding service packs could be made more clear.
In terms of comparing versions and changes to database objects, now that we're on RAMP I have a very simple approach. I basically save the structure into local tables for all database objects prior to the upgrade in our dev or test system, say, and then after the upgrade has been applied I compare the current structure to the old structure. This tells me quickly which table fields changed and how, parameters/stored procedures/functions/triggers/etc. that have been added or removed, etc. I'm happy to share the script with anyone, just DM me.
Happy upgrading and service patching!
My approach to doing the diff is to put everything into a Git repository and then git diff between different commits and branches. File size is small; it's just the text of the SQL DDL and procs, so a repo I have that contains nearly everything from 11.0.3 to 14.1.11 is only 20MB. To run the scripts, you just need the SMO objects (that come installed with SQL Server OR SSMS) and PowerShell, with the ability to log in to the SQL database. Potentially you could do it on RAMP since functionally you're not making use of anything you don't already have access to in SSMS. But if they don't let you have access to a PowerShell prompt within the RAMP client used for SSMS access, you're kind of dead in the water.
I will pass this feedback along regarding additional uses of the calendar. For the releases I will have to think if there is a way to indicate targeted release time frame. This might be something we can put on the Roadmap section of the website since the official date is not determined until we start into our Beta process. Thanks for the idea Michele. I'll do some thinking about this.