Deploy changes to live: Quick fix vs Big Features

Hey guys,

Does anyone have a video tutorial or manual on best practices for making changes to live apps? I’m looking for better understanding of the following…

  1. If I’m doing ongoing dev work on a major feature… how can I deploy a quick bug fix without pushing my “half-finished” feature to live?
  2. If I want to add a new field to the DB… should I do it directly in live version? Or add it in Dev and push data structure to Live?
  3. How does the “Multiple Dev” versions work? (I can do project A in Dev version #1, and project B in Dev version #2…. But if I push one to live… do I have to sync live into the other?)

My co-founder and I are about to launch our app to live and want to make sure we understand how to push changes… especially if we are working on separate parts of the app.

If anyone has resources or tips, that would be awesome. Also willing to pay for someone’s time to discuss in more detail.

  1. If I’m doing ongoing dev work on a major feature… how can I deploy a quick bug fix without pushing my “half-finished” feature to live?

The only way as far as I know is to have 2 Dev versions of your app. 1 you can use for making major changes, whilst the other one can be kept in sync with your live app and used for minor fixes etc.

  1. If I want to add a new field to the DB… should I do it directly in live version? Or add it in Dev and push data structure to Live?

You can’t change the database structure of the live version of your app directly - so your second suggestion is the only way to do it.

  1. How does the “Multiple Dev” versions work? (I can do project A in Dev version #1, and project B in Dev version #2…. But if I push one to live… do I have to sync live into the other?)

Yep you’ll need to sync the other dev version with the live version before you can deploy it. The best place for full information is the Bubble manual: Version Control - Bubble Docs

3 Likes

Hi there, @NoCodeNinja… I have a different take on #1, so I will throw it out there as food for thought. There is nothing wrong with deploying a half-finished feature to live as long as 1) it doesn’t break existing functionality, and 2) you don’t expose it to users in its half-finished form.

With regard to #1, I’m sure you will have a solid regression testing process in place, and you can take advantage of that process here. About #2, it can be as simple as making sure pages/elements aren’t visible until the feature is complete. Personally, I like more control over the rollout of a new feature, though, so I prefer to use feature flags.

One of the main benefits of hiding a new feature behind a flag is the ability to easily expose the feature by turning the flag on. This approach is great for beta testing a new feature by flipping the flag for a subset of users so you can get feedback from those users and, more importantly, see how the feature performs under the load of your live environment.

Anyway, I could go on for quite a while here, but to circle back to the main point, I don’t think there is anything wrong with deploying half-finished features to live as long as you are smart about how you do it.

Best…
Mike

3 Likes