Comment bien cadrer votre projet avec OneFlow

0
99
bien cadrer avec oneflow
<iframe frameborder="0" id="ausha-UKdv" height="420" style="border: none; width:100%" src="https://player.ausha.co/index.html?podcastId=bY4YkhAeplDV&playlist=true&color=%2372238e&display=horizontal&v=3&playerId=ausha-UKdv"></iframe><script src="https://player.ausha.co/ausha-player.js"></script>


Nous continue notre série sur la découverte des cadres Git (git flow) pour plus de cohésion technique avec One Flow.
Vous cherchez une alternative à Git flow mais vous ne souhaitez pas passer par Github flow, ou bien Gitlab flow ? OneFlow est fait pour vous.

Prendre les principes de Git flow …

Dans OneFlow, on retrouve les mêmes principes de :

  • branche master/main
  • branche pour chaque nouvelle fonctionnalité
  • gestion des bugs avec des branches hotfix

OneFlow dédié pour certains types de projet

Vu que Oneflow git cadre des projets où les livraisons s’enchaînent les unes après les autres, tout comme Git flow, il va sans dire que cela oriente rapidement notre choix pour démarrer un projet.
Exit les projets qui ont des contraintes de type : une nouvelle release est totalement différente de la dernière (non rétro-compatible). Dans son article, Adam Ruka présente par exemple le cas de Python avec le passage de la v2 à la v3.

Un flux de développement non pensé pour un haut niveau de Déploiement continue, selon l’auteur. Attention, cela ne veut pas dire que ce n’est pas possible. Simplement, le processus est sans doute un peu trop lourd pour ça.

… Et les améliorer

Se passer de la branche developpement

De base, on peut ici se passer de la branche developement ! Première avancée positive ? (l’auteur propose quand même la même option que git flow, à savoir avoir deux branches : main/master et developement)

Possibilité d’utiliser le rebase

Pour l’auteur Adam Ruka, rebase, merge, ce n’est qu’un choix arbitraire, qui dépend de l’équipe, pas de OneFlow.

Cependant, cela fait plaisir de voir cette stratégie proposée.


Voici les commandes git pour respecter OneFlow :

git checkout feature/my-feature
$ git rebase -i master
$ git checkout master
$ git merge --ff-only feature/my-feature
$ git push origin master
$ git branch -d feature/my-feature

Nous trouvons les mêmes propositions pour le merge.

Trois différences majeures

De l’auteur, il nous précise que OneFlow diffère surtout de GitFlow, pour trois raisons :

  • Pas la même façon de finir une branche de release
  • Une façon différente de finir une branche de fonctionnalité
  • Une autre façon de finir les branches de bugs

C’est donc dans ces 3 parties que OneFlow apporte sa vraie différence.

Bien pour la cohésion technique ?

On est sur un flow qui se veut plus souple, donc, du point de vue cohésion c’est mieux, car on va pouvoir mieux s’adapter à la culture de l’équipe, de l’entreprise.

Par contre, vu que le OneFlow est limité dans les livraisons / déploiements continu-e-s, cela va amener une forte contrainte, surtout dans les environnements techniques actuels (recherchant toujours plus d’automatismes).

Votre équipe ?

Besoin de plus de cohésion !

Vos équipes peinent à se former ?

Vous souhaitez passer à l'étape supérieur pour vos projets ?

Plus de qualité, de plus de cohésion technique, d'équipe ?

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici