Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Quand on m’interroge sur Azure Pipeline, il y a presque toujours une question relative aux extensions ou tâches que j’utilise. Aussi surprenant que cela puisse paraitre, je n’ai pas d’extensions à recommander. Je n’ai pas non plus d’extension que j’installe systématiquement.

Sérieusement ?

Dit comme cela, on peut se demander si j’utilise vraiment le produit.

Oui, j’utilise Azure Pipeline depuis ses toutes premières versions (si on compte aussi les produits qui l’ont précéder). À force de configurer des builds et pipelines de déploiements, je n’ai trouvé qu’une raison d’installer des extensions : s’interfacer avec un produit tièrs.

Le plus souvent, il s’agit de solutions liées à la qualité, la sécurité ou une API custom. Il s’agit donc d’un usage au cas par cas.

Et pour le reste ?

La marketplace Azure DevOps regorge d’extensions dédiées à la consultation, la transformation de fichiers ou encore la manipulation de configuration. Il en est aussi une multitude pour des opérations système. Mais je ne les installe pas non plus.

Il m’arrive d’en installer pour voir, et tester. Mais très souvent je me rends compte qu’il est possible de faire sans.

Exemple : pourquoi installer une tâche dédiée à vider un répertoire avant d’effectuer une copie de fichier ? Cela ne sert à rien quand on sait que la tâche de base dédiée à la copie a une option lui permettant de vider le dossier avant de procéder à la copie.

Et pour tout ce qui n’est pas possible avec les tâches de base ?

Pour tout le reste, j’utilise la tâche PowerShell. Celle-ci me permet de faire "inline", tout type d’action. Vu qu’il n’y a pas de limite à PowerShell, cette tâche peut tout faire.

Je ne m’impose que quelques règles :

• Cette tâche ne doit jamais lancer un script ps1, psm1 ou autre. La build doit rester lisible. Le code doit donc être "inline". Il ne faut pas avoir besoin d’ouvrir un fichier externe pour savoir ce que la tâche fait réellement.
• Cette tâche ne doit pas dépendre d’un outil tiers (la gestion des capacités doit rester de la responsabilité de l’agent Azure Pipeline).
• Le script ne doit pas dépasser quelques lignes (la lisibilité de la build est impérative).
• Le script ne doit pas contenir plus d’une condition (if, else, et c’est tout).
• L’action entreprise doit être reproductible 100% du temps et toujours donner le même résultat (pour ne pas nuire à la logique "déclarative" d’Azure Pipeline).

Moralité

Si vous n’avez jamais utilisé PowerShell, prenez le temps d’y regarder avant d’installer quoi que ce soit sur Azure DevOps. Il n’est pas impossible que vous trouviez quelques lignes de scripts qui répondront à vos besoins.

Si vous respectez les quelques règles que je me suis fixées, vous ne devriez jamais vous tromper.