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
In the November 2018 Development Update we announced that v15.0 had been released on October 9th with the deadline to upgrade by April 9, 2019. In that same update we mentioned that we were working on Tessitura Version 15.1, an optional release due out at the end of the first quarter of 2019. We are still working on v15.1 and will begin the Beta process in the next month. The exact date of the v15.1 release has not been announced at this time, but it will be after the 15.0 deadline. v15.1 is an optional release, that will require v15.0 to be installed prior to applying v15.1. As the JCA announcement mentioned, the current RMA will continue to work on Tessitura versions 12.5 to 15.0. The new RMA will require that v15.1 is installed. For those of you who have upgraded to the 15.0.3 Service Pack, that's exactly what you want to do. Stay up to date with the service packs so that you can have the latest fixes and the most up to date software.
Regarding Service Packs. What is the current thinking around, how much testing we should be done before implementing a Service Pack in Live?
I'm interested in this from the Tessitura Network's point of view?
Also interested in this from the communities point of view. Has anyone gone from 15.0.2 to 15.0.3? What sort of testing did you do? What sort of problems or fixes did you see?
We can report that we went from 15.0.0 put in our dev environment back in late October of last year, this January we upgraded in our test environments to 15.0.2. in our Test environments. We did minimal additional testing focused on 15.0.2 and have seen no adverse impact...
I agree that I can not afford to do a full Test for every SP. I'll either need to not do SPs. Or trust that these are exceptionally well tested.
How do we know when the SPs are made available? Because we have been on Tessitura V12.5.1 for a long while now, I've not had to keep up on this. How are the announcements of SP posted? On RAMP what requests do I need to make in order to get this work done?
cc: Anna Wessely (Past Staff Member) Tanya Hoffmann
I just check the service pack page periodically unless we're watching for a specific one. It was great when I used to get RSS notifications on the page but they don't work anymore. SP's are generally released early to mid month (or they were for 14.1). www.tessituranetwork.com/.../Service-Packs
We are on 14.1.5. Our current approach is to stick with the service pack level we are on unless we discover some major issue (and it has to be something really big) that compels us to upgrade to a later service pack. If we do upgrade to a later service pack, we would still go through most of our regular upgrade testing. There are so many different ways to use Tessitura and customize that even if Tessitura's testing process is solid, that's still not an adequate indicator as to how a certain release will function in specific environments.
I'm also not certain if the list of changes on the service pack page is 100% complete. Is there a chance of some other changes sneaking into a service pack that aren't well-documented? (Hopefully not.)
Anyway, once we have more experience with the service pack approach we might be able to go with more lightweight testing. But at the moment, we are taking a more conservative approach.
We've taken a more aggressive approach to installing Service Packs, at least while we were on v14.0.x -- our hand was forced earlier on because we had some payment issues/bugs that were resolved in later Service Packs. Service Packs, in our experience, have consistently led to greater stability, so we've become more comfortable with installing them regularly with little testing outside of installing the SP on TEST and making sure the system is able to process sales. Our auditors were a little miffed by that, in all honesty, but we're working through that.
Since moving to v15.0.x, we've been limited in our ability to schedule updates due to heavy sales and major shows -- the risk is just a bit too high. With that said, our confidence in Service Packs remains high -- especially since we, as an organization, are eager to move to new versions when the functionality makes it a compelling move. In the case of v15.0.x, we chose to move quickly as we've just gone on sale with HAMILTON subscriptions and are gearing up for HAMILTON Single Ticket sales, and improvements in v15.0.x, especially with the Pricing Rules engine, was compelling enough.
I think the problem is that the RSS feeds "work" (in that they exist and have posts on them), but the Network hasn't quite figured out how to properly utilize their web platform so that the feeds actually reliably contain the updates that they should. There was an article in the feed on 1/16 about V15 SP3 and V14.1 SP11, but the previous article in the feed was on 11/9/18 about 15SP1 and 14.1SP8. (So where was 15SP2 and 14.1 SP 9-10?) But in any case, the idea is that service packs are released on a monthly basis, so that is becoming a bit more predictable at least.
I deleted my feed and tried to get it back and now just get a page of code that begins with: the XML file does not appear to have any style information associated with it. The document tree is shown below. .
That's the actual feed itself -- if you take the URL of that page and put it into your RSS reader, it'll work just fine.
I'm going to set up an automatic email using the free version of Zapier. This will read the RSS Feed and send me an email through my Gmail account.
P.S. I'm using the same approach to be notified about the Service Outages over on RAMP. This is not too bad. $0.00.
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?
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.