It would be really nice, and I’d say potentially necessary, that account owners be given explicit control over when to upgrade their specific Tulip instance. I think something like “Update available, update now?”. Yesterday, and multiple times before, I’ve had a Tulip update break something that prevents us from using the apps and systems I’ve built in Tulip. As we get more and more invested in Tulip and have more users on board, this is becoming a bigger problem. I certainly believe that the QA and testing process will get more thorough with time, but for now I really don’t like taking a chance that production is going to be taken down every three weeks for some number of minutes or hours until I can get support to roll back my version. It’s even worse if the update hits us while I’m asleep and our facilities overseas can’t operate until I’m awake and check my email.
Hi Ethan,
My company is on a Tulip “enterprise” account with LTS.
The problem you are facing is non-existent for us (from my 6 month experience with Tulip - still in devel not in production)
LTS releases are less frequent, maybe once a quarter. And when there is an upgrade Tulip requires our explicit authorization before they go ahead. And we get to tell them when to do it. Tulip also has a feature called “workspaces” to manage multiple sites. I have not used it, but i think you should look into it.
The downside is, it probably costs more and you have to wait longer for new features to hit the LTS release.
Hi Rakitha, yes unfortunately we do not have a the budget to move up to an enterprise account. I’m also aware of workspaces, but I don’t think those have an affect on updates?
Actually your original request makes sense. The customer should have the final say on when to deploy updates regardless of account status. Thus you have my vote.
This is a great idea and something we have talked about internally for the last year. There are some technical hurdles to enable this sort of flexibility (updates become a pull-based system, not a pushed-based one), but it is something we are giving serious consideration to right now.
One thing that drove this original architecture initially was the desire to insure customers were on/near the latest and greatest Tulip, and a manual update button means many users won’t ever update their Tulip instance to the newest version. We went down this road with the operating system on our edge devices (as a test of the theory) and found that something like 80% of devices never got updated if it was a manual process. This learning is forcing us to consider a hybrid system where updates can be scheduled during a specific window, but updates can’t be skipped indefinitely.
Hi Pete, I completely understand wanting to push the updates out to the users, and I think ultimately is a good idea. I think a hybrid approach would be perfect, then it just matches how many other IT operations work these days. Security updates are mandatory, but you can install them at night when you’re ready. And if you wait too long your computer will restart during a meeting
