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.
# Mettre en œuvre une stratégie GitHub de branchement Flow pour les environnements multi-comptes DevOps
*Mike Stephens et Abhilash Vinod, Amazon Web Services*
## Résumé
Lors de la gestion d'un référentiel de code source, différentes stratégies de branchement affectent les processus de développement et de publication des logiciels utilisés par les équipes de développement. Trunk, Flow et GitHub Gitflow sont des exemples de stratégies de branchement courantes. Ces stratégies utilisent différentes branches et les activités effectuées dans chaque environnement sont différentes. Organisations qui mettent en œuvre DevOps des processus bénéficieraient d'un guide visuel pour les aider à comprendre les différences entre ces stratégies de branchement. L'utilisation de ce visuel dans votre organisation aide les équipes de développement à aligner leur travail et à respecter les normes organisationnelles. Ce modèle fournit ce visuel et décrit le processus de mise en œuvre d'une stratégie de branchement GitHub Flow dans votre organisation.
Ce modèle fait partie d'une série de documentation sur le choix et la mise en œuvre de stratégies de DevOps succursales pour les organisations qui en ont plusieurs Comptes AWS. Cette série est conçue pour vous aider à appliquer la bonne stratégie et les meilleures pratiques dès le départ, afin de rationaliser votre expérience dans le cloud. GitHub Flow n'est qu'une des stratégies de branchement possibles que votre organisation peut utiliser. Cette série de documentation couvre également les modèles de branchement [Trunk](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html) et [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html). Si ce n'est pas déjà fait, nous vous recommandons de consulter [Choisir une stratégie de branchement Git pour les DevOps environnements multi-comptes](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) avant de mettre en œuvre les instructions de ce modèle. Veuillez faire preuve de diligence raisonnable pour choisir la bonne stratégie de succursale pour votre organisation.
Ce guide fournit un schéma qui montre comment une organisation peut mettre en œuvre la stratégie GitHub Flow. Il est recommandé de consulter le guide [AWS DevOps Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) pour passer en revue les meilleures pratiques. Ce modèle inclut les tâches, les étapes et les restrictions recommandées pour chaque étape du DevOps processus.
## Conditions préalables et limitations
**Conditions préalables**
+ Git, [installé](https://git-scm.com/downloads). Il est utilisé comme outil de dépôt de code source.
+ [Draw.io, installé.](https://github.com/jgraph/drawio-desktop/releases) Cette application permet de visualiser et de modifier le diagramme.
## Architecture
**Architecture cible**
Le schéma suivant peut être utilisé comme un [carré de Punnett](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia). Vous 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 indiquent la séquence des actions du flux de travail. Cet exemple vous emmène d'une `feature` succursale à un déploiement en production.
Pour plus d'informations sur les Comptes AWS environnements et les branches d'une approche GitHub Flow, consultez [Choisir une stratégie de branchement Git pour les environnements multi-comptes DevOps ](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach).
**Automatisation et mise à l'échelle**
L'intégration continue et la livraison continue (les CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CD pipelines) fournissent également une gouvernance et des garanties aux équipes de développement en garantissant la cohérence, les normes, les meilleures pratiques et les niveaux d'acceptation minimaux pour l'acceptation et le déploiement des fonctionnalités. Pour plus d'informations, voir [Pratiquer l'intégration continue et la livraison continue sur AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html).
AWS propose une suite de services de développement conçus pour vous aider à créer des CI/CD pipelines. Par exemple, [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)il s'agit d'un service de livraison continue entièrement géré qui vous aide à automatiser vos pipelines de publication pour des mises à jour rapides et fiables des applications et de l'infrastructure. [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)compile le code source, exécute des tests et produit des ready-to-deploy progiciels. Pour plus d'informations, consultez la section [Outils de développement sur AWS](https://aws.amazon.com/products/developer-tools/).
## Outils
**AWS services et outils**
AWS fournit une suite de services de développement que vous pouvez utiliser pour implémenter ce modèle :
+ [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html)est un service de référentiel d'artefacts géré hautement évolutif qui vous permet de stocker et de partager des progiciels pour le développement d'applications.
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)est un service de génération entièrement géré qui vous aide à compiler le code source, à exécuter des tests unitaires et à produire des artefacts prêts à être déployés.
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)automatise les déploiements vers Amazon Elastic Compute Cloud EC2 (Amazon) ou vers des instances, des AWS Lambda fonctions ou des services Amazon Elastic Container Service (Amazon ECS) sur site.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)vous permet de modéliser et de configurer rapidement les différentes étapes d'une version logicielle et d'automatiser les étapes nécessaires à la publication continue des modifications logicielles.
**Autres outils**
+ [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) est une application pour créer des organigrammes et des diagrammes. Le référentiel de code contient des modèles au format .drawio pour Draw.io.
+ [Figma](https://www.figma.com/design-overview/) est un outil de conception en ligne conçu pour la collaboration. Le référentiel de code contient des modèles au format .fig pour Figma.
**Référentiel de code**
Ce fichier source pour le diagramme de ce modèle est disponible dans le référentiel GitHub [Git Branching Strategy for GitHub Flow](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow). Il inclut des fichiers aux formats PNG, draw.io et Figma. Vous pouvez modifier ces diagrammes pour soutenir les processus de votre organisation.
## Bonnes pratiques
Suivez les meilleures pratiques et recommandations décrites dans [AWS DevOps Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) Guidance et [Choosing a Git Branching](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) strategy pour les environnements multi-comptes. DevOps Ils vous aident à mettre en œuvre efficacement le développement GitHub basé sur Flow, à favoriser la collaboration, à améliorer la qualité du code et à rationaliser le processus de développement.
## Épopées
### Révision des GitHub flux de travail Flow
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Passez en revue le processus GitHub Flow standard. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps ingénieur |
| Passez en revue le processus de correction de bogues GitHub Flow. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps ingénieur |
| Passez en revue le processus du correctif GitHub Flow. | GitHub Flow est conçu pour permettre une diffusion continue, dans le cadre de laquelle les modifications de code sont déployées fréquemment et de manière fiable dans des environnements supérieurs. L'essentiel est que chaque `feature` branche puisse être déployée à tout moment.
`Hotfix`les branches, qui sont apparentées à `feature` ou à `bugfix` des branches, peuvent suivre le même processus que l'une ou l'autre de ces branches. Cependant, étant donné leur urgence, les correctifs ont généralement une priorité plus élevée. En fonction des politiques de l'équipe et de l'urgence de la situation, certaines étapes du processus pourraient être accélérées. Par exemple, les révisions de code pour les correctifs peuvent être accélérées. Par conséquent, bien que le processus de correction soit parallèle au processus de correction des fonctionnalités ou des bogues, l'urgence des correctifs peut justifier des modifications de la conformité procédurale. Il est essentiel d'établir des directives relatives à la gestion des correctifs afin de s'assurer qu'ils sont gérés de manière efficace et sécurisée. | DevOps ingénieur |
## Résolution des problèmes
| Problème | Solution |
| --- | --- |
| Conflits entre branches | Un problème courant qui peut survenir avec le modèle GitHub Flow est lorsqu'un correctif doit être appliqué en production`feature`, `bugfix` mais qu'une modification correspondante doit se produire dans une `hotfix` branche ou une branche où les mêmes ressources sont modifiées. Nous vous recommandons de fusionner fréquemment les modifications depuis `main` les branches inférieures afin d'éviter des conflits importants lors de la fusion avec`main`. |
| Maturité des équipes | GitHub Flow encourage les déploiements quotidiens vers des environnements supérieurs, en adoptant une véritable intégration continue et une livraison continue (CI/CD). Il est impératif que l'équipe possède la maturité technique nécessaire pour créer des fonctionnalités et créer des tests d'automatisation pour celles-ci. L'équipe doit effectuer un examen exhaustif des demandes de fusion avant que les modifications ne soient approuvées. Cela favorise une solide culture d'ingénierie qui favorise la qualité, la responsabilité et l'efficacité du processus de développement. |
## Ressources connexes
Ce guide n'inclut pas de formation à Git ; toutefois, de nombreuses ressources de haute qualité sont disponibles sur Internet si vous avez besoin de cette formation. Nous vous recommandons de commencer par le site de [documentation Git](https://git-scm.com/doc).
Les ressources suivantes peuvent vous aider dans votre parcours de branchement GitHub Flow dans le AWS Cloud.
**AWS DevOps orientation**
+ [AWS DevOps Conseils](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS Architecture de référence du pipeline de déploiement](https://pipelines.devops.aws.dev/)
+ [Qu'est-ce que c'est DevOps ?](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps resources](https://aws.amazon.com/devops/resources/)
**GitHub Guidage du flux**
+ [GitHub Tutoriel de démarrage rapide de Flow](https://docs.github.com/en/get-started/using-github/github-flow) () GitHub
+ [Pourquoi GitHub Flow ?](https://githubflow.github.io/)
**Autres ressources**
+ [Méthodologie d'application à douze facteurs (12factor.net](https://12factor.net/))