Explorer le modèle de branche Git pour la livraison continue

  • 3 minutes

La livraison de logiciels réussie dépend d’une stratégie de branchement qui équilibre la vitesse, la qualité et la gestion des risques. L’objectif est d’expédier rapidement des améliorations tout en conservant la stabilité de la production.

Équilibre stratégique : vitesse et qualité

Un modèle de branchement efficace doit atteindre le bon équilibre :

  • Réduisez la surcharge du processus pour accélérer le délai de commercialisation.
  • Maintenir des portes de qualité pour empêcher les défauts d’atteindre la production.
  • Activez le développement parallèle pour l’extensibilité de l’équipe.
  • Prendre en charge le déploiement rapide des correctifs logiciels pour les problèmes critiques.

Bien que de nombreuses stratégies de branchement Git existent, l’approche la plus efficace combine les modèles éprouvés avec les besoins spécifiques de votre équipe. Les équipes d’entreprise modernes adoptent généralement un modèle de développement léger basé sur le tronc centré sur les branches de fonctionnalités et les requêtes de tirage.

Principe fondamental : branche principale toujours prête

Cette unité vous apprend à implémenter un modèle de branchement prêt pour la livraison continue à l’aide de branches de fonctionnalités et de demandes de tirage pour maintenir en permanence une branche principale déployable.

Cadre stratégique de gestion des branches d'entreprise

Les principes suivants établissent une base robuste pour la livraison continue :

Stabilité de branche principale

  • Source unique de vérité : la branche principale est le chemin exclusif des versions de production.
  • Préparation de la production : la branche principale doit toujours être dans un état déployable.
  • Protection des branches : Mettez en œuvre des politiques de branche complètes pour empêcher les commits directs.
  • Modifications contrôlées : toutes les modifications transitent exclusivement via des pull requests.
  • Suivi des mises en production : balisez toutes les versions de production avec des balises Git sémantiques.

Discipline de la branche fonctionnelle

  • Développement isolé : créez des branches dédiées pour toutes les fonctionnalités et correctifs de bogues.
  • Intégration de l’indicateur de fonctionnalité : gérez les fonctionnalités de longue durée avec des bascules de fonctionnalité pour réduire la durée de vie des branches.
  • Nommage stratégique : utilisez des conventions d’affectation de noms descriptives qui reflètent la valeur métier.
  • Workflow de demande de tirage (pull request) : fusionnez vers la branche primaire exclusivement à travers des demandes de tirage examinées.

Stratégie de branche de mise en production

  • Préparation dédiée : créez des branches de mise en production à partir de points d’intégration de fonctionnalités stables.
  • Assurance qualité : Effectuer des tests et une stabilisation approfondis sur les branches de mise en production.
  • Renforcement de la production : appliquez les correctifs de bogues finaux et les optimisations des performances.
  • Suivi des jalons : balisez des jalons de mise en production significatifs pour la traçabilité.

Conventions d’affectation de noms pour la mise à l’échelle

# Bug fixes
bugfix/[ticket-id]-description
bugfix/AUTH-123-login-timeout

# Feature development
features/[area]/[feature-name]
features/authentication/oauth-integration
features/api/rate-limiting

# Hotfixes
hotfix/[severity]-description
hotfix/critical-payment-gateway

# Personal branches
users/[username]/[description]
users/john-doe/experimental-caching

Gestion des demandes de tirage

  • Révision de code obligatoire : aucune exception pour les fusions directes vers le principal.
  • Validation automatisée : intégrez des pipelines CI/CD pour des portes de qualité.
  • Métriques de performances : assurez le suivi et optimisez le temps d'achèvement des pull requests.
  • Partage des connaissances : Utilisez des révisions pour l’apprentissage de l’équipe et l’application des normes.

Prérequis et configuration

Outils essentiels pour les flux de travail Git d’entreprise

Cet exercice pratique tire parti de la chaîne d’outils DevOps complète d’Azure :

  • Azure CLI : interface de ligne de commande native cloud pour les services Azure.
  • Azure DevOps CLI : extension spécialisée pour l’intégration transparente des outils Git, CI/CD et Agile sur Windows, Linux et macOS.

Configuration de l'interface en ligne de commande Azure DevOps

Azure DevOps CLI fournit une mise en forme de sortie flexible (JSON, YAML, table, TSV) pour prendre en charge différents scénarios d’automatisation. Configurez votre format préféré à l’aide de :

az devops configure --defaults output=table

Implémentation pratique : Workflow Git pour les entreprises

Cette procédure pas à pas complète illustre la branche Git de niveau entreprise pour la livraison continue, couvrant le développement de fonctionnalités, le déploiement de correctifs logiciels et la résolution des conflits.

Étape 1 : Création et développement de branche de fonctionnalité

Créez une branche de fonctionnalités suivant les conventions d’affectation de noms d’entreprise :

myWebApp

git checkout -b feature/myFeature-1

Sortie :Basculé vers une nouvelle branche « feature/myFeature-1 ».

Vérifiez le contexte de branche et l’état de l’arborescence de travail :

myWebApp

git branch

Sortie :✓ feature/myFeature-1

  • principal*

Étape 2 : Implémentation de fonctionnalités et contrôle de version

Implémentez vos modifications de fonctionnalité :

myWebApp

# Edit your source files
code Program.cs  # Or your preferred editor

Suivez le cycle de vie de validation complet :

myWebApp

git status

Sortie :Sur ma branche feature/myFeature-1Modifications non préparées pour le commit :

  • modifié : Program.cs*

myWebApp

git add .
git commit -m "feat: implement myFeature-1 with enhanced error handling"

Sortie :[feature/myFeature-1 70f67b2] feat : implémentez myFeature-1 avec une gestion améliorée des erreurs1 fichier modifié, 1 insertion(+)

Publier sur un référentiel distant :

myWebApp

git push -u origin feature/myFeature-1

Sortie :Vers https://dev.azure.com/organization/teamproject/_git/MyWebApp

  • [nouvelle branche] feature/myFeature-1 –>feature/myFeature-1Branche feature/myFeature-1 définie pour suivre la branche distante feature/myFeature-1 depuis l’origine.

Étape 3 : Configuration de l'interface CLI Azure DevOps et création d'une pull request

Configurez Azure DevOps CLI pour votre organisation et votre projet. Remplacez organisation et nom du projet :

az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

Créez une nouvelle pull request (avec Azure DevOps CLI) pour examiner les modifications de la branche feature-1 :

az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

Utilisez le commutateur --open lors du lancement de la demande de tirage pour l’ouvrir dans un navigateur web après l’avoir créée. Le --deletesource-branch paramètre peut être utilisé pour supprimer la branche une fois le pull request terminé. Envisagez également d'utiliser l'option --auto-complete pour compléter automatiquement lorsque toutes les stratégies sont validées, et que la branche source peut être fusionnée dans la branche cible.

Remarque

Pour plus d’informations sur le paramètre az repos pr create, consultez Créer une demande de pull pour examiner et fusionner le code.

L’équipe examine conjointement les modifications du code et approuve le pull request.

Capture d’écran de la pull request avec les modifications de code approuvées et complétées.

La branche primaire est prête pour publication. L’équipe étiquette la branche primaire avec le numéro de publication :

Capture d’écran de la création d’un exemple d’étiquette.

Étape 4 : Développement de fonctionnalités parallèles

Commencez à travailler sur Feature 2. Créez une branche sur un dépôt distant à partir de la branche primaire et effectuez l’extraction localement :

myWebApp

git push origin main:refs/heads/feature/myFeature-2

Sortie :Total 0 (delta 0), réitomosé 0 (delta 0) à https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nouvelle branche] origin/HEAD –> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Output:Passé à une nouvelle branche « feature/myFeature-2 » feature/myFeature-2 défini pour suivre la branche distante feature/myFeature-2 depuis l’origine.

Modifiez Program.cs en modifiant la même ligne de commentaire dans le code modifié dans la fonctionnalité 1 :

```
public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
```

Étape 5 : Scénario de pull request et de correctif de la fonctionnalité 2

Commitez les modifications localement, poussez-les vers le dépôt distant, puis lancez une demande de tirage pour fusionner les modifications de feature/myFeature-2 avec la branche main :

az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

Un bogue critique est signalé en production dans la publication de feature-1 dans la demande de tirage en cours. Pour investiguer, vous devez déboguer sur la version du code actuellement déployée en production. Pour enquêter sur le problème, créez une nouvelle branche fof en utilisant l’étiquette "release_feature1" :

myWebApp

git checkout -b fof/bug-1 release_feature1

Sortie :Passé à une nouvelle branche « fof/bug-1 ».

Étape 6 : Implémentation du correctif logiciel critique

Modifiez Program.cs en changeant la même ligne de code qui a été changée dans la publication de feature-1 :

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Indexez et validez les modifications localement, puis envoyez les modifications vers le dépôt distant :

myWebApp

git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

Sortie :Vers https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nouvelle branche] fof/bug-1 – Branche fof/bug-1 fof/bug-1 défini pour suivre la branche distante fof/bug-1 depuis l’origine.

Étape 7 : Intégration des correctifs logiciels et résolution des conflits

Tout de suite après le déploiement des modifications en production, taggez la branche fof/bug-1 avec le tag release_bug-1, puis lancez une pull request pour fusionner les modifications de fof/bug-1 dans la branche principale.

az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

Dans le cadre de la pull request, la branche est supprimée. Toutefois, vous pouvez quand même référencer la totalité de l’historique avec l’étiquette.

Une fois le bogue critique corrigé, passons en revue la pull request de feature-2.

La page des branches indique clairement que la branche feature/myFeature-2 est en avance d'une modification par rapport à la branche principale et en retard de deux modifications par rapport à celle-ci.

Capture d’écran de la page des branches. Les deux branches de la fonctionnalité myFeature sont en avance d’une modification par rapport à la branche principale et en retard de deux modifications par rapport à la branche principale.

Si vous aviez essayé d’approuver le pull request, vous verriez un message d’erreur s’afficher vous informant d’un conflit de fusion.

Capture d’écran des conflits de fusion de la demande de tirage.

Résoudre les conflits de fusion

Pour résoudre les conflits de fusion, vous pouvez utiliser l’interface web Azure DevOps ou les résoudre localement à l’aide de commandes Git. Pour la résolution locale, commencez par mettre à jour votre branche de fonctionnalité avec les dernières modifications de la version principale :

```CMD
git checkout feature/myFeature-2
git fetch origin
git merge origin/main
```

Résolvez les conflits dans votre éditeur préféré, puis effectuez la fusion :

```CMD
git add .
git commit -m "Resolve merge conflicts between feature-2 and main"
git push origin feature/myFeature-2
```

Une fois les conflits résolus, le pull request peut être finalisé avec succès.

À ce stade, vous pouvez créer une branche de mise en production en fonction du correctif de bogue critique implémenté dans la branche fof/bug-1 et fusionnée dans la branche principale. À l’aide de la commande git checkout, créez une branche de mise en production dédiée à partir de la branche principale.

git checkout -b release/v1.1 main

Cette commande crée une branche nommée release/v1.1 basée sur la branche principale.

Au fur et à mesure que des jalons significatifs sont atteints pendant le processus de publication, marquez les versions dans la branche de publication en utilisant des tags Git. Les balises servent de marqueurs pour désigner des versions spécifiques du logiciel.

git tag -a v1.1 -m "Release version 1.1"

Cette commande crée une balise nommée v1.1 pour marquer la version de mise en production 1.1 dans la branche de mise en production.

Fonctionnement

Nous avons appris comment le modèle de branchement Git vous donne la possibilité de travailler en parallèle sur plusieurs fonctionnalités en créant une branche pour chacune d’elles.

Le workflow des pull requests vous permet de réviser les modifications du code à l’aide de stratégies de branche.

Les étiquettes Git sont un excellent moyen d’enregistrer des jalons, tels que la version du code publié, et vous permettent de créer des branches à partir d’étiquettes.

Nous avons créé une branche à partir d’une étiquette de publication précédente pour résoudre un bogue critique en production.

La vue des branches dans le portail web rend facile l’identification des branches devançant la principale. Elle force également un conflit de fusion si des demandes de tirage en cours essaient de fusionner avec la branche primaire sans résoudre les conflits de fusion.

Un modèle de branchement épuré vous permet de créer des branches courte durée et de pousser les modifications de qualité en production plus vite.