Combinez vos steps spécifiques avec des templates YAML réutilisables dans Azure DevOps

Lorsque nous configurons des pipelines Azure DevOps dans nos projets, en tant que bon développeur, nous voulons toujours éviter les doublons entre nos projets, c’est pourquoi nous utilisons des répertoires de templates communs comme nous l’avons vu dans un précédent tutoriel.

Dans cet article, nous allons voir une utilisation avancée de ceux-ci.

Cas d’usage

Imaginons que vous ayez 3 projets dotnet qui partagent les mêmes templates de pipeline pour builder leur application. Cependant, chacun a une manière spécifique de publier le résultat du build.

Vous avez plusieurs possibilités pour y parvenir :

• Placez tous les templates spécifiques dans le répertoire commun
• Copiez-collez les templates communs dans chaque répertoire Git en y ajoutant les tasks de publication spécifiques
• Ajoutez des steps de post build aux templates communs afin que chaque projet puisse ajouter des tasks personnalisées

Ces 3 méthodes fonctionneront mais:

• La première casse la généricité de vos templates communs donc ce n’est pas la bonne approche
• La seconde ajoute des doublons à travers vos projets ce qui n’est pas acceptable
• La dernière vous permet de conserver des templates génériques et de conserver des templates spécifiques à l’intérieur de chaque projet

Bien sûr, nous choisirons la dernière possibilité.

Templates commun

Voici un template de job courant pour créer un projet dotnet :

parameters:
- name: preBuildSteps
  type: object
  default: []
- name: buildConfiguration
  type: string
  default: Release
- name: postBuildSteps
  type: object
  default: []

jobs:
- job: Build
  displayName: 'Build dotnet project'
  
  steps:
    - task: UseDotNet@2
      displayName: Install dotnet
      inputs:
        version: 6.0.x
        includePreviewVersions: false

    - task: NuGetToolInstaller@1
      displayName: Install Nuget tool

    - script: dotnet restore
      displayName: Restore package

    - ${{ parameters.preBuildSteps }}

    - script: dotnet build -c ${{ parameters.buildConfiguration }} --no-restore
      displayName: Build
    
    - ${{ parameters.postBuildSteps }}

Ce fichier appelé job-dotnet-build.yaml sera dans un dossier jobs à l’intérieur d’un dépôt Git spécifique : Common.Templates.

Comme vous pouvez le voir ci-dessus, ce job accepte les étapes de pré build et de post build, ce qui est idéal pour nous. Pour publier des artefacts, nous utiliserons évidemment les postBuildSteps.

Utiliser un modèle spécifique

Dans l’un de nos projets, nous avons ce template de publication spécifique :

parameters:
- name: artifactName
  type: string
  default: ''

steps: 
  - script: dotnet publish demo.csproj -c Release --no-restore --output $(Build.ArtifactStagingDirectory)
    displayName: Publish package

  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifacts to Azure DevOps'
    inputs:
      pathToPublish: '$(Build.ArtifactStagingDirectory)'
      artifactName: '${{ parameters.artifactName }}'

Ce fichier appelé publish_artifacts.yaml sera dans un dossier templates > tasks à l’intérieur du projet.

Il est maintenant temps de combiner les deux !

Dans notre pipeline azure-pipelines.yaml, nous aurons d’abord une référence pour consommer le répertoire Common.Templates :

resources:
  repositories:
    - repository: templates
      type: git
      name: Common.Templates
      ref: 'refs/tags/v0.0.1'

Notez que nous ciblons un tag spécifique pour nous assurer que nous récupérons à chaque build la même version des templates.

Ensuite, voici la partie délicate :

stages:
- stage:
  jobs:
    - template: jobs/job-dotnet-build.yaml@templates # Template from the Common.Templates repository
      parameters:
        postBuildSteps:
            - template: templates/tasks/publish_artifacts.yaml@self # Template from the current directory
              parameters:
                artifactName: 'drop'

Nous appelons notre template commun job en utilisant le mot clé @templates et pour cibler le template publish_artifacts.yaml dans notre répertoire de projet, nous devons absolument ajouter le mot clé @self. Si vous ne le faites pas, Azure DevOps essaiera de rechercher le template dans le répertoire Common.Templates et vous obtiendrez ce type d’erreur :

/jobs/job-dotnet-build.yaml@templates: File /jobs/templates/tasks/publish_artifacts.yaml not found in repository https://dev.azure.com/organisation/project/_git/Common.Template branch refs/heads/main version 196ef908f49819986db5483dacac5e6221610502.

C’est pourquoi le mot clé @self est important ici.

Touche finale

Vous savez maintenant comment combiner vos steps spécifiques avec des templates YAML réutilisables dans Azure DevOps ! Vous trouverez le code source complet dans ce répertoire Github.

Happy coding!

Vous avez aimé ce tutoriel ? Laissez une étoile sur le répertoire Github associé !

N'hésitez pas à me suivre sur Twitter pour ne pas rater mon prochain tutoriel !