Comment étendre vos templates YAML Azure DevOps

Il n’est pas facile de créer des templates YAML Azure Pipelines génériques et de maximiser leurs réutilisations dans vos projets. Dans ce tutoriel, nous allons voir comment créer des templates flexibles pouvant s’adapter à autant de projets que possible.

Petit rappel

Pour pouvoir réutiliser vos templates YAML, vous devez créer votre propre ensemble de templates. Ils peuvent être hébergés dans un répertoire Git privé ou public par exemple.

Comme vous pouvez le voir ci-dessus, chacun de vos projets fait référence à votre projet de templates communs. Ainsi, chaque fois que vous souhaitez configurer un nouveau pipeline pour votre projet, cela sera plus simple et plus rapide car vous utiliserez la même base de templates YAML.

Pour réutiliser autant que possible vos templates YAML, vous devez disposer du template le plus générique pour s’adapter à un maximum de cas. Cependant, certains projets nécessitent parfois quelques étapes spécifiques pour s’adapter à leurs propres cas. Vous êtes donc confronté à un problème: comment éviter de dupliquer vos templates pour pouvoir les étendre ?

Aperçu

Dans cet esprit, prenons un exemple:

Vous avez un projet qui utilise déjà l’un de vos templates communs appelé job-build.yml pour builder votre application. Ainsi, dans vos templates communs, vous avez toutes les étapes dont vous avez besoin:

# job-build.yml
parameters:
  # list of parameters needed here

jobs:
- job:
  displayName: 'Build Project'
  steps:
    
    - task: Bash@3
      displayName: 'Restore packages'
      inputs:
        targetType: 'inline'
        script: |
          echo Restore all packages needed

    - task: Bash@3
      displayName: 'Install certificates'
      inputs:
        targetType: 'inline'
        script: |
          echo Install all the certificates needed
     
    - task: Bash@3
      displayName: 'Build'
      inputs:
        targetType: 'inline'
        script: |
          echo This script represents the build tasks
          
    - task: Bash@3
      displayName: 'Publish'
      inputs:
        targetType: 'inline'
        script: |
          echo This script represents the publish tasks

Et vous l’utilisez comme ceci:

stages:
  - stage: Build
    jobs:
    - template: job-build.yml@templates
      parameters:
        # Pass all parameters here    

Imaginez maintenant que votre deuxième projet doive ajouter quelques étapes supplémentaires au fichier job-build.yml pour pouvoir répondre à ses besoins. Que pouvez-vous faire ?

La première idée que vous aurez probablement est de copier-coller vos templates génériques dans votre deuxième projet et d’ajouter les étapes dont vous avez besoin. Le problème avec cette solution est que:

• vous perdrez les évolutions potentielles de votre répertoire de templates communs
• vous créez une spécificité pour ce projet qui implique une perte de cohérence avec les autres projets
• vous perdez en maintenabilité

Alors, comment le rendre plus flexible ?

Solution

Pour résoudre ce problème, vous devrez ajouter différents points d’entrée dans vos templates génériques qui vous donneront la possibilité à tous les projets d’ajouter leur configuration personnalisée si nécessaire.

Vous devez ajouter des paramètres personnalisés qui sont une liste de steps en haut de votre template comme ceci:

parameters:
  myCustomSteps: []

et ensuite vous pouvez l’utiliser dans votre template comme ceci:

- ${{ parameters.myCustomSteps }}

Imaginons maintenant une liste de steps d’entrées et quelques exemples d’utilisation que vous pouvez avoir:

• onBegin: Vous pouvez installer d’autres certificats
• preBuild: Installer des packages personnalisés, définir une configuration, ajouter une bannière d’icônes..
• postBuild: Pousser un tag si le build a réussi
• prePublish: Créer une structure de dossier spécifique, renommer les artefacts qui viennent d’être générés
• onEnd: Nettoyer les actions, publier sur un autre point de terminaison

Revenons à notre template job-build.yml voici un exemple de ce que vous pouvez donc avoir:

# job-build.yml
parameters:
  preBuild: []
  postBuild: []
  
jobs:
- job:
  displayName: 'Build Project'
  steps:
    
    - task: Bash@3
      displayName: 'Restore packages'
      inputs:
        targetType: 'inline'
        script: |
          echo Restore all packages needed
    - task: Bash@3
      displayName: 'Install certificates'
      inputs:
        targetType: 'inline'
        script: |
          echo Install all the certificates needed
     
    - ${{ parameters.preBuild }} # Here we start the prebuild steps

    - task: Bash@3
      displayName: 'Build'
      inputs:
        targetType: 'inline'
        script: |
          echo This script represents the build tasks
          
    - ${{ parameters.postBuild }} # Here we start the postbuild steps

    - task: Bash@3
      displayName: 'Publish'
      inputs:
        targetType: 'inline'
        script: |
          echo This script represents the publish tasks

Pour insérer plus d’étapes, c’est maintenant super facile:

stages:
  - stage: Build
    jobs:
    - template: job-build.yml@templates
      parameters:
        preBuild:
          - task: Bash@3
            displayName: 'Add custom configuration'
            inputs:
              targetType: 'inline'
              script: |
                echo Add a specific configuration
          - task: Bash@3
            displayName: 'Define application version'
            inputs:
              targetType: 'inline'
              script: |
                echo Define the application version automatically
        postBuild:
          - task: Bash@3
            displayName: 'Push git tag'
            inputs:
              targetType: 'inline'
              script: |
                echo Push a tag to the Git repository  

Les avantages de cette solution sont:

• vous avez des templates flexibles
• la réutilisabilité à travers vos projets est plus élevée
• vous pouvez facilement déboguer les templates en plaçant quelques étapes supplémentaires
• si vous ne spécifiez pas de valeurs pour les paramètres des steps, ce n’est pas un problème, elles seront ignorées

Touche finale

Vous avez maintenant la possibilité de personnaliser vos pipelines YAML selon vos besoins. Comme d’habitude, vous trouverez l’exemple de code source dans le répertoire Github associé.

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 !