Développement basé sur le tronc vs Git Flow

Afin de développer des logiciels de qualité, nous devons être en mesure de suivre tous les changements et de les annuler si nécessaire. Les systèmes de contrôle de version remplissent ce rôle en suivant l'historique du projet et en aidant à fusionner les modifications apportées par plusieurs personnes. Ils accélèrent considérablement le travail et nous permettent de trouver plus facilement les bogues.

De plus, le travail en équipes distribuées est possible principalement grâce à ces outils. Ils permettent à plusieurs personnes de travailler sur différentes parties d'un projet en même temps et de regrouper ensuite leurs résultats en un seul produit. Examinons de plus près les systèmes de contrôle de version et expliquons comment le développement basé sur le tronc et le flux Git ont vu le jour.

Comment les systèmes de contrôle de version ont changé le monde

Avant la création des systèmes de contrôle de version, les gens comptaient sur la sauvegarde manuelle des versions précédentes des projets. Ils copiaient manuellement les fichiers modifiés afin d'intégrer le travail de plusieurs développeurs sur le même projet.

Cela a coûté beaucoup de temps, d'espace sur le disque dur et d'argent.

Quand on regarde l'historique, on peut globalement distinguer trois générations de logiciels de contrôle de version.

Jetons un coup d'œil à eux :

Nous remarquons qu'à mesure que les systèmes de contrôle de version mûrissent, il y a une tendance à augmenter la capacité de travailler sur des projets en parallèle.

L'un des changements les plus révolutionnaires a été le passage du verrouillage des fichiers à la fusion des modifications. Cela a permis aux programmeurs de travailler plus efficacement.

Une autre amélioration considérable a été l'introduction de systèmes distribués. Git a été l'un des premiers outils à intégrer cette philosophie. Il a littéralement permis au monde open-source de prospérer. Git permet aux développeurs de copier l'intégralité du référentiel, dans une opération appelée fork, et d'introduire les modifications souhaitées sans avoir à se soucier des conflits de fusion.

Plus tard, ils peuvent lancer une demande d'extraction afin de fusionner leurs modifications dans le projet d'origine. Si le développeur initial n'est pas intéressé par l'intégration de ces modifications à partir d'autres référentiels, il peut les transformer lui-même en projets distincts. Tout est possible grâce au fait qu'il n'y a pas de concept de stockage central.

Styles de développement

De nos jours, le système de contrôle de version le plus populaire est sans aucun doute Git, avec une part de marché d'environ 70 % en 2016.

Git a été popularisé avec l'essor de Linux et de la scène open source en général. GitHub, actuellement le stockage en ligne le plus populaire pour les projets publics, a également contribué de manière considérable à sa prévalence. Nous devons l'introduction de pull requests faciles à gérer à Git.

En termes simples, les demandes d'extraction sont des demandes créées par un développeur de logiciels pour combiner les modifications qu'il a créées avec le projet principal. Il comprend un processus d'examen de ces changements. Les réviseurs peuvent insérer des commentaires sur chaque élément qu'ils pensent pouvoir être amélioré ou considérer comme inutile.

Après avoir reçu des commentaires, le créateur peut y répondre, créer une discussion, ou simplement la suivre et modifier son code en conséquence.

Git n'est qu'un outil. Vous pouvez l'utiliser de différentes manières. Actuellement, les deux styles de développement les plus populaires que vous pouvez rencontrer sont le flux Git et le développement basé sur le tronc. Très souvent, les gens connaissent l'un de ces styles et peuvent négliger l'autre.

Examinons les deux de plus près et apprenons comment et quand nous devons les utiliser.

Flux Git

Dans le modèle de développement de flux Git, vous disposez d'une branche de développement principale avec un accès strict à celle-ci. On l'appelle souvent la branche develop .

Les développeurs créent des branches de fonctionnalités à partir de cette branche principale et travaillent dessus. Une fois qu'ils ont terminé, ils créent des pull requests. Dans les demandes d'extraction, d'autres développeurs commentent les modifications et peuvent avoir des discussions, souvent assez longues.

Il faut un certain temps pour se mettre d'accord sur une version finale des changements. Une fois convenue, la pull request est acceptée et fusionnée avec la branche principale. Une fois qu'il est décidé que la branche principale a atteint une maturité suffisante pour être publiée, une branche distincte est créée pour préparer la version finale. L'application de cette branche est testée et les corrections de bogues sont appliquées jusqu'au moment où elle est prête à être publiée pour les utilisateurs finaux. Une fois cela fait, nous fusionnons le produit final avec la branche master et le marquons avec la version finale. En attendant, de nouvelles fonctionnalités peuvent être développées sur la branche develop .

Ci-dessous, vous pouvez voir le diagramme de flux Git, illustrant un flux de travail général :

L'un des avantages du flux Git est un contrôle strict. Seuls les développeurs autorisés peuvent approuver les modifications après les avoir examinées attentivement. Il garantit la qualité du code et aide à éliminer les bogues plus tôt.

Cependant, vous devez vous rappeler que cela peut aussi être un énorme inconvénient. Cela crée un entonnoir qui ralentit le développement de logiciels. Si la vitesse est votre principale préoccupation, cela pourrait être un problème sérieux. Les fonctionnalités développées séparément peuvent créer des branches durables qui pourraient être difficiles à combiner avec le projet principal.

De plus, les demandes d'extraction se concentrent sur la révision du code uniquement sur le nouveau code. Au lieu de regarder le code dans son ensemble et de travailler à l'améliorer en tant que tel, ils ne vérifient que les modifications nouvellement introduites. Dans certains cas, ils peuvent conduire à une optimisation prématurée car il est toujours possible d'implémenter quelque chose pour fonctionner plus rapidement.

De plus, les demandes d'extraction peuvent conduire à une microgestion étendue, où le développeur principal gère littéralement chaque ligne de code. Si vous avez des développeurs expérimentés en qui vous pouvez avoir confiance, ils peuvent le gérer, mais vous risquez de perdre leur temps et leurs compétences. Cela peut également fortement démotiver les développeurs.

Dans les grandes organisations, la politique de bureau lors des demandes d'extraction est une autre préoccupation. Il est concevable que les personnes qui approuvent les demandes d'extraction puissent utiliser leur position pour empêcher délibérément certains développeurs d'apporter des modifications à la base de code. Ils pourraient le faire par manque de confiance, tandis que certains pourraient abuser de leur position pour régler des comptes personnels.

Avantages et inconvénients du flux Git

Comme vous pouvez le voir, faire des pull requests n'est pas toujours le meilleur choix. Ils ne doivent être utilisés qu'en cas de besoin.

Quand Git Flow fonctionne-t-il le mieux ?

• Lorsque vous exécutez un projet open source.
  Ce style vient du monde open source et c'est là qu'il fonctionne le mieux. Puisque tout le monde peut contribuer, vous voulez avoir un accès très strict à tous les changements. Vous voulez pouvoir vérifier chaque ligne de code, car franchement, vous ne pouvez pas faire confiance aux personnes qui contribuent. Habituellement, ce ne sont pas des projets commerciaux, donc la vitesse de développement n'est pas un problème.

• Quand vous avez beaucoup de développeurs juniors.
  Si vous travaillez principalement avec des développeurs juniors, vous souhaitez avoir un moyen de vérifier leur travail de près. Vous pouvez leur donner plusieurs conseils sur la façon de faire les choses plus efficacement et les aider à améliorer leurs compétences plus rapidement. Les personnes qui acceptent les demandes d'extraction ont un contrôle strict sur les modifications récurrentes afin d'éviter la détérioration de la qualité du code.

  

• Lorsque vous avez un produit établi.
  Ce style semble également bien jouer lorsque vous avez déjà un produit à succès. Dans de tels cas, l'accent est généralement mis sur les performances des applications et les capacités de charge. Ce type d'optimisation nécessite des changements très précis. Habituellement, le temps n'est pas une contrainte, donc ce style fonctionne bien ici. De plus, les grandes entreprises conviennent parfaitement à ce style. Ils doivent contrôler chaque changement de près, car ils ne veulent pas casser leur investissement de plusieurs millions de dollars.

Quand Git Flow peut-il causer des problèmes ?

• Lorsque vous venez de démarrer.
  Si vous débutez, alors Git flow n'est pas pour vous. Il y a de fortes chances que vous souhaitiez créer rapidement un produit minimal viable. Faire des demandes d'extraction crée un énorme goulot d'étranglement qui ralentit considérablement toute l'équipe. Vous ne pouvez tout simplement pas vous le permettre. Le problème avec le flux Git est le fait que les pull requests peuvent prendre beaucoup de temps. Il n'est tout simplement pas possible d'assurer un développement rapide de cette façon.

• Lorsque vous avez besoin d'itérer rapidement.
  Une fois que vous aurez atteint la première version de votre produit, vous devrez probablement le faire pivoter plusieurs fois pour répondre aux besoins de vos clients. Encore une fois, plusieurs branches et demandes d'extraction réduisent considérablement la vitesse de développement et ne sont pas conseillées dans de tels cas.

• Lorsque vous travaillez principalement avec des développeurs seniors.
  Si votre équipe se compose principalement de développeurs expérimentés qui travaillent ensemble depuis plus longtemps, vous n'avez pas vraiment besoin de la microgestion des demandes d'extraction susmentionnée. Vous faites confiance à vos développeurs et savez qu'ils sont des professionnels. Laissez-les faire leur travail et ne les ralentissez pas avec toute la bureaucratie du flux Git.

Workflow de développement basé sur le tronc

Dans le modèle de développement basé sur le tronc, tous les développeurs travaillent sur une seule branche avec un accès ouvert à celle-ci. Il s'agit souvent simplement de la branche master . Ils y commettent du code et l'exécutent. C'est ultra simple.

Dans certains cas, ils créent des branches de fonctionnalités de courte durée. Une fois que le code de leur branche a été compilé et a réussi tous les tests, ils le fusionnent directement dans master . Cela garantit que le développement est vraiment continu et empêche les développeurs de créer des conflits de fusion difficiles à résoudre.

Jetons un coup d'œil au flux de travail de développement basé sur le tronc.

La seule façon de réviser le code dans une telle approche est de faire une révision complète du code source. Habituellement, les longues discussions sont limitées. Personne n'a un contrôle strict sur ce qui est modifié dans la base du code source, c'est pourquoi il est important d'avoir en place un style de code applicable. Les développeurs qui travaillent dans un tel style doivent être expérimentés afin que vous sachiez qu'ils ne réduiront pas la qualité du code source.

Ce style de travail peut être formidable lorsque vous travaillez avec une équipe de développeurs de logiciels chevronnés. Cela leur permet d'introduire de nouvelles améliorations rapidement et sans bureaucratie inutile. Cela leur montre également que vous leur faites confiance, car ils peuvent introduire du code directement dans la branche master . Les développeurs de ce flux de travail sont très autonomes : ils livrent directement et sont contrôlés sur les résultats finaux dans le produit de travail. Il y a certainement beaucoup moins de microgestion et de possibilité de politique de bureau dans cette méthode.

Si, d'un autre côté, vous n'avez pas d'équipe expérimentée ou si vous ne leur faites pas confiance pour une raison quelconque, vous ne devriez pas utiliser cette méthode, vous devriez plutôt choisir le flux Git. Cela vous évitera des soucis inutiles.

Avantages et inconvénients du développement basé sur le tronc

Examinons de plus près les deux côtés du coût, les meilleurs et les pires scénarios.

Quand le développement basé sur le tronc fonctionne-t-il le mieux ?

• Lorsque vous venez de démarrer.
  Si vous travaillez sur votre produit minimum viable, ce style est parfait pour vous. Il offre une vitesse de développement maximale avec un minimum de formalités. Puisqu'il n'y a pas de demandes d'extraction, les développeurs peuvent fournir de nouvelles fonctionnalités à la vitesse de la lumière. Assurez-vous simplement d'embaucher des programmeurs expérimentés.

• Lorsque vous avez besoin d'itérer rapidement.
  Une fois que vous avez atteint la première version de votre produit et que vous avez remarqué que vos clients veulent quelque chose de différent, alors n'hésitez pas et utilisez ce style pour pivoter dans une nouvelle direction. Vous êtes encore en phase d'exploration et vous devez pouvoir changer de produit au plus vite.

• Lorsque vous travaillez principalement avec des développeurs seniors.
  Si votre équipe se compose principalement de développeurs seniors, vous devez leur faire confiance et les laisser faire leur travail. Ce workflow leur donne l'autonomie dont ils ont besoin et leur permet d'exercer leur maîtrise de leur métier. Donnez-leur simplement un but (tâches à accomplir) et observez comment votre produit se développe.

Quand le développement basé sur le tronc peut-il causer des problèmes ?

• Lorsque vous exécutez un projet open source.
  Si vous exécutez un projet open source, le flux Git est la meilleure option. Vous avez besoin d'un contrôle très strict sur les changements et vous ne pouvez pas faire confiance aux contributeurs. Après tout, tout le monde peut contribuer. Y compris les trolls en ligne.

• Quand vous avez beaucoup de développeurs juniors.
  Si vous embauchez principalement des développeurs juniors, il est préférable de contrôler étroitement ce qu'ils font. Des demandes d'extraction strictes les aideront à améliorer leurs compétences et trouveront plus rapidement les bugs potentiels.

• Lorsque vous avez établi un produit ou gérez de grandes équipes.
  Si vous avez déjà un produit prospère ou si vous gérez de grandes équipes dans une grande entreprise, alors le flux Git pourrait être une meilleure idée. Vous voulez avoir un contrôle strict sur ce qui se passe avec un produit bien établi qui vaut des millions de dollars. Les performances des applications et les capacités de chargement sont probablement les choses les plus importantes. Ce type d'optimisation nécessite des changements très précis.

Utilisez le bon outil pour le bon travail

Comme je l'ai déjà dit, Git n'est qu'un outil. Comme tout autre outil, il doit être utilisé de manière appropriée.

Le flux Git gère toutes les modifications via des demandes d'extraction. Il fournit un contrôle d'accès strict à toutes les modifications. C'est idéal pour les projets open source, les grandes entreprises, les entreprises avec des produits établis ou une équipe de développeurs juniors inexpérimentés. Vous pouvez vérifier en toute sécurité ce qui est introduit dans le code source. D'un autre côté, cela pourrait conduire à une microgestion extensive, à des conflits liés à la politique de bureau et à un développement considérablement plus lent.

Le développement basé sur le tronc donne aux programmeurs une autonomie totale et exprime plus de confiance en eux et en leur jugement. L'accès au code source est gratuit, vous devez donc vraiment pouvoir faire confiance à votre équipe. Il offre une excellente vitesse de développement logiciel et réduit les processus. Ces facteurs le rendent parfait lors de la création de nouveaux produits ou du pivotement d'une application existante dans une toute nouvelle direction. Cela fonctionne à merveille si vous travaillez principalement avec des développeurs expérimentés.

Néanmoins, si vous travaillez avec des programmeurs juniors ou des personnes en qui vous n'avez pas entièrement confiance, Git flow est une bien meilleure alternative.

Fort de ces connaissances, j'espère que vous serez en mesure de choisir le flux de travail qui correspond parfaitement à votre projet.