Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Stratégie de branchement Gitflow Gitflow est un modèle de branchement qui implique l'utilisation de plusieurs branches pour faire passer le code du développement à la production. Gitflow fonctionne bien pour les équipes qui ont des cycles de publication planifiés et qui ont besoin de définir un ensemble de fonctionnalités en tant que version. Le développement est effectué dans des branches de fonctionnalités individuelles qui sont fusionnées, avec approbation, dans une branche de développement, qui est utilisée pour l'intégration. Les fonctionnalités de cette branche sont considérées comme prêtes à être produites. Lorsque toutes les fonctionnalités planifiées sont accumulées dans la branche de développement, une branche de publication est créée pour les déploiements dans des environnements supérieurs. Cette séparation permet de mieux contrôler quelles modifications sont transférées vers tel ou tel environnement nommé selon un calendrier défini. Si nécessaire, vous pouvez accélérer ce processus pour obtenir un modèle de déploiement plus rapide. Pour plus d'informations sur la stratégie de branchement de Gitflow, consultez les ressources suivantes : + [Mettre en œuvre une stratégie de branchement Gitflow pour les DevOps environnements multi-comptes (directives prescriptives](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html))AWS + [Le blog original de Gitflow (article de blog](https://nvie.com/posts/a-successful-git-branching-model/) de Vincent Driessen) + Flux de travail [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian) **Topics** + [Aperçu visuel de la stratégie Gitflow](visual-overview-of-the-gitflow-strategy.md) + [Branches dans une stratégie Gitflow](branches-in-a-gitflow-strategy.md) + [Avantages et inconvénients de la stratégie Gitflow](advantages-and-disadvantages-of-the-gitflow-strategy.md) # Aperçu visuel de la stratégie Gitflow Le schéma suivant peut être utilisé comme un [carré de Punnett](https://en.wikipedia.org/wiki/Punnett_square) pour comprendre la stratégie de branchement de Gitflow. Alignez les branches sur l'axe vertical avec les AWS environnements sur l'axe horizontal pour déterminer les actions à effectuer dans chaque scénario. Les chiffres encerclés vous guident dans la séquence d'actions représentée dans le diagramme. Pour plus d'informations sur les activités qui se produisent dans chaque environnement, consultez la section [DevOps environnements](understanding-the-devops-environments.md) de ce guide. ![\[Tableau récapitulatif des activités de Gitflow dans chaque branche et environnement\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png) # Branches dans une stratégie Gitflow Une stratégie de branchement Gitflow comporte généralement les branches suivantes. ![\[Les branches et les environnements d'une stratégie de branchement Gitflow.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png) ## branche de fonctionnalités `Feature`les branches sont des branches à court terme dans lesquelles vous développez des fonctionnalités. La `feature` branche est créée en partant de la `develop` branche. Les développeurs itèrent, valident et testent le code dans la `feature` branche. Lorsque la fonctionnalité est terminée, le développeur en fait la promotion. Il n'existe que deux voies de transfert à partir d'une branche de fonctionnalités : + Fusionner dans la `sandbox` branche + Créez une demande de fusion dans la `develop` succursale | | | | --- |--- | | Convention de dénomination : | `feature/__` | | Exemple de convention de dénomination : | `feature/123456_MS_Implement_Feature_A` | ## branche de bac à sable La `sandbox` branche est une branche non standard à court terme pour Gitflow. Cependant, il est utile pour le développement de CI/CD pipelines. La `sandbox` branche est principalement utilisée aux fins suivantes : + Effectuez un déploiement complet dans l'environnement sandbox en utilisant les CI/CD pipelines plutôt qu'un déploiement manuel. + Développez et testez un pipeline avant de soumettre des demandes de fusion pour des tests complets dans un environnement inférieur, tel que le développement ou les tests. `Sandbox`les branches sont de nature temporaire et ne sont pas destinées à durer longtemps. Ils doivent être supprimés une fois les tests spécifiques terminés. | | | | --- |--- | | Convention de dénomination : | `sandbox/__` | | Exemple de convention de dénomination : | `sandbox/123456_MS_Test_Pipeline_Deploy` | ## développer une branche La `develop` branche est une branche durable dans laquelle les fonctionnalités sont intégrées, créées, validées et déployées dans l'environnement de développement. Toutes les `feature` branches sont fusionnées dans la `develop` branche. Les fusions avec la `develop` branche sont effectuées par le biais d'une demande de fusion qui nécessite une compilation réussie et deux approbations de développeurs. Pour empêcher la suppression, activez la protection des branches sur la `develop` branche. | | | | --- |--- | | Convention de dénomination : | `develop` | ## branche de sortie Dans Gitflow, `release` les branches sont des branches à court terme. Ces branches sont spéciales car vous pouvez les déployer dans plusieurs environnements, en adoptant la méthodologie Build-Once, Deploy-Many. `Release`les branches peuvent cibler les environnements de test, de préparation ou de production. Une fois qu'une équipe de développement a décidé de promouvoir des fonctionnalités dans des environnements supérieurs, elle crée une nouvelle `release` branche et utilise le numéro de version incrémenté par rapport à la version précédente. Au niveau de chaque environnement, les déploiements nécessitent des approbations manuelles pour pouvoir être effectués. `Release`les branches doivent nécessiter la modification d'une demande de fusion. Une fois que la `release` branche a été déployée en production, elle doit être fusionnée à nouveau dans les `main` branches `develop` et pour s'assurer que les corrections de bogues ou les correctifs seront intégrés dans les futurs efforts de développement. | | | | --- |--- | | Convention de dénomination : | `release/v{major}.{minor}` | | Exemple de convention de dénomination : | `release/v1.0` | ## branche principale La `main` branche est une branche à longue durée de vie qui représente toujours le code en cours d'exécution en production. Le code est automatiquement fusionné dans la `main` branche à partir d'une branche de version après un déploiement réussi depuis le pipeline de publication. Pour empêcher la suppression, activez la protection des branches sur la `main` branche. | | | | --- |--- | | Convention de dénomination : | `main` | ## branche bugfix La `bugfix` branche est une branche à court terme qui est utilisée pour résoudre les problèmes dans les branches de publication qui n'ont pas été mises en production. Une `bugfix` branche ne doit être utilisée que pour promouvoir les corrections apportées dans `release` les branches aux environnements de test, de test ou de production. Une `bugfix` branche est toujours dérivée d'une `release` branche. Une fois le correctif testé, il peut être promu vers la `release` branche par le biais d'une demande de fusion. Vous pouvez ensuite faire avancer la `release` branche en suivant le processus de publication standard. | | | | --- |--- | | Convention de dénomination : | `bugfix/__` | | Exemple de convention de dénomination : | `bugfix/123456_MS_Fix_Problem_A` | ## branche hotfix La `hotfix` succursale est une succursale à court terme utilisée pour résoudre les problèmes de production. Il ne doit être utilisé que pour promouvoir des correctifs qui doivent être accélérés pour atteindre l'environnement de production. Une `hotfix` branche est toujours issue d'une branche. `main` Une fois le correctif testé, vous pouvez le promouvoir en production par le biais d'une demande de fusion dans la `release` branche à partir `main` de laquelle il a été créé. Pour les tests, vous pouvez ensuite faire avancer la `release` branche en suivant le processus de publication standard. | | | | --- |--- | | Convention de dénomination : | `hotfix/__` | | Exemple de convention de dénomination : | `hotfix/123456_MS_Fix_Problem_A` | # Avantages et inconvénients de la stratégie Gitflow La stratégie de branchement de Gitflow convient parfaitement aux équipes plus importantes et plus distribuées qui ont des exigences strictes en matière de publication et de conformité. Gitflow contribue à un cycle de publication prévisible pour l'organisation, ce qui est souvent préféré par les grandes entreprises. Gitflow convient également aux équipes qui ont besoin de garde-fous pour terminer correctement leur cycle de vie de développement logiciel. Cela s'explique par le fait que la stratégie comporte de nombreuses opportunités d'évaluation et d'assurance qualité. Gitflow convient également aux équipes qui doivent gérer simultanément plusieurs versions de versions de production. Certains inconvénients GItflow sont qu'il est plus complexe que les autres modèles de branchement et qu'il nécessite un strict respect du modèle pour réussir. Gitflow ne fonctionne pas bien pour les organisations qui recherchent une livraison continue en raison de la nature rigide de la gestion des branches de publication. Les agences de lancement de Gitflow peuvent être des succursales à longue durée de vie susceptibles d'accumuler des dettes techniques si elles ne sont pas traitées correctement en temps opportun. ## Avantages Le développement basé sur Gitflow offre plusieurs avantages qui peuvent améliorer le processus de développement, rationaliser la collaboration et améliorer la qualité globale du logiciel. Voici quelques-uns des principaux avantages : + **Processus de publication prévisible** — Gitflow suit un processus de publication régulier et prévisible. Il convient parfaitement aux équipes ayant des cadences de développement et de publication régulières. + **Collaboration améliorée** — Gitflow encourage l'utilisation de `feature` et de `release` branches. Ces deux branches permettent aux équipes de travailler en parallèle avec un minimum de dépendance les unes par rapport aux autres. + **Bien adapté à plusieurs environnements**, Gitflow utilise des `release` branches, qui peuvent avoir une durée de vie plus longue. Ces branches permettent aux équipes de cibler des versions individuelles sur une plus longue période. + **Plusieurs versions en production** — Si votre équipe prend en charge plusieurs versions du logiciel en production, les `release` succursales de Gitflow prennent en charge cette exigence. + **Révisions intégrées de la qualité du code** : Gitflow exige et encourage l'utilisation de révisions et d'approbations de code avant que le code ne soit promu dans un autre environnement. Ce processus élimine les frictions entre les développeurs en imposant cette étape pour toutes les promotions de code. + **Avantages pour l'organisation** — Gitflow présente également des avantages au niveau de l'organisation. Gitflow encourage l'utilisation d'un cycle de publication standard, qui aide l'organisation à comprendre et à anticiper le calendrier de publication. Comme l'entreprise sait désormais quand de nouvelles fonctionnalités peuvent être proposées, les délais sont réduits grâce à des dates de livraison fixes. ## Inconvénients Le développement basé sur Gitflow présente certains inconvénients qui peuvent avoir un impact sur le processus de développement et la dynamique de l'équipe. Voici quelques inconvénients notables : + **Complexité** — Gitflow est un modèle complexe que les nouvelles équipes doivent apprendre, et vous devez respecter les règles de Gitflow pour l'utiliser avec succès. + **Déploiement continu** — Gitflow ne convient pas à un modèle dans lequel de nombreux déploiements sont rapidement mis en production. Cela est dû au fait que Gitflow nécessite l'utilisation de plusieurs branches et un flux de travail strict régissant la `release` branche. + **Gestion des succursales** — Gitflow utilise de nombreuses branches, dont la maintenance peut s'avérer fastidieuse. Il peut être difficile de suivre les différentes branches et de fusionner le code publié afin de maintenir les branches correctement alignées les unes avec les autres. + **Dette technique** — Les versions de Gitflow étant généralement plus lentes que les autres modèles de branchement, un plus grand nombre de fonctionnalités peuvent s'accumuler au fur et à mesure de leur publication, ce qui peut entraîner une accumulation de dettes techniques. Les équipes doivent soigneusement prendre en compte ces inconvénients lorsqu'elles décident si le développement basé sur Gitflow est la bonne approche pour leur projet.