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

3 minutes

L’objectif de l’écriture de code est de livrer des améliorations à votre logiciel.

Un modèle de branchement qui introduit une trop grande surcharge de processus n’aide pas à augmenter la vitesse à laquelle les clients obtiennent les modifications. Le développement d’un modèle de branchement vous offre suffisamment de marge pour ne pas livrer des modifications de mauvaise qualité. Mais, qui en même temps n’introduit pas trop de processus qui vous ralentiraient.

Internet regorge de stratégies de branche pour Git. Il n’y en a pas de bonne ou de mauvaise, la stratégie de branche parfaite est celle qui fonctionne pour votre équipe !

Vous y apprendrez toujours à utiliser la combinaison de branches de fonctionnalités et de demandes de tirage permettant d’avoir une branche primaire prête pour livraison.

Préparation

Parlons des principes de ce que nous proposons :

La branche primaire :
- La branche primaire est le seul moyen d’envoyer quoi que ce soit en production.
- La branche primaire doit toujours être dans un état prêt pour publication.
- Protégez la branche primaire à l’aide de stratégies de branche.
- Toutes les modifications de la branche primaire passent uniquement par des demandes de tirage.
- Étiquetez toutes les publications de la branche primaire avec des étiquettes Git.
La branche de fonctionnalité :
- Utilisez des branches de fonctionnalité pour toutes les nouvelles fonctionnalités et tous les correctifs de bogues.
- Utilisez des indicateurs de fonctionnalité pour gérer les branches de fonctionnalité longue durée.
- Les modifications qui vont des branches de fonctionnalité vers la branche primaire passent uniquement par des demandes de tirage.
- Nommez votre fonctionnalité pour décrire son rôle.
Branche de mise en production :
- Créez une branche de mise en production dédiée à partir d’une branche de mise en production stable pour préparer un déploiement.
- Veillez à ce que la branche de mise en production fasse l’objet de tests et d’efforts de stabilisation soigneux.
- Appliquez les correctifs de bogues et les modifications nécessaires à la branche de mise en production avant le déploiement.
- Marquez les mises en production dans la branche de mise en production pour marquer les jalons importants.
Liste des branches :
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
Demandes de tirage :
- Révisez et fusionnez le code avec des demandes de tirage.
- Automatisez ce que vous inspectez et validez dans le cadre des demandes de tirage.
- Suivez la durée d’exécution des demandes de tirage et définissez des objectifs pour réduire le temps qu’elles prennent.

Nous allons utiliser myWebApp des exercices précédents. Consultez Décrire l’utilisation locale de Git.

Dans cette recette, nous allons utiliser trois extensions tendance de la place de marché :

Azure CLI : Interface de ligne de commande pour Azure.
Azure DevOps CLI : il s’agit d’une extension d’Azure CLI permettant d’utiliser Azure DevOps et Azure DevOps Server. Elle est conçue pour s’intégrer de façon fluide à Git, aux pipelines CI et aux outils Agile. Avec Azure DevOps CLI, vous pouvez contribuer à vos projets sans quitter la ligne de commande. CLI s’exécute sur Windows, Linux et Mac.
Git Pull Request Merge Conflict : Cette extension open source créée par Microsoft DevLabs vous permet de réviser et de résoudre les conflits de fusion des demandes de tirage sur le web. Tous les conflits avec la branche cible doivent être résolus avant qu’une demande de tirage Git puisse se terminer. Avec cette extension, vous pouvez résoudre ces conflits sur le web dans le cadre de la fusion des demandes de tirage au lieu de procéder à la fusion et à la résolution des conflits dans un clone local.

Azure DevOps CLI prend en charge le retour des résultats de la requête en JSON, JSONC, YAML, YAMLC, table, TSV et plus encore. Vous pouvez configurer votre préférence à l’aide de la commande configure.

Marche à suivre

Important

Vous devez créer le projet dans le premier parcours d’apprentissage : Décrire l’utilisation locale de Git.

Une fois que vous avez cloné la branche primaire dans un dépôt local, créez une branche de fonctionnalité, myFeature-1 :

monAppliWeb
```
git checkout -b feature/myFeature-1
```
Output:

Switched to a new branch 'feature/myFeature-1'.
Exécutez la commande Git branch pour voir toutes les branches. La branche qui s’affiche avec un astérisque est la branche « actuellement extraite » :

monAppliWeb
```
git branch
```
Output:

feature/myFeature-1

main
Apportez une modification au fichier Program.cs dans la branche feature/myFeature-1 :

monAppliWeb
```
notepad Program.cs
```
Indexez vos modifications et commitez en local, puis publiez votre branche sur le dépôt distant :

monAppliWeb
```
git status
```
Output:

On branch feature/myFeature-1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Program.cs.

monAppliWeb
```
git add .
git commit -m "Feature 1 added to Program.cs"
```
Output:

[feature/myFeature-1 70f67b2] feature 1 added to program.cs 1 file changed, 1 insertion(+).

monAppliWeb
```
git push -u origin feature/myFeature-1
```
Output:

Compression Delta utilisant jusqu’à 8 threads. Compression d’objets : 100 % (3/3), effectué. Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Analyzing objects... (3/3) (10 ms) remote: Storing packfile... done (44 ms) remote: Storing index... done (62 ms) To https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

Le dépôt distant affiche l’historique des modifications :
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 demande de tirage (avec Azure DevOps CLI) pour réviser 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 commutateur --deletesource-branch peut être utilisé pour supprimer la branche une fois la demande de tirage terminée. Vous pouvez aussi utiliser --auto-complete pour terminer automatiquement lorsque toutes les stratégies sont passées et que la branche source peut être fusionnée dans la branche cible.

Notes

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

L’équipe révise conjointement les modifications du code et approuve la demande de tirage :

La branche primaire est prête pour publication. L’équipe étiquette la branche primaire avec le numéro de publication :
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 :

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

Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

monAppliWeb
```
git checkout feature/myFeature-2
```
Output:

Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

Modifiez Program.cs en changeant la même ligne de commentaire dans le code changée dans feature-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();

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 investiguer, créez une branche fof avec l’étiquette release_feature1 :

monAppliWeb
```
git checkout -b fof/bug-1 release_feature1
```
Output:

Switched to a new branch, 'fof/bug-1'.

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 commitez les modifications localement, puis poussez les modifications vers le dépôt distant :

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

To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.
Tout de suite après le déploiement des modifications en production, étiquetez la branche fof_bug-1 avec l’étiquette release_bug-1, puis lancez une demande de tirage pour fusionner les modifications de fof/bug-1 dans la branche primaire :
```
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 demande de tirage, 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 résolu, révisons la demande de tirage de feature-2.

La page branches indique clairement que la branche feature/myFeature-2 est en avance d’une modification et en retard de deux par rapport à la branche primaire :

Si vous avez essayé d’approuver la demande de tirage, vous avez vu un message d’erreur s’afficher vous informant d’un conflit de fusion :
L’extension de résolution de conflits Git Pull Request Merge Conflict permet de résoudre les conflits de fusion directement dans le navigateur. Accédez à l’onglet Conflicts et cliquez sur Program.cs pour résoudre les conflits de fusion :

L’interface utilisateur vous permet de prendre la source et la cible, d’ajouter des modifications personnalisées, de réviser et de soumettre la fusion. Une fois les modifications fusionnées, la demande de tirage est terminée.

À ce stade, vous pouvez créer une branche de mise en production basée sur le correctif de bogue critique implémenté dans la branche fof/bug-1 et fusionné dans un master. Utilisez la commande de basculement sur une branche Git pour créer une branche de mise en production dédiée à partir de la branche de master.

git checkout -b release/v1.1 main

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

Alors que des jalons significatifs sont atteints pendant le processus de mise en production, la balise effectue une mise en production dans la branche de mise en production en utilisant des balises 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 demandes de tirage 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 branches dans le portail web facilite l’identification des branches en avance par rapport à la branche primaire. 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.

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

Préparation

Marche à suivre

Fonctionnement

Commentaires