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 concernant l'état de la build pour le site web Space Game.
Andy : Il doit exister 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 : Salut, Amita. Est-ce que je peux vous emprunter Mara quelques secondes ?
Amita : Je dois me rendre à 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 avec Azure Pipelines, et Git est un excellent système de gestion de versions. Y a-t-il un moyen de permettre aux autres personnes de connaître l'état de la build ?
Mara : Oui, c’est possible. 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 dépôt GitHub.
La plupart des dépôts GitHub incluent un fichier nommé README.md, qui est un fichier Markdown contenant 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 :
Dans Azure DevOps, accédez à votre organisation.
Sélectionnez Paramètres de l’organisation dans le coin inférieur.
Sous Pipelines, sélectionnez Paramètres.
Désactivez Désactiver l’accès anonyme aux badges.
Vous avez besoin d’apporter une modification similaire à votre projet :
- Accédez à votre projet.
- Accédez à Paramètres du projet en bas.
- Sous Pipelines, sélectionnez Paramètres.
- Désactivez Désactiver 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.
Dans Azure DevOps, dans le volet gauche, sélectionnez Pipelines, puis sélectionnez votre pipeline.
Sélectionnez les points de suspension (...) dans le coin supérieur droit, puis Badge d'état.
Sous Exemple de Markdown, sélectionnez le bouton Copier pour copier le code Markdown dans le Presse-papiers.
Dans GitHub, accédez à votre projet.
Vérifiez que vous êtes sur la branche
main
. Dans la zone des fichiers, ouvrez le fichier README.md.Sélectionnez Modifier ce fichier (icône de crayon) pour ouvrir le fichier dans l'éditeur.
En haut de la page, ajoutez une ligne vide, puis collez le contenu du Presse-papiers.
Sélectionnez l’onglet Prévisualiser pour voir les changements que vous proposez.
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.
Sélectionnez Valider les modifications.
Dans la zone de message de validation, spécifiez un message de validation, comme « Ajouter un badge de build. »
Ne décochez pas l'option Valider directement dans la
main
branche, puis sélectionnez Valider les modifications pour valider vos modifications dans la branchemain
.Votre badge s’affiche dans 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 directement une modification à main
. Pourquoi ne pas utiliser le flux que vous m’avez appris ? Vous savez, celui avec les branches de fonctionnalité.
Mara : Nous aurions 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 : C’est là un sujet dont je voulais vous parler.
Andy et Mara poursuivent cette conversation tout en rejoignant leurs bureaux.