Cet article se destine particulièrement à ceux qui utilisent Azure Devops ou ont pour projet son utilisation.

Dans ce billet je vais expliquer rapidement les différentes briques dont nous allons avoir besoin sur Azure Devops pour pouvoir publier des modules avec Nuget. Si vous avez raté l’article précédent je vous conseille fortement de le lire avant de revenir ici. On y aborde un sujet important: bien organiser ses dossiers de module.

⚠️ Les descriptions sont les miennes, avec mes mots. Elles sont très certainement incomplètes voire techniquement bof, mais j’estime que ça sera suffisant pour les néophytes comme moi.

Car oui, je débute dans Azure Devops !

Les outils Azure Devops

Azure Repos

Les “repositories” ou dépôts sauce Microsoft ! Très similaire à Github, on peut tout à fait garder ses habitudes de commandes GIT d’ailleurs car c’est la même techno. Je ne vais pas m’attarder dessus plus que ça, c’est l’élément le plus simple.

Azure Pipelines

Les pipelines sont le pendant des workflow chez Github, pour ceux qui connaissent. Pour les autres, les pipelines c’est une machine conteneurisée qui va exécuter les tâches que vous lui donnez, dans l’ordre indiqué. On peut s’en servir pour tout un tas de chose, la majorité du temps ça conciste à automatiser la partie “build” de son dev, à savoir la compilation.

Toutes ces actions/tâches, ont une syntaxe particulière et sont rédigées au format YAML dans un fichier: azure-pipelines.yml

trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

# Exemple tiré de https://learn.microsoft.com/en-us/azure/devops/pipelines/customize-pipeline?view=azure-devops

Décrivons le plus important:

  • trigger: c’est la/les branche(s) du dépôt Azure Devops surveillée. Dès qu’elle est modifiée par un push, le pipeline se déclenche. Par défaut: main ou master
  • pool: c’est la plateforme utilisée pour votre build. Je vous conseille fortement le “ubuntu-latest”, bien plus rapide avec du Powershell qu’un windows-latest (paradoxal n’est-ce pas ?).
  • steps: contient les différentes tâches à faire par le pipeline

Il est possible d’organiser, scinder l’exécution des tâches en plusieurs grandes étapes:

  • Stages: Contient des grandes étapes, qui contiennent elles-mêmes des jobs
  • Jobs: Contient des jobs, un job = un nouvel environnement de build
  • Steps: Contient les task, les “actions” concrètes

La documentation de Microsoft à ce sujet est vraiment complète, néanmoins le formatage YAML est capricieux, je vous conseille l’utilisation de Visual Studio ou Visual Studio Code avec le module YAML.

Azure Artifacts

Cet outil vous permet de créer des flux, des “feeds” ou simplement ce qu’on peut appeler en Powershell des “providers”. C’est une plateforme d’échange de paquets de plusieurs types possibles: Nuget, Npm, Python… La documentation est encore une fois complète.

Azure Feeds

Partie intégrante de Artifact, un feed est un “flux” sur lequel vous allez publier vos paquets Nuget, Npm, etc. Dans le cas du projet global de modules powershell, le feed sera le PSRepository auquel se connecter.

Dans le prochain billet nous verrons les scripts à mettre en place ainsi que le contenu du fichier azure-pipelines.yml que j’ai rédigé permettant toute l’automatisation de build et de publication Nuget.