Mettre en œuvre une stratégie GitHub de branchement Flow pour les environnements multi-comptes DevOps

PDF

Créée par Mike Stephens (AWS) et Abhilash Vinod (AWS)

Récapitulatif

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 et Gitflow. 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 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 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

Prérequis

• Git, installé. Il est utilisé comme outil de dépôt de code source.

• Draw.io, installé. 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 (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 .

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.

AWS propose une suite de services de développement conçus pour vous aider à créer des pipelines CI/CD. Par exemple, AWS CodePipelineil 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 CodeBuildcompile 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.

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 CodeArtifactest 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 CodeBuildest 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 CodeDeployautomatise 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 CodePipelinevous 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 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 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. 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 Guidance et Choosing a Git Branching 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

Tâche	Description	Compétences requises
Passez en revue le processus GitHub Flow standard.	Dans l'environnement sandbox, le développeur crée une feature branche à partir de cette main branche et utilise le modèle feature/<ticket>_<initials>_<short description> de dénomination. Le développeur ajoute un ou plusieurs validations à la feature branche, chacune représentant une modification ou une amélioration discrète. Le développeur ouvre une demande de fusion (MR) pour fusionner les modifications dans la main branche. Cela lance un processus de révision. Au cours du processus de révision, les développeurs discutent des modifications apportées au code et fournissent des commentaires. L'objectif est de s'assurer que les modifications sont de haute qualité et répondent aux normes du projet. Une fois que le développeur a créé la demande de fusion, un processus de génération automatique démarre et déploie les modifications apportées à la feature branche dans l'environnement de développement. Des tests automatisés vérifient l'intégrité et la qualité des modifications encapsulées dans la demande de fusion. Une compilation réussie, un déploiement réussi et des tests réussis sont nécessaires pour terminer la demande de fusion. Lorsque le processus de révision est terminé, les modifications sont fusionnées dans la main branche. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement de test. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement intermédiaire. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement de production.	DevOps ingénieur
Passez en revue le processus de correction de bogues GitHub Flow.	Le développeur crée une bugfix branche à partir de cette main branche et utilise le modèle de dénominationbugfix/<ticket number>_<developer initials>_<descriptor>. Le développeur résout le problème, valide le correctif et crée la bugfix branche. Le développeur ouvre une demande de fusion pour fusionner la bugfix branche dans la main branche. Cela lance un processus de révision. Au cours du processus de révision, les développeurs discutent des modifications apportées au code et fournissent des commentaires. Une fois l'examen terminé et approuvé, le développeur complète la demande de fusion de la bugfix succursale avec la main succursale. Un approbateur approuve manuellement le déploiement des artefacts de version dans des environnements supérieurs.	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. Hotfixles 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évision des GitHub flux de travail Flow

Tâche	Description	Compétences requises
Passez en revue le processus GitHub Flow standard.	Dans l'environnement sandbox, le développeur crée une feature branche à partir de cette main branche et utilise le modèle feature/<ticket>_<initials>_<short description> de dénomination. Le développeur ajoute un ou plusieurs validations à la feature branche, chacune représentant une modification ou une amélioration discrète. Le développeur ouvre une demande de fusion (MR) pour fusionner les modifications dans la main branche. Cela lance un processus de révision. Au cours du processus de révision, les développeurs discutent des modifications apportées au code et fournissent des commentaires. L'objectif est de s'assurer que les modifications sont de haute qualité et répondent aux normes du projet. Une fois que le développeur a créé la demande de fusion, un processus de génération automatique démarre et déploie les modifications apportées à la feature branche dans l'environnement de développement. Des tests automatisés vérifient l'intégrité et la qualité des modifications encapsulées dans la demande de fusion. Une compilation réussie, un déploiement réussi et des tests réussis sont nécessaires pour terminer la demande de fusion. Lorsque le processus de révision est terminé, les modifications sont fusionnées dans la main branche. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement de test. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement intermédiaire. Un approbateur approuve manuellement le déploiement des artefacts de version dans l'environnement de production.	DevOps ingénieur
Passez en revue le processus de correction de bogues GitHub Flow.	Le développeur crée une bugfix branche à partir de cette main branche et utilise le modèle de dénominationbugfix/<ticket number>_<developer initials>_<descriptor>. Le développeur résout le problème, valide le correctif et crée la bugfix branche. Le développeur ouvre une demande de fusion pour fusionner la bugfix branche dans la main branche. Cela lance un processus de révision. Au cours du processus de révision, les développeurs discutent des modifications apportées au code et fournissent des commentaires. Une fois l'examen terminé et approuvé, le développeur complète la demande de fusion de la bugfix succursale avec la main succursale. Un approbateur approuve manuellement le déploiement des artefacts de version dans des environnements supérieurs.	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. Hotfixles 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 productionfeature, 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 avecmain.
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.

Les ressources suivantes peuvent vous aider dans votre parcours de branchement GitHub Flow dans le AWS Cloud.

AWS DevOps orientation

• AWS DevOps Orientations

• AWS Architecture de référence du pipeline de déploiement

• Qu'est-ce que c'est DevOps ?

• DevOps resources

GitHub Guidage des flux

• GitHub Tutoriel de démarrage rapide de Flow () GitHub

• Pourquoi GitHub Flow ?

Autres ressources

• Méthodologie d'application à douze facteurs (12factor.net)