Création d’un pipeline d’intégration continue avec Azure Pipelines

L’intégration continue (CI) consiste à fusionner fréquemment les modifications de code dans une branche partagée, chaque fusion déclenchant automatiquement une compilation et une série de tests. L’objectif est de détecter rapidement les échecs d’intégration, avant qu’ils ne s’aggravent et ne deviennent des problèmes importants et difficiles à corriger. Une bonne Pipeline CI compile le code, exécute les tests unitaires, mesure la couverture du code, effectue une analyse statique et produit un artefact déployable en quelques minutes. Azure Pipelines fournit le moteur d’automatisation nécessaire à cette pratique.

Les Pipelines CI Azure Pipelines sont définies dans un fichier azure-pipelines.yml situé à la racine de votre référentiel. Le fichier YAML spécifie les déclencheurs (quand exécuter la Pipeline), un pool (le type d’Agent à utiliser) et une hiérarchie composée de stages, de jobs et d’étapes. Par défaut, les stages s’exécutent séquentiellement. Les jobs d’un même stage s’exécutent par défaut en parallèle. Les étapes d’un job s’exécutent séquentiellement. Cette structure vous donne un contrôle précis sur le flux d’exécution de la Pipeline.

Azure Pipelines prend en charge plusieurs types de déclencheurs. Les déclencheurs de branche exécutent la Pipeline lorsqu’un code est envoyé vers les branches spécifiées. Les déclencheurs de demandes d’extraction (déclencheurs PR) s’exécutent lorsqu’une PR est ouverte ou mise à jour vers les branches cibles, ce qui est essentiel pour valider le code avant sa fusion. Les déclencheurs planifiés s’exécutent à une heure fixe (par exemple, pour les compilations Nightly). Les déclencheurs de Pipeline enchaînent les Pipelines. Spécifiez trigger: none pour désactiver les exécutions automatiques et n’autoriser que l’exécution manuelle.

Les étapes d’une Pipeline sont soit des scripts (commandes bash ou PowerShell), soit des tâches (unités préconfigurées et paramétrées provenant de la marketplace Azure DevOps). Des tâches comme NodeTool@0, DotNetCoreCLI@2 et Maven@3 encapsulent les opérations de compilation courantes. Utilisez displayName pour chaque étape afin d’obtenir des journaux de Pipeline lisibles. Chaque étape s’exécute dans l’ordre et la Pipeline échoue si une étape se termine avec un code différent de zéro, sauf si vous définissez continueOnError: true.

Après l’exécution des tests, publiez les résultats dans Azure DevOps à l’aide de la tâche PublishTestResults. Azure Pipelines analyse les fichiers de résultats aux formats JUnit, NUnit, XUnit ou VSTest et affiche dans l’interface d’exécution de la Pipeline le nombre de réussites et d’échecs, la durée de l’exécution des tests et les détails de chaque test. L’historique des tests est suivi au fil du temps afin de repérer les tests instables et les régressions. Cette visibilité est essentielle pour suivre la qualité du code dans toute l’équipe.

Publiez les rapports de couverture du code afin qu’Azure Pipelines affiche les pourcentages et les tendances de couverture dans l’interface de la Pipeline. La tâche PublishCodeCoverageResults accepte les rapports aux formats Cobertura ou JaCoCo. Associez cette tâche à des gates de couverture de branche : configurez un seuil minimal de couverture et faites échouer la compilation si la couverture passe en dessous de ce seuil. Les tendances de couverture aident à repérer les ajouts de code qui ne sont pas accompagnés de tests correspondants.

Stockez la configuration de la Pipeline dans des variables définies au niveau de la Pipeline, du stage ou du job dans YAML. Pour les valeurs sensibles (clés d’API, mots de passe), utilisez des variables secrètes : définissez-les dans la bibliothèque de la Pipeline (interface utilisateur) ou dans des groupes de variables, puis référencez-les dans YAML. Les groupes de variables sont des collections réutilisables de variables partagées entre plusieurs Pipelines. Liez un groupe de variables à Azure Key Vault pour synchroniser automatiquement les secrets de Key Vault avec les variables de la Pipeline.

Après une compilation réussie, empaquetez la sortie dans un artefact de Pipeline afin que les stages en aval (comme le déploiement) puissent y accéder. Utilisez PublishPipelineArtifact pour charger les fichiers de l’Agent de compilation vers le stockage d’Artifacts Azure DevOps. Dans un stage ou un job ultérieur, utilisez DownloadPipelineArtifact pour récupérer l’artefact. Cela découple le job de compilation des jobs de déploiement, qui peuvent s’exécuter sur des Agents différents ou dans des stages différents.

Exécutez les tâches indépendantes en parallèle en définissant plusieurs jobs dans un stage. Par exemple, exécutez simultanément les tests unitaires et l’analyse de sécurité plutôt que séquentiellement. Les jobs parallèles nécessitent des minutes de compilation distinctes, mais peuvent réduire considérablement la durée totale de la Pipeline. Utilisez la propriété dependsOn pour obliger un job à attendre la fin d’un ou plusieurs autres jobs avant de démarrer, afin de créer un graphe de dépendances au sein d’un stage.

Liez votre Pipeline CI à une stratégie de branche dans Azure Repos afin qu’elle s’exécute automatiquement comme vérification de validation de compilation sur les demandes d’extraction ciblant main. La fusion est bloquée tant que la Pipeline n’a pas réussi. Combinez plusieurs vérifications : la Pipeline CI doit réussir, au moins deux réviseurs doivent approuver, tous les commentaires doivent être résolus et un élément de travail lié doit exister. Vous créez ainsi une gate de qualité qui rend impossible la fusion de code défectueux dans la branche principale.

Une fois l’exécution d’une Pipeline terminée, examinez les résultats dans le portail Azure DevOps. L’onglet Summary affiche le résultat global (réussite ou échec) ainsi que la durée. L’onglet Tests répertorie tous les résultats de tests et permet de les filtrer selon leur résultat. L’onglet Code Coverage affiche le pourcentage de couverture et met en évidence les lignes non couvertes. Cliquez sur un job pour afficher le journal détaillé de chaque étape. Les Pipelines ayant échoué affichent l’étape défaillante en rouge, avec la sortie complète de l’erreur pour faciliter le diagnostic.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que Azure Pipelines YAML définit des Pipelines CI avec des stages, des jobs et des étapes pour la compilation, les tests et la création d’Artifacts, que les déclencheurs PR et les stratégies de branche appliquent des gates de qualité qui bloquent la fusion de code défectueux et que les tâches PublishTestResults et PublishCodeCoverageResults rendent la qualité des tests visible dans toute l’équipe. Nous allons ensuite découvrir le déploiement continu vers Azure.