On ne va pas se mentir, quand une technologie fonctionne, pourquoi se compliquer la vie à en utiliser une autre ?

C’est à peu de chose près la question que l’on se pose quand on découvre pour la première fois la définition de builds avec YAML. Azure DevOps a un designer de builds très agréable et beaucoup moins austères que YAML. On peut donc se demander pourquoi Microsoft veut nous faire abandonner les builds classiques au profit de YAML.

Mais YAML a de nombreux avantages. Certains avantages rappellent des possibilités perdues lors de la disparition des builds XAML :

Les fichiers

La build est définie dans un fichier. Ceci la rend donc facile à copier, importer, exporter.

Templates

Une définition de build peut être découpée en plusieurs fichiers. Ce sont les templates. Ces templates ne sont pas figés. Ils acceptent que notre définition de build leur passe des paramètres.

Pour faire simple, on peut utiliser un Template comme une méthode.

Les templates peuvent être réutilisés à volonté. Dans plusieurs builds, et plusieurs fois dans une même build.

Personnellement, j’utilise beaucoup les templates pour définir une structure fiable que j’importe dans chaque projet.

Stockage et Branches

Une définition de build YAML doit être stockée dans votre repository (en général, on créé un dossier Builds ou Pipelines). Le gros avantage de cette solution consiste dans le fait qu’Azure Pipeline utilise le fichier YAML présent dans la branche que l’on peut compiler/tester/déployer.

Lors du développement, on peut donc inclure des spécificités à sa build sans induire d’effet de bord sur les builds des autres branches. Finis les problèmes de builds en cascade du fait d’un développeur qui fait des tests avec des outils qui n’ont pas encore été validés.

Triggers

Les triggers sont un autre avantage intéressant qui découle du stockage des fichier YAML dans le repository. Contrairement aux builds classiques, les triggers ne sont pas centralisés. Les triggers peuvent dont être crées aussi rapidement, que les branches.

La mise en place de builds d’intégration continue est donc plus rapide.

Le merge des définitions de builds se faisant lors du merge de branches, on peut très rapidement mettre à jour les triggers. Ceci est aussi valable pour la suppression de triggers (fini les triggers sur des branches disparues).

Multi staging

Actuellement, cette fonctionnalité est toujours en version preview.

À l’avenir, il sera possible de définir dans son YAML l’ensemble des opérations que l’on confie actuellement à Release Manager. S’ajoute à cela une meilleure visibilité des environnements et des historiques de déploiement (très pratique quand on a de nombreuses builds qui conduisent à des déploiements sur le même environnement).

Ces informations étant disponibles dans une section dédiée, il n’est pas utile d’explorer ses pipelines de déploiement pour trouver la version actuellement installée sur un serveur.

Conclusion

Si comme moi, vous avez beaucoup utilisé les builds XAML, vous apprécierez les fonctionnalités retrouvées. On a perdu Workflow Foundation, mais on a retrouvé ses avantages. YAML apporte en plus de très bonnes choses, dont il devient très vite difficile de se passer. Ceci avec une souplesse inégalée.