Comment on page
Bubble.io Version Control best practices
Recommendations for its best use when developing or maintaining an application
Version control is a complex feature that requires a good understanding of how it works in order to use it as safely as possible.
Before discussing the recommendations, you should read and assimilate the information provided by Bubble about version control. Please read it now in their manual before continuing with this article.
This is a brief overview of Bubble Note on databases of development versions manual section. Please visit the manual for more detailed information.
All development versions share a common "test" database, although data associated with custom types you've created remain associated with specific development versions. This means that although records of "userA-type' will exist in the same database referenced by userB, they will not show up in userB's version until userB syncs.
Here is what happens with any thing (whether it be an element, an action, a property…) when you add changes from one version (Version 1) to another (Version 2):
This thing in Version 1 | This thing in Version 2 | This thing in synchronized Version 2 |
|---|---|---|
Not changed (or never existed) | Updated (or added/deleted) | No change |
Updated (or added/deleted) | Not changed (or never existed) | Changed to match the updates from Version 1 |
Updated (or added/deleted) | Updated (or added/deleted) | Conflict |
When comparing the two versions to see what has been updated, Bubble do not simply consider all the differences between the two versions. Instead, they actually use a snapshot of what the version that you are adding changes from was the last time these two versions were synced.
The time when these two versions were last synced gets updated each time you add changes from one version into another.
Bubble has issued several recommendations for the correct use of version control. We want to emphasize the importance of contemplating them to avoid problems during the merge process.
The flow advised by Bubble is as follows:
- 1.Keep Development as the main version.
- 2.Create a new branch version from Development every time a hot fix or new feature needs to be deployed.
- 3.Once the new feature is developed or the bug is fixed, add the changes from that version to Development.
- 4.Check in Development that your changes were successfully added and that everything works as expected
- 1.Please visit all of the pages that could have changed after the sync in your editor to make sure the updates have been made (some elements or issues might take a little bit of time to appear for large apps).
- 2.If you notice that anything was not added then please reach out to Bubble so they can investigate this situation.
- 5.Deploy Development to live.
- 6.Delete the branch and create a new one when you want to add another new feature or need to fix a bug and repeat the flow.
(2) Create branch
(3) Add changes from the new branch to Development
(5) Deploy to live
(6) Delete branch
You should also take into account:
- That the lifetime of versions (other than Development and Live) be kept as short as possible.
- That if you are working on a fix or feature in one version, that you do not edit the relevant items (elements, workflows, page…) in another version.
This will help to limit the number of conflicts that are raised when syncing the two versions.
- You can find the complete forum thread with Bubble recommendations and explanations on how they compare the changes between the two versions to merge here.
Last modified 1yr ago