Exercice – Ajouter un badge de build

Les membres de l'équipe doivent connaître l'état de la build. Un moyen simple de déterminer rapidement l’état de la build consiste à ajouter un badge de build au fichier README.md sur GitHub. Rejoignons l’équipe pour voir comment s’effectue cette opération.

Assis à son bureau, Andy consulte ses e-mails. Il répond au troisième e-mail lié à l’état de la construction du site web du Space Game.

Andy: Il doit y avoir un moyen d’automatiser un message d’état. Nous disposons du pipeline. Nous devrions donc pouvoir placer un état quelque part. Peut-être que Mara sait comment faire.

Andy retrouve Mara dans la salle de pause, qui discute avec Amita.

Andy: Bonjour, Amita. Est-ce que je peux vous emprunter Mara quelques secondes ?

Amita: Je dois aller à une réunion de toute façon. Je vous la confie.

Mara: Salut Andy. Qu’est-ce qu’il y a ?

Andy: J’aime vraiment les modifications que nous avons apportées à notre pipeline de build à l’aide d’Azure Pipelines, et Git est un excellent système de contrôle de version. Y a-t-il un moyen de permettre aux autres personnes de connaître l'état de la build ?

Mara: Oui, en fait. Nous pouvons utiliser un badge de build.

Qu’est-ce qu’un badge de build ?

Un badge fait partie de Microsoft Azure Pipelines. Il contient des méthodes que vous pouvez utiliser pour ajouter une image SVG qui affiche l’état de la build sur votre référentiel GitHub.

La plupart des dépôts GitHub incluent un fichier nommé README.md, qui est un fichier Markdown qui inclut des détails et une documentation essentiels sur votre projet. GitHub affiche ce fichier dans la page d’accueil de votre projet.

Voici un exemple de badge de build :

Dans le cadre de cet exercice, vous rendez votre badge de build visible pour tout le monde. Ce n'est peut-être pas une bonne idée pour vos projets privés, car les informations relatives à la build seront rendues publiques.

Pour vérifier que votre badge de build est visible :

1. Dans Azure DevOps, accédez à votre organisation.

2. Sélectionnez Paramètres de l’organisation dans le coin inférieur.

3. Sous Pipelines, sélectionnez Paramètres.

4. Désactivez l’accès anonyme aux badges.

   

Vous avez besoin d’apporter une modification similaire à votre projet :

1. Accédez à votre projet.
2. Accédez aux paramètres du projet dans le coin inférieur.
3. Sous Pipelines, sélectionnez Paramètres.
4. Désactivez l’accès anonyme aux badges.

Ajouter le badge de build

Jusqu’à présent, vous avez créé des branches Git localement pour apporter des modifications au projet Space Game . Vous pouvez également proposer des modifications directement par le biais de GitHub. Dans cette section, vous allez effectuer cela pour configurer votre badge d’état.

1. Dans Azure DevOps, dans le volet gauche, sélectionnez Pipelines, puis votre pipeline.

2. Sélectionnez les points de suspension (...) dans le coin supérieur droit, puis Badge d'état.

   

3. Sous Exemple Markdown, sélectionnez le bouton Copier pour copier le code Markdown dans le Presse-papiers.

4. Dans GitHub, accédez à votre projet.

5. Vérifiez que vous êtes sur la branche main. Dans la zone fichiers, ouvrez le fichier README.md .

6. Sélectionnez Modifier ce fichier (icône de crayon) pour ouvrir le fichier dans l’éditeur.

7. En haut de la page, ajoutez une ligne vide, puis collez le contenu du Presse-papiers.

8. Sélectionnez l’onglet Aperçu pour afficher vos modifications proposées.

   GitHub affiche le fichier Markdown et vous montre le badge de build.

   

Commiter vos changements dans main

Dans cette section, vous commitez vos modifications dans la branche main sur GitHub.

1. Sélectionnez Valider les modifications.

2. Dans la zone Message de commit, spécifiez un message de validation, tel que « Ajouter un badge de compilation ».

   

3. Laissez l'option Confirmer directement sur la branche main sélectionnée, puis sélectionnez Valider les modifications pour valider vos modifications sur la branche main.

   Votre badge s’affiche sur la page README.md .

   

   Ce processus est une méthode plus simple pour fusionner du code dans GitHub. Au lieu de valider directement, vous auriez pu créer une demande de tirage avec vos modifications pour que d’autres personnes les passent en revue.

   Dans la pratique, vous passerez à la branche main et tirerez (pull) les dernières modifications de GitHub la prochaine fois que vous aurez besoin d'ajouter une caractéristique ou de corriger un bogue.

Andy: Mara, vous venez d’apporter un changement directement à main. Pourquoi ne pas utiliser le flux que vous m’avez appris ? Vous savez, celui avec les branches de fonctionnalité.

Mara: On aurait pu le faire. Mais parfois, quand les utilisateurs changent uniquement le fichier README ou d’autres fichiers de documentation, ils effectuent un commit dans main à ce moment-là. De plus, vous et moi avons pu vérifier le travail ensemble avant de fusionner la modification.

Mais cela soulève un point intéressant. Si nous pouvons commiter dans main quand bon nous semble, des problèmes affectant le code pourraient se glisser dans notre branche main.

Andy: Je voulais vous parler de ça.

Andy et Mara poursuivent cette conversation tout en rejoignant leurs bureaux.