Qu'est ce que le versioning et comment l'utiliser sur Bubble ?

Qu’est-ce que le versioning ?

Lorsqu’on parle de versioning, on pourrait penser aux différentes versions de notre application (V1.1, V1.2, V2.1, etc). Mais ce n’est pas le sujet ici, même si tout ceci est lié. Dans cette partie, on va surtout s’intéresser aux différentes branches de développement dans Bubble, qui permettent aux développeurs de construire plusieurs fonctionnalités en parallèle sans se déranger dans les phases de tests et qui permettent de bien segmenter les développements, comme le propose Guithub pour les devs code.

À savoir, les branches de développement ne sont accessible qu’à partir d’un plan professionnel ou pour les plans agency (CF pricing Bubble : https://bubble.io/pricing/compare)

Le principe du versioning sur Bubble

Bubble propose 2 branches principales :

• la branche Live (ce qui est en ligne pour nos utilisateur)

• la branche de développement (qu’on utilise tous pour développer avant de le mettre en ligne).

Chacune de ces 2 branches possède sa propre base de données afin de bien segmenter ce qui est en ligne de ce qui est en développement.

Ce qui est intéressant ici, c’est de pouvoir diviser la version de développement en plusieurs sous-branches pour que chaque développement de fonctionnalité soit bien segmenté et que chaque développeur puisse tester sa fonctionnalité sans déranger les autres dû aux rafraichissement de page. Chaque sous-branche de développement partage la même base de donnée que la branche de développement principale. L’objectif final est de merger la branche qui possède la nouvelle fonctionnalité avec la branche principale de développement avant de merge avec la branche live.

2 manières d'utiliser le versioning sur Bubble :

1. Utiliser une version pour une fonctionnalité à développer et la merger avec la branche principale lorsque la fonctionnalité est terminé.
   Avantage : La nouvelle fonctionnalité à développer est bien segmenter par rapport à ce qui est déjà développé.
   Inconvénients : Si deux développeurs font des modifications sur un même élément ou dans la structure de donnée mais dans des branches différents, cela peut engendrer des conflits compliqué à résoudre.

2. Tout développer dans la version principale de développement, et utiliser une deuxième version seulement pour la phase de test
   Avantage : tout le développement se fait sur la version principale, donc les conflits seront très rare et faciles à résoudre.
   Inconvénients : Il est nécessaire de merge à chaque petite modification pour que le teste puisse être fait avec les modification

Dans tous les cas, utiliser plusieurs version (branche) de développement demande une rigueur lors du développement et une bonne communication entre les développeurs

‍