Qu’est-ce qu’Azure Pipelines ?
Microsoft Azure Pipelines est un service cloud que vous pouvez utiliser pour générer, tester et déployer automatiquement votre projet de code. Vous pouvez également le mettre à la disposition d’autres utilisateurs et il fonctionne avec quasiment n’importe quel langage ou type de projet.
Mara est impatiente de répliquer le processus de génération de l’équipe sur Azure Pipelines. Amita, en charge des tests, a enfin du temps libre et souhaite rattraper son retard. Mara décide que le moment est venu de lui faire part de son plan : configurer un pipeline de build automatisé pour le site web Space Game en utilisant Azure Pipelines.
Amita, après avoir écouté Mara, semble hésitante. Mais comme l’idée de Mara consiste à répliquer le processus de build, sans le remplacer, elle se montre également curieuse. Elle sait que le processus de génération pourrait faire l’objet de quelques améliorations.
Amita : L’exercice a l’air intéressant, mais vous cherchez sans doute à prouver quelque chose en rapport avec DevOps !
Mara : Vous me connaissez déjà très bien !
Amita : À quelles améliorations vous attendez-vous, compte tenu que vous allez faire ce que nous faisons déjà ?
Mara : Je pense que le simple fait de passer à Azure Pipelines va apporter beaucoup d’avantages. Souvenez-vous, Azure Pipelines est un service cloud. Nous pouvons l’utiliser pour générer et tester automatiquement du code. Et ce service est également disponible pour tous les autres. Il fonctionne avec n’importe quel langage ou type de projet.
Notre serveur de build a des problèmes, et le garder à jour est même difficile. Comme les serveurs de builds fournis par le service Azure Pipelines sont hébergés et gérés par Microsoft, ils ont toujours les derniers correctifs et les dernières mises à jour de sécurité. Nous n’aurons plus à nous soucier de la maintenance des serveurs de builds.
De plus, nous avons toutes sortes de scripts écrits par différentes personnes. Nous ne comprenons même pas comment certains d’entre eux fonctionnent. Azure Pipelines est fourni avec un catalogue de tâches. Une tâche est une procédure ou un script packagé qui fait abstraction d’un ensemble d’entrées. Je vais essayer de mapper nos scripts de build à ces tâches. Au minimum, nous pouvons standardiser notre façon de faire afin d’augmenter le niveau d’automatisation.
De plus, Azure Pipelines fonctionne avec de nombreux langages et types d’application différents. Si nous voulons partir dans ces directions, nous n’aurons pas à changer d’outils.
Amita : Je suis peut-être trop personnelle, mais en quoi cela me concerne-t-il ? Un de mes gros problèmes est que je ne sais jamais quand une build est prête à être testée. Parfois, quelqu’un pense à mettre à jour la feuille de calcul, mais le plus souvent, personne n’y pense. C’est comme si j’étais la dernière personne à être informée.
Mara : C’est un problème que nous pouvons facilement résoudre. Nous pouvons configurer le pipeline pour qu’il vous avertisse automatiquement, par e-mail ou tout autre type de notification, quand une build est prête. Vous n’aurez plus jamais à attendre que quelqu’un vous le signale.
Amita : OK, donc votre objectif immédiat est de générer l’application et de m’avertir quand elle est prête ?
Mara : Oui ! Bien sûr, j’ai aussi de plus grandes ambitions. Je sais que vous allez tous adorer cette première étape, alors je vais m’appuyer dessus pour nous donner la possibilité d’une vraie intégration continue.
Amita : Pouvez-vous m’expliquer en 5 minutes ce qu’est l’intégration continue (CI) ?
Mara : Laissez-moi vous faire un dessin.
Mara s’approche du tableau blanc et dessine le pipeline.
Mara : Voici mon pipeline d’intégration continue. L’intégration continue est le processus d’automatisation de la génération et du test du code chaque fois qu’un membre d’équipe commite des modifications dans la gestion de versions. Je sais que nous ne faisons pas encore de tests automatisés, mais envisageons-le.
Un pipeline définit le processus d’intégration continue pour l’application. Il se compose d’étapes appelées tâches
. Vous pouvez l’envisager comme un script qui définit la manière d’exécuter tes étapes de génération, de test et de déploiement. Je vais essayer de mapper nos scripts à des tâches.
Le pipeline s’exécute quand vous envoyez des modifications de code 
. Vous pouvez configurer le pipeline pour qu’il s’exécute automatiquement, ou l’exécuter manuellement. Vous connectez votre pipeline à un dépôt source comme GitHub, Bitbucket ou Subversion. Une de nos tâches pour ce sprint consiste à démarrer en utilisant GitHub. Nous utiliserons donc GitHub pour ce projet.
Un agent de build
génère ou déploie le code. Quand votre build ou déploiement s’exécute, le système démarre un ou plusieurs travaux. Un agent est un logiciel installable qui exécute un seul travail de build ou de déploiement à la fois. Puisque nous utilisons Azure Pipelines, nous pouvons utiliser un agent hébergé par Microsoft. Avec les agents hébergés par Microsoft, la maintenance et les mises à niveau sont effectuées pour nous. Chaque fois que nous exécutons un pipeline, nous obtenons une machine virtuelle actualisée. Vous pouvez choisir entre plusieurs images de machine virtuelle, notamment Ubuntu 22.04, qui est celle que nous utilisons.
Le produit final du pipeline est un artefact de build
. Un artefact peut être vu comme la plus petite unité compilée dont nous avons besoin pour tester ou déployer l’application. Par exemple, un artefact peut être :
- Une application Java ou .NET packagée dans un fichier .jar ou .zip.
- Une bibliothèque C++ ou JavaScript
- Une image de machine virtuelle, cloud ou Docker
Et c’est terminé ! Je sais que nous pouvons faire comme ça.
Amita : Cela paraît très bien. Dites-moi ce que vous devez faire pour tout mettre en place et combien de temps cela va prendre. Vous pouvez nous faire à tous une démonstration.
Mara : Oui, je le ferai !
Gérer les agents de build
Maintenant que l’équipe et vous-même êtes familiarisés avec Azure Pipelines, parlons un peu plus des agents de build. Un agent de build est un logiciel installable qui exécute un seul travail de génération ou de déploiement à la fois. Pour générer votre code ou déployer votre application, vous avez besoin d’un agent au minimum. Au fur et à mesure que vous ajouterez du code et des utilisateurs, vous aurez peut-être besoin de plusieurs agents. Il existe deux catégories principales d’agents.
Les agents hébergés par Microsoft sont des agents gérés par Microsoft, et la maintenance et les mises à niveau sont prises en charge pour vous. Chaque fois que vous exécutez un pipeline, vous obtenez un nouvel agent pour chaque travail dans le pipeline. Dans ce module, lorsque vous choisissez Environnement de développement local à l’aide d’un agent hébergé par Microsoft, vous exécutez votre pipeline sur un agent hébergé par Microsoft. Pour exécuter des pipelines sur un agent hébergé par Microsoft, votre organisation doit avoir au moins un travail parallèle hébergé par Microsoft. Vérifiez le nombre de travaux parallèles hébergés par Microsoft pour vous assurer que vous disposez d’au moins un travail parallèle hébergé par Microsoft. Si votre nombre de travaux parallèles hébergés par Microsoft est égal à zéro (les nouvelles organisations Azure DevOps n’ont généralement aucun travail parallèle), vous pouvez demander un octroi gratuit. Le processus d’approbation de l’octroi gratuit prend généralement deux à trois jours ouvrables.
Les agents auto-hébergés sont des agents que vous gérez. Vous configurez les machines virtuelles ou les conteneurs en installant le logiciel de l’agent et les outils souhaités, puis vous inscrivez les agents auprès d’Azure DevOps. Dans ce module, lorsque vous choisissez Environnement de développement GitHub Codespaces à l’aide d’un agent auto-hébergé, vous utilisez un agent auto-hébergé s’exécutant dans votre conteneur GitHub Codespaces. L’auto-hébergement de l’agent sur un conteneur GitHub Codespaces n’est pas un scénario de production classique, mais cela fournit un environnement pour suivre ce module de formation.