Maybe I’m missing something here, but it seems very awkward that there is no option to make a commit (not a save) to Development to mark a point in time you could always revert back to. To me, it looks like we can only publish Development to Live if we want to create a point in time to go back to. But that means you might push out half-baked ideas just because you want to be able to revert back to them if you’re making a lot of changes.
Am I missing something here? This feels like a must-have for any genuine development effort.
Yeah, Bubble is missing a robust version control capability. This becomes ever more important as your development team gets larger too. So, I hope it’s something they tackle not too far down the road. I’m sure it’s a big project for them though, so I understand why it hasn’t been tackled yet.
Here’s some tricks that we’ve used that may mitigate the feature gap for you in the meantime:
When making radical changes to a page we often copy the original page and work on the new one until it’s done. Once it’s done and tested, then we connect the new one to navigation/link flow for the original page. We then delete the original page and rename the new one with the orginal page’s name (so it’ll be same URL for external links too). This way, we can push anytime we’re working on the new page and the work-in-progression version won’t be shown to users.
For smaller changes, we’ll often put changes in a group and set it to be hidden on the page by default. This way, any changes aren’t displayed to the end user.
We also coordinate on features and have designed our processes to finish and test Bubble projects instead of leaving them 90% complete/tested because without a more robust version control it’s helpful to have frequent points where everything is fully coded, tested, and ready to push.
Note - there’s also a somewhat new capability to push a hot fix if you ever run into that scenario. I haven’t used it, but I believe it’ll let you push the most recent changes you made (since your browser was refreshed) without pushing everything on development to production.
I’d add here that, while robust version control would be amazing (and necessary, eventually) simply being able to make a single commit to Development that stored everything and could be later restored would solve 90% of the common problems I face with this development workflow.
As is, development feels crazy risky on an active product with a bunch of active users at any given time. I’m also shocked every time I can easily delete a DB field, as if a stray click could undue tons of work.
