On Dedicated Plans, how are you determining when it's safe to upgrade the version of Bubble on your server?

In the past, we’ve run into problems when upgrading the version of Bubble running on our Dedicated server. As such, we don’t upgrade this frequently.

Our product needs to be quite stable, so we’re trying to get smarter about how we time these updates and do our best to ensure there’s no system breaking bugs.

We do test our app for a few hours immediately after updates, but our app has, perhaps, millions of permutations for the core user experience so we only test the core flows.

How do you time these updates? What best practices on you using? Anything we should consider? Thanks!

3 Likes

I’m wondering this myself. I’ve been a dedicated user for 4 years now. Copying to the main cluster doesn’t copy data so I can’t test anything useful.

I wish I had a better answer to this, but our answer is “we don’t” :grimacing:

We’ll add new features from the box in the top right of the editor, but we haven’t upgraded our Bubble engine in years due to worries of breaking changes in a complex app.

It would definitely be great if we could test the upgrade extensively on a “QA instance” before committing to the upgrade. Especially since it seems that you only have a set amount of time to revert the upgrade if something breaks.

2 Likes

I just recently began using Bubble and am almost ready to upgrade accounts. So, I’m not sure if this would even be useful or at least provide a workaround. Does the “Dedicated” environment look or behave similar to the Bubble hosted apps?

Something I did to “protect” me from myself during a major change I was doing was to clone the project. Would something like that work where you clone your current app - essentially create a QA_[AppName] then upgrade the Bubble version and run your Test Sequences on it?

Not even sure if that is possible in your environment but thought I’d at least suggest an idea.