Le langage YAML permet de configurer des pipelines de CI/CD sur Microsoft Azure DevOps sous forme de code. Découvrez pourquoi et comment opter pour cette approche, et quels sont ses avantages par rapport à l'éditeur classique !
En ajoutant les pipelines à son offre de services cloud Azure DevOps, Microsoft a permis d’ajouter les pratiques de CI/CD (intégration et livraison continue) au processus de développement.
Toutefois, il existe deux façons de créer un pipeline Azure Devops. La première méthode consiste à utiliser les outils « classiques », la seconde à exploiter la nouvelle fonctionnalité de pipeline YAML multi-étapes lancée en 2020.
Qu'est-ce que les pipelines classiques ?
Les pipelines classiques permettent l’intégration continue (CI) via les pipelines de build Azure DevOps. Un pipeline de build s’exécute avant qu’un développe intègre les changements de code à la base de code.
Le pipeline peut exécuter une tâche de build, lancer des tests d’unités, ou encore exécuter des analyses de code statique. Il peut ensuite accepter ou rejeter les nouveaux changements selon les résultats de ces tâches.
La livraison continue (CD) s’effectue par le biais des pipelines de relaxe Azure DevOps. Après que le pipeline de build ait produit un artefact, un pipeline de relaxe publie l’artefact sur divers environnements pour le testing fonctionnel manuel, le test d’expérience utilisateur et l’assurance qualité.
Quand les testeurs ont rigoureusement testé les artefacts déployés, le pipeline de relaxe peut pousser les artefacts vers l’environnement de production.
Toutefois, ces pipelines CI/CD classiques comportent des inconvénients. Tout d’abord, les outils de création de pipelines de build et de relaxe n’offrent pas d’expérience unifiée.
Les pipelines CI fournissent une interface utilisateur graphique intuitive pour créer et visualiser les étapes d’intégration, et permettent aussi de définir les mêmes étapes en YAML.
Les pipelines de relaxe proposent aussi une interface graphique pour créer et visualiser les étapes de pipeline, mais le problème est que cette interface est différente de celle du pipeline de build et ne permet pas les définitions YAML.
Qu'est-ce que les pipelines multi-étapes ?
Afin de corriger ce problème, Microsoft a créé les pipelines multi-étapes. Disponibles depuis 2020, ces pipelines permettent à un ingénieur de définir pipeline de build, de relaxe ou hybride sous forme de document YAML unique.
Outre l’avantage d’une expérience de développement unifiée, YAML offre de nombreux bénéfices par rapport aux pipelines classiques. Et ce, aussi bien pour les builds que les relaxes.
Les définitions YAML sont directement validées sur le contrôle de version, permettant de profiter des mêmes avantages que ceux apportés aux développeurs par le contrôle de version depuis plusieurs décennies.
Qu'est-ce que YAML ?
YAML est un langage de sérialisation de données, souvent utilisé pour l’écriture de fichiers de configuration. Son nom est un acronyme pour « Yet Another Markup Language ».
Ce langage de programmation est populaire, car facile à comprendre et lisible par l’humain. Il peut aussi être utilisé conjointement à d’autres langages. Sa flexibilité et son accessibilité sont ses principaux points forts.
Le YAML reprend des caractéristiques de divers langages comme Perl, C, XML et HTML. Il utilise aussi l’indentation dans le style de Python pour indiquer le nesting. Les caractères de tabulation ne sont pas autorisés, et on utilise à la place des espaces vierges.
Il n’y a pas de symboles de format habituels tels que les parenthèses ou les guillemets. Les fichiers YAML portent l’extension .yml ou .yaml, et leur structure est une carte ou une liste.
Les cartes permettent d’associer des paires de clés et de valeurs. Chaque clé doit être unique, mais l’ordre n’a pas d’importance. Une carte YAML doit être résolue avant de pouvoir être fermée, et une nouvelle carte est créée en augmentant le niveau d’indentation ou en résolvant la précédente carte pour en commencer une adjacente.
Une liste inclut des valeurs dans un ordre spécifique et peut contenir n’importe quelle quantité d’éléments requis. Une séquence de liste commence avec un dash (-) et un espace, et l’indentation la sépare de son parent. On peut la comparer à une liste Python ou un tableau Bash ou Perl. Une liste peut être intégrée à une carte.
Le langage YAML exploite aussi des scalaires : des données arbitraires encodées en Unicode pouvant être utilisées en tant que valeurs telles que des strings, des nombres entiers ou encore des dates.
Outre l’écriture de fichiers de configuration plus simples et compréhensibles qu’en JSON, YAML est couramment utilisé par les Playbooks Ansible pour l’orchestration de processus IT et pour les déploiements Kubernetes.
Les avantages des pipelines YAML
L’un des principaux avantages des pipelines YAML est la possibilité de passer en revue chaque changement apporté au pipeline depuis sa création, grâce à l’historique offert par le système de gestion de version.
Il est également possible de comparer une définition dysfonctionnelle avec la dernière définition fonctionnelle connue. Ceci permet de résoudre les problèmes dans le build plus efficacement, et de réduire le temps de récupération.
De la même manière, il peut être utile de voir qui a déposé le code buggé causant l’échec et qui a approuvé la requête pull. Ceci permet de convoquer les membres d’équipe pour chercher avec eux la meilleure façon de corriger le problème tout en s’assurant d’atteindre les objectifs initiaux.
Autre point fort : les éléments de travail aident à savoir pourquoi les changements ont été effectués. En attachant une tâche utilisateur à chaque contribution au pipeline, il n’est plus nécessaire de se souvenir du raisonnement ayant mené à une modification spécifique.
Par ailleurs, si un changement de pipeline provoque des soucis comme une mauvaise configuration d’environnement d’assurance qualité, il suffit d’effectuer un retour vers la dernière version fonctionnelle connue. Votre environnement QA sera ainsi restauré en quelques minutes.
Le véritable avantage du YAML est de permettre aux développeurs d’avoir l’application, l’infrastructure, mais aussi les pipelines de build et de relaxe sous même de code dans un même dépôt de gestion de version. Ceci offre un snapshot complet du système, pour n’importe quelle période antérieure.
En consultant une ancienne version du dépôt, il est possible de cloner très facilement l’environnement, d’exécuter les mêmes pipelines et de déployer le code exactement comme il l’était. C’est une fonctionnalité très utile.
En outre, le partage ou la duplication d’un pipeline s’effectue avec un simple copier-coller. Il s’agit d’un simple texte, qui peut même être envoyé par email à un collègue en cas de besoin de réutilisation.
Les pipelines CI/CD sont larges et complexes, et des modifications apportées à un même fichier YAML par de multiples ingénieurs peuvent causer un conflit. Heureusement, les plateformes de gestion de version résolvent ce problème en fournissant des outils intuitifs pour fusionner des changements conflictuels. Les définitions YAML permettent donc à plusieurs ingénieurs de travailler simultanément sur le même fichier.
Tout comme pour le code d’application, l’évaluation par les pairs est importante pour les pipelines. Grâce à la capacité de soumettre une requête pull avant d’apporter de nouveaux changements, les membres d’équipe peuvent s’assurer que ces modifications auront l’effet escompté.
Enfin, le branching ou ramification permet de créer une nouvelle branche pour essayer des idées atypiques. Il est possible d’enclencher une exécution de pipeline depuis cette branche, et de la supprimer si l’idée s’avère infructueuse.
L’introduction de définitions de pipelines entièrement basée sur le texte et pouvant être déposée sur la gestion de version apporte des avantages par rapport aux définitions classiques basées sur une interface graphique. C’est tout particulièrement le cas pour les grandes organisations, qui ont tout intérêt à penser au YAML pour leur prochaine implémentation de pipeline Azure DevOps…
Pipelines classiques VS YAML : le comparatif
Les pipelines classiques sont configurés à l’aide d’une interface utilisateur, en choisissant parmi les options proposées. Ceci concerne aussi bien les pipelines de build que les pipelines de relaxe.
De leur côté, les pipelines YAML sont configurés en utilisant du code sur un fichier YAML. L’assistant de tâche Azure DevOps peut vous aider à trouver les tâches requises et à les ajouter au fichier YAML.
Il est tout à fait possible de construire et déployer une application à l’aide de pipelines classiques. Toutefois, les pipelines YAML permettent un déploiement dans différents environnements.
Les pipelines YAML simplifient la collaboration, et facilitent les changements de multiples valeurs simultanément. Il est par exemple possible d’utiliser l’outil de recherche d’un IDE pour trouver et remplacer plusieurs occurrences d’une même valeur.
Un outil de gestion de version comme git permet aussi de comparer très facilement les changements. Le pipeline étant dans un fichier YAML dans le dépôt, il est possible de restaurer une ancienne version du pipeline en même temps qu’une ancienne version du dépôt de code.
Le YAML est devenu l’option par défaut pour construire des pipelines sur Azure DevOps, et la plupart des outils CI/CD sont compatibles avec ce langage. En outre, les jobs de conteneurs sont exclusifs aux pipelines YAML.
En revanche, cette approche peut nécessiter plus de temps et d’efforts que les pipelines classiques. Notons tout de même que l’assistant de tâches est d’un précieux secours, et qu’il est possible d’exporter un pipeline classique existant en tant que YAML. Plusieurs ajustements sont toutefois requis.
Autre point faible : certaines configurations ne peuvent être modifiées dans le fichier. Il est nécessaire d’effectuer les changements en utilisant l’interface utilisateur, et l’option peut être difficile à trouver la première fois.
Enfin, certaines fonctionnalités CD disponibles pour les pipelines de relaxe ne sont pas encore disponibles pour les pipelines YAML. Toutefois, Microsoft ajoute de nouvelles fonctionnalités progressivement.
De leur côté, les pipelines classiques sont intuitifs et simples d’utilisation. Il est également très facile de découvrir les différentes options en explorant l’interface avec sa souris, sans même avoir à consulter la documentation. En revanche, ce n’est plus l’option par défaut pour construire des pipelines pour Azure DevOps.
En conclusion, le choix entre pipeline classique ou pipeline YAML dépend de vos besoins. Prenons soin d’analyser la façon dont les pipelines seront enclenchés et sur quels environnements l’application sera déployée, comment la stratégie de ramification fonctionne et comment elle affecte le flux de déploiement.
Vous devez aussi savoir si vous avez besoin d’un seul pipeline CI/CD, ou de deux pipelines séparés. Assurez-vous également de connaître votre flux de travail et vos besoins.
Comment créer un pipeline CI/CD en YAML sur Azure DevOps ?
Pour créer un pipeline CI/CD en YAML sur Azure DevOps, commencez tout d’abord par vous connecter à un compte Microsoft Azure pour utiliser Azure DevOps et Azure Pipelines.
Créez un Projet d’Equipe, basé sur Basic, Agile, Scrum ou CMMI, puis créez un pipeline de build. Vous devez fournir la source du code, et les identifiants permettant de s’y connecter. Il peut s’agir par exemple d’un dépôt GitHub.
Après avoir ajouté le dépôt, vous recevez des suggestions de templates basé sur différents langages comme Java ou .Net. Choisissez un template, sauvegardez le fichier YAML (.yml) et activez le build. Il est possible d’ajouter autant d’étapes et de jobs que nécessaire au pipeline.
L’étape suivante est d’ajouter une définition de relaxe et de déployer l’application web sur Azure Web App Service. Dans l’onglet « Relaxes », sélectionnez « Nouveau pipeline » et choisissez le template pour de Déploiement App Service.
Vous devez avoir un Web App Service sur Azure pour y déployer l’application. Dans le cas contraire, créez-en un nouveau depuis le Portail Azure.
Pour compléter le déploiement, il est impératif de publier les artefacts créés dans le build. Ceci requiert d’ajouter une tâche au fichier YAML pour publier les artefacts à la fin.
Éditez la définition du build, rendez-vous à la fin du fichier YAML, cherchez l’option de publication d’artefacts de build et cliquez sur « Ajouter ». Sauvegardez le build et exécutez-le, pour que les artefacts puissent être publiés et utilisés pour la relaxe.
Il est nécessaire de fournir le build d’où proviennent les artefacts pour toute définition de relaxe. Vous devez donc configurer la tâche pour Azure App Service dans la définition de relaxe, et autoriser la tâche à utiliser le service créé avec votre compte Azure. Sauvegardez la définition de relaxe, et créez une relaxe. Une fois le déploiement complété, vous devriez voir l’application déployée.
Par la suite, éditez la définition du build pour activer l’interrupteur d’intégration continue et l’interrupteur de déploiement continu. Il suffit de cliquer sur le bouton d’ellipse et de sélectionner les interrupteurs. Activez et sauvegardez les interrupteurs pour la définition de relaxe, et changez le code dans GitHub pour être sûr que les deux interrupteurs fonctionnent comme prévu. Sauvegardez le pipeline.
Vous pouvez ensuite customiser le pipeline de build en ajoutant des tâches ou en modifiant les tâches existantes au besoin. Il est notamment possible d’ajouter des variables et des jobs.
Comment devenir expert Azure DevOps ?
La construction de pipelines en YAML n’est que l’une des nombreuses subtilités d’Azure DevOps. Pour apprendre à maîtriser cette plateforme, vous pouvez vous tourner vers DataScientest.
Notre formation Data Engineer permet de découvrir les techniques et outils d’ingénierie des données, dont la programmation en Python, le CI/CD, les bases de données, le Big Data, le Machine Learning ou encore l’automatisation et le déploiement.
Nous proposons aussi une formation certifiante pour le cloud Microsoft Azure, permettant d’obtenir les certifications AZ-104 Microsoft Azure Administrator et DP-203 Engineering on Microsoft. Ces deux parcours se complètent en seulement cinq jours.
Toutes nos formations s’effectuent intégralement à distance, en mode BootCamp intensif ou Formation Continue. Notre organisme est reconnu par l’Etat, et éligible au Compte Personnel de Formation (CPF) pour le financement. Découvrez DataScientest !
Vous savez tout sur les pipelines CI/CD en YAML sur Azure DevOps. Pour plus d’informations sur le même sujet, découvrez notre dossier complet sur DevOps et notre dossier sur Microsoft Azure.
