Versioning Bubble.io

If you’ve ever done code, you’ll agree with me that the version control system during development done with Git is a revolution. With Bubble, we have something similar that allows us to work together on the same project. Because you have to be able to work separately and pool your work at the end of the development of the feature.
But let’s go back to the basics.

Some Notions

To begin with, we need to understand some of the concepts used in the versioning system:

A branch represents an independent line of development, it is a copy of the independent application on which you make changes. You can create as many as you want in theory, but with Bubble, there is a limit depending on the chosen plan.

Commits are considered snapshots or milestones in the timeline of a Git project. But we have no alternative with Bubbe. Knowing that commits are done before deploying the project on the repository, is understandable because the repository and the versioning system are confused.

git push is the most commonly used command to publish local changes and upload them to a centralized repository. After a local repository has been modified, a push is executed to share the changes with remote team members. This is the universal code but, with Bubble, you click deploy and the job is done.

Merger consists of adding the modifications made separately on the main project. But this step can generate conflicts when the same element has undergone several modifications on different versions. This is the most complicated thing in versioning, even with Bubble. You have to choose which version to keep.

Bubble Versioning System

With Bubble, every application has at least two versions, the live version (the publicly exposed version) and at least one development version, on which you make changes, accessible by authorization. By default, all applications come with a single development version, called “test”, but if you have a professional, production or dedicated plan, you can create multiple versions (multiple branches). On these plans, if you delete a development version, it will not affect the online application in any way, but with a lower plan, it is not possible to delete the development version. This would be a nightmare.
With Bubble’s versioning system, it’s possible to revert changes to your application in case something goes wrong, which often happens when working in a team. Save points make it easy to revert to a particular point, but since the changes are stored permanently, you can revert to any specific point in time. The date you can revert is determined by your plan. This increases security in the life and maintenance of the product.

Things to keep in mind

A few things to remember in order to take advantage of the versioning power of Bubble:

When you merge two versions, especially with large applications and significant differences between the two versions, the editor will be noticeably slower for a while after the merge, because Bubble does a lot of calculations in the backend. This problem should resolve itself after a while, depending on the complexity of the added features.

After merging two development versions, the issue checker for the new combined version may not update immediately. In this case, if you want to be sure that all issues are taken into account in the merged version, we suggest that you visit each page of the editor knowing that visiting a page should cause the issue checker for that page to run. Sure it’s weird but you have to do it to be sure and I think Bubble to fix these problems over time.

With Bubble, a conflict occurs when the same item or workflow has been modified in a different way in the two branches involved in a merge. For example, let’s say I have a blue login button in version X and I create version Y from version X. I then change the color of that login button to red in version X and green in version Y. If I try to merge version X with version Y, Bubble doesn’t know what color the button should be and therefore raises a conflict. To solve the conflict, you have to choose between the red color in version X and the green color in version Y.

In my experience, it’s better if no one makes changes when you merge versions in order to limit stupid conflicts.

Find here other techniques and tips to better understand the Bubble versioning system

Bubble’s versioning system is a great help when developing in groups on the same project. It is very useful when working in a development agency. If you are two or single, don’t create versions unnecessarily, because you can always work on the same project in several when the changes are not made on the same page or the same elements. In order to limit the conflict and complexity of versioning. If you have any questions let’s discuss them or leave a comment.