Aller directement au contenu principal

Git Flow vs Trunk-Based pour CI/CD

Découvrez les différences entre Git Flow et Trunk-Based Development pour des workflows CI/CD efficaces, mettant en avant leurs forces et leurs faiblesses.

Martin Donadieu

Martin Donadieu

Responsable de la création de contenu

Git Flow vs Trunk-Based pour CI/CD

Choisir entre Git Flow et le développement basé sur le tronc (TBD) peuvent avoir un impact significatif sur votre flux de travail CI/CD. Voici un aperçu rapide :

  • Git Flow: Idéal pour les environnements structurés et contrôlés par version. Il utilise plusieurs branches comme main, develop, feature, release, et hotfix. Adapté pour les grandes équipes, les cycles de mise à jour lents et les processus de test qualité stricts.
  • Développement basé sur le tronc: Se concentre sur une seule branche principale avec des branches de fonctionnalités à vie courte. Conçu pour les équipes plus petites, les mises à jour rapides et les tests automatisés solides.

Comparaison Rapide :

Aspect Développement basé sur le tronc Complexité des Branches
Git Flow Plusieurs branches à long terme Une branche unique, des branches à court terme
Rythme de mise en production Mises en production planifiées Déploiement continu
Taille de l'équipe Équipes importantes Petites à moyennes équipes
Test Test à la fin du cycle Test automatique
Risque de déploiement Inférieur avec des mises à jour étalées Supérieur avec des mises à jour fréquentes
Annuler Plus lent Plus rapide

Point clé: Utilisez Git Flow pour des workflows structurés et plus lents, et TBD pour la vitesse et la flexibilité. Les deux nécessitent des pipelines CI/CD solides pour réussir.

29 - GitFlow vs. Développement basé sur le tronc : Gestion …

Git Flow Basics de flux de travail

Git Flow

Git Flow organise la mise au point en utilisant cinq types de branches : main, develop, feature, release, et hotfix. Cette structure aide à gérer les mises à jour et le développement parallèle de manière efficace.

Structure des Branches Git Flow

Type de branche Objectif Cible de fusion
Main Contient des code prêts à la production N/A
Développe Intègre des fonctionnalités ; sert de base pour les branches de fonctionnalités N/A
Fonctionnalité Utilisé pour la construction d'éléments individuels de fonctionnalité ; créé à partir de develop develop
Version de production Prépare à la version finale et à la mise en test ; créé à partir de develop main & develop
Correctif Résout les problèmes de production rapidement ; créé à partir de main main & develop

Avantages du flux Git

  • Permet de développer plusieurs fonctionnalités en même temps sans causer de conflits.
  • Les branches de version fournissent un espace dédié pour les tests finals et la préparation de la version, tout en gardant la develop branche ouverte pour les travaux en cours.
  • Les branches de correctif facilitent la résolution des problèmes de production rapidement sans interrompre les autres tâches de développement. Inconvénients du flux Git

Complexité de la gestion des branches

  • Complexité de la gestion des branches: Gestion de plusieurs branches actives peut rendre la fusion plus difficile.
  • Déploiement plus lent: Le processus de publication formelle peut ralentir les déploiements par rapport à des workflows plus simples.
  • Entretien accru: Chaque branche nécessite sa propre configuration de pipeline, ce qui ajoute au fardeau de l'entretien.

Ce flux de travail convient mieux aux projets qui nécessitent un contrôle de version strict, plusieurs pistes de publication ou une conformité aux réglementations. Nous allons ensuite explorer comment cela se compare à l'approche simplifiée du développement basé sur le tronc.

Développement Basé sur le Tronc

Le développement basé sur le tronc (TBD) tourne autour d'une seule branche principale, souvent appelée tronc ou main. Cette approche se rapproche étroitement des pratiques DevOps et de l'intégration continue.

Structure de Branches du Développement Basé sur le Tronc

Dans un flux de travail typique de TBD, vous rencontrerez ces types de branches :

Type de Branch But Durée de vie
Brancher principal/Tronc Brancher central avec code prêt pour la production Permanent
Branches de fonctionnalités Branches temporaires pour des modifications individuelles Court terme
Branches de version Utilisé pour les dernières retouches avant une version Temporaire

Les développeurs intègrent régulièrement de petites modifications incrémentales dans la brancher principale - souvent plusieurs fois par jour. Cela encourage des tests continus et aide à résoudre les conflits rapidement.

Avantages de la gestion de tronc

L'approche TBD offre plusieurs avantages aux équipes travaillant avec CI/CD et DevOps :

  • Moins de conflits de fusion : Les merges réguliers gardent les conflits gérables.
  • Un feedback plus rapide : Les builds automatisés s'exécutent avec chaque merge, détectant les bogues tôt.
  • Des pipelines plus simples : Une seule branche réduit la complexité des configurations CI/CD.
  • Une meilleure collaboration d'équipe : Un tronc partagé garantit que tout le monde reste aligné.

Cette structure crée un flux de travail éclairé, préparant la scène pour une comparaison avec Git Flow dans la prochaine section.

Limites de l'approche TBD

Bien que TBD ait ses forces, elle présente également des défis que les équipes doivent relever :

Challenge Impact Comment s'attaquer à
Code Stabilité Le risque de modifications de rupture affectant la branche principale Utiliser des tests automatisés solides
Coordination de l'équipe Le travail en chevauchement peut provoquer des perturbations Se fier aux drapeaux de fonctionnalité et aux commits fréquents et petits
Courbe d'apprentissage Passer d'une branche à long terme à une autre Proposer une formation et introduire progressivement
Problèmes d'échelle Les mises à jour fréquentes peuvent submerger les grandes équipes Imposer des examens approfondis code

Le succès de TBD nécessite des tests automatisés solides et une communication ouverte au sein de l'équipe.

Git Flow vs. Développement Basé sur le Tronc : Comparaison Directe

Voici comment Git Flow et le Développement Basé sur le Tronc se valent en termes clés :

Tableau de Comparaison des Caractéristiques

Aspect Git Flow Développement Basé sur le Tronc
Complexité des Branches Plusieurs branches longues Branch principale unique avec des branches à durée de vie courte
Fréquence de mise en production Lancements planifiés Déploiement continu
Effectif d'équipe Conçu pour les équipes plus importantes Mieux adapté pour les équipes plus petites
Code Processus de revue Revue formelle lors des mergers de branches Revue continue des petites modifications fréquentes
Exigences de test Concentrez-vous sur les tests de fin de cycle Fort grande de la dépendance aux tests automatisés
Courbe d'apprentissage Plus complexe en raison de plusieurs branches Flux de travail plus simple, mais nécessite des tests solides
Risque de déploiement Moindre risque avec des lancements étalés Plus grand risque avec des mises à jour fréquentes
Temps de récupération Procédures de reprise plus lentes Capacités de reversion plus rapides

Quand utiliser chaque flux de travail

Git Flow est idéal pour les projets à niveau entreprise qui nécessitent des sorties structurées et versionnées. C'est un bon choix pour les équipes gérant plusieurs versions prises en charge et des projets avec des besoins de QA ou de conformité formels.

Développement Basé sur le Tronc fonctionne le mieux pour les équipes et les projets qui donnent la priorité à la vitesse et à la flexibilité, comme :

  • Les plateformes SaaS nécessitant des mises à jour rapides
  • Les équipes avec des pipelines CI/CD solides
  • Les projets soutenus par des tests automatisés fiables
  • Les workflows de déploiement continu ou des mises à jour fréquentes
  • Les projets d'applications mobiles nécessitant des mises à jour régulières

Certaines équipes combinent même les deux méthodes : en utilisant le Développement Basé sur le Tronc pour les services de base et Git Flow pour les projets avec des trajectoires de sortie formelles.

Prochainement : Comment configurer les pipelines CI/CD pour l'une ou l'autre approche.

Configuration du Pipeline CI/CD

Configuration du Pipeline CI/CD Git Flow

  • Branch de Développement Pipeline: Exécute les tests unitaires, les tests d'intégration, les code contrôles qualité, la vérification de la construction et la mise en ligne dans l'environnement de développement.
  • Pipeline de Branch de Version: Exécute l'ensemble du test, les scans de sécurité, construit un candidat de version et déploie vers l'environnement de pré-production.
  • Pipeline de Branch Principale: Effectue les tests de validation, gère la version, crée la construction de production, déploie vers la production et étiquette la version.

Configuration de CI/CD basée sur le Tronc

  • Pipeline de Branch de Fonctionnalité: Se concentre sur les tests unitaires rapides, les code contrôles de style, la vérification de la construction et la mise en ligne dans un environnement de prévisualisation.
  • Pipeline de Branch Principale: Couvre les tests automatisés approfondis, les scans de sécurité, la création de la construction de production, le déploiement progressif et les fonctionnalités de retrait automatique.

Capgo Intégration CI/CD

Capgo Tableau de bord d'actualisation en direct

Pour ajouter des mises à jour en temps réel sur le réseau à l'une ou l'autre configuration CI/CD, Capgo peut être intégré de manière fluide :

Capgo fonctionne avec GitHub Actions, GitLab CI, et Jenkins pour activer les mises à jour en direct, les déploiements étalés et les retours rapides dans les flux de travail Git Flow et Trunk-Based. Il répond aux exigences d'Apple et Google tout en offrant une prise en charge pour les déploiements cloud et auto-hébergés [1].

Résumé et recommandations

Choisissez votre flux de travail en fonction du niveau de maturité CI/CD et de la taille de votre équipe en utilisant le tableau ci-dessous :

Scénario Flux Git Développement Tronqué
Taille de l'équipe 50+ développeurs Moins de 50 développeurs
Rythme de mise à jour Hebdomadaire ou mensuel Journellement ou plusieurs fois par jour
Tests & QA Cycles de QA traditionnels Focus sur les tests automatisés
Modèle de déploiement Multi-version, traditionnel Cloud-native, conteneurisé
Attitude face au risque Ensembles de configuration réglementés Approches progressives avec feedback rapide
  • Démarrez avec le développement en tronc dans les petites équipes, puis étendez-le aux groupes plus importants. Assurez-vous que votre pipeline CI/CD est entièrement automatisé avant de passer à l'étape suivante.
  • Maintenez des revues cohérentes code et utilisez les commutateurs de fonctionnalité dans les deux workflows. Alignez les configurations de votre pipeline avec le workflow que vous sélectionnez.

Certains équipes peuvent mélanger ces approches - en utilisant Git Flow pour les mises à jour majeures tout en exploitant le développement en tronc pour la livraison de fonctionnalités. Quelle que soit la voie que vous prenez, le succès dépend de l'intégration de CI/CD, de l'automatisation des tests et de garder l'équipe sur la même page.

Continuez de Git Flow vs Trunk-Based pour CI/CD

Si vous utilisez Git Flow vs Trunk-Based pour CI/CD pour planifier l'automatisation de CI/CD, connectez-le à Capgo CI/CD pour le flux de travail du produit dans Capgo CI/CD Capgo Builds natifs pour le flux de travail du produit dans Capgo Builds natifs Capgo Intégrations pour le flux de travail du produit dans Capgo Intégrations Intégration CI/CD pour le détail d'implémentation dans Intégration CI/CD, et GitHub Intégration d'actions pour le détail d'implémentation dans GitHub Intégration d'actions

Mises à jour en temps réel pour les applications Capacitor

Lorsqu'un bug dans la couche web est en ligne, expédiez la correction à travers Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans le chemin de revue normal.

Commencez maintenant

Dernières actualités de notre blog

Capgo vous offre les meilleures informations nécessaires pour créer une application mobile véritablement professionnelle.