Ci Cd

GitFlow et Trunk-Based Development

Comprendre et implémenter les stratégies de branches GitFlow et Trunk-Based Development

Pourquoi utiliser une stratégie de gestion de branches Git ?

Lorsque vous travaillez sur un projet, surtout en équipe, il est essentiel d'adopter une stratégie de gestion de branches Git cohérente. Ces stratégies vous aident à :

  • Organiser le développement : Structurer le travail en parallèle de plusieurs développeurs
  • Gérer les versions : Faciliter la maintenance de différentes versions du logiciel
  • Assurer la qualité : Protéger votre code de production des erreurs et régressions
  • Optimiser la collaboration : Clarifier le processus pour tous les membres de l'équipe

GitFlow

GitFlow est un modèle de workflow Git formalisé par Vincent Driessen en 2010. Il définit un ensemble structuré de branches et de règles pour la gestion du code source.

Structure des branches dans GitFlow

GitFlow utilise plusieurs types de branches, chacune avec un rôle spécifique :

  • master/main : Contient uniquement le code de production stable
  • develop : Branche principale de développement où s'intègrent les fonctionnalités
  • feature/ : Branches pour développer de nouvelles fonctionnalités
  • release/ : Branches pour la préparation des versions à livrer
  • hotfix/ : Branches pour les correctifs urgents en production
  • support/ : Branches optionnelles pour le support des versions antérieures

Exemple de flux GitFlow

Voici un exemple concret du cycle de vie d'une fonctionnalité avec GitFlow :

  1. L'équipe travaille sur la branche develop
  2. Alice crée une branche feature/authentification à partir de develop
  3. Alice termine la fonctionnalité et la fusionne dans develop
  4. L'équipe décide de préparer la version 1.0.0
  5. Bob crée une branche release/1.0.0 à partir de develop
  6. Bob corrige quelques bugs mineurs dans la branche de release
  7. La release est fusionnée dans master et develop
  8. Un tag v1.0.0 est créé sur master
  9. Un bug critique est découvert en production
  10. Charlie crée un hotfix/correction-login à partir de master
  11. Le hotfix est fusionné dans master et develop
  12. Un tag v1.0.1 est créé sur master

Trunk-Based Development

Le Trunk-Based Development est une approche minimaliste où les développeurs travaillent principalement sur une seule branche, appelée "trunk" (généralement main ou master).

Principes du Trunk-Based Development

  • Une seule branche principale (trunk) où presque tout le développement a lieu
  • Intégration continue avec commits fréquents sur le trunk
  • Branches de fonctionnalités de très courte durée (1-2 jours maximum)
  • Utilisation de feature toggles pour désactiver le code incomplet
  • Déploiement continu ou fréquent depuis le trunk

Exemple de flux Trunk-Based

Voici un exemple concret du cycle de vie d'une fonctionnalité avec Trunk-Based Development :

  1. L'équipe travaille sur la branche main
  2. Alice crée une branche feature/bouton-partage à partir de main
  3. Alice développe la fonctionnalité en 1 jour
  4. Alice pousse sa branche et crée une Pull Request
  5. Bob fait la revue de code et approuve
  6. Les tests automatisés passent avec succès
  7. Alice fusionne sa branche dans main
  8. Le code est automatiquement déployé en production
  9. Pour une fonctionnalité plus complexe, Charlie utilise un feature toggle
  10. La fonctionnalité est développée progressivement et fusionnée régulièrement dans main
  11. Une fois complète, le toggle est activé en production

Comparaison et choix

Le tableau ci-dessous présente une comparaison entre GitFlow et Trunk-Based Development pour vous aider à choisir la stratégie la plus adaptée à votre contexte :

CritèreGitFlowTrunk-Based Development
Taille d'équipeGrandes équipes avec coordination formellePetites à moyennes équipes agiles
Type d'applicationApplications avec cycles de release planifiésApplications web/SaaS avec déploiement continu
MaintenanceSupport de multiples versions en productionFocus sur la dernière version
Cadence de livraisonPlanifiée et moins fréquenteContinue et très fréquente
ComplexitéComplexe avec nombreuses branchesSimple avec peu de branches
Prérequis techniquesMoins de dépendance aux tests automatisésNécessite une bonne couverture de tests
ValidationProcessus formel et multipleValidation rapide par revue et tests
FocusStabilité et planificationRapidité et agilité
Courbe d'apprentissagePlus difficile à maîtriserPlus simple à adopter
Structure du codePeut fonctionner avec tout type de codeNécessite une architecture modulaire