Photo par Patrick Fore

Azure Devops : Réduisez vos pipelines YAML

Simplifiez vos scripts YAML !

Créé par Damien Aicheh le 30/09/2020 · 6 mins

Lorsque vous créez vos pipelines pour vos projets, vous devez probablement configurer des jobs avec plusieurs configurations, en fonction des différents environnements ciblés (par exemple,dev, staging, production et ainsi de suite). Ces configurations peuvent être répétitives et prendre du temps. Dans ce tutoriel, je vais vous montrer comment optimiser ce processus.

Aperçu du contexte

Prenons l’exemple d’un nightly build, où vous voulez vérifier que toutes les configurations de votre projet fonctionnent toujours après une journée de travail.

Voici un job de base avec toutes les tasks que vous devez utiliser pour builder votre projet:


# job_build_app.yml
parameters:
  name: ''
  certificate: ''
  frameworkVersion: ''
  toolVersion: ''

jobs:
- job: Build_app_${{ parameters.name }}

  steps:
  - task: Bash@3
    inputs:
      targetType: 'inline'
      script: |
        echo This job will running on env ${{ parameters.name }} with framework version ${{ parameters.frameworkVersion }} and tool ${{ parameters.toolVersion }} with the certificat ${{ parameters.certificate }}
    
    # All the tasks you need to build the project...

Et maintenant le stage qui définit le nightly build avec plusieurs environnements:


# Basic nightly_builds.yml
stages:
- stage: Build
  jobs:
  - template: job_build_app.yml
    parameters:
      name: 'dev'
      certificate: 'certificat-dev'
      frameworkVersion: '5.0'
      toolVersion: '1.0'
      
  - template: job_build_app.yml
    parameters:
      name: 'staging'
      certificate: 'certificat-staging'
      frameworkVersion: '5.0'
      toolVersion: '1.0'

  - template: job_build_app.yml
    parameters:
      name: 'production'
      certificate: 'certificat-production'
      frameworkVersion: '5.0'
      toolVersion: '1.0'

Comme vous pouvez le voir dans cet exemple, plusieurs paramètres sont répétitifs:

  • Le nom du template utilisé pour chaque job (job_build_app.yml).
  • Les paramètres frameworkVersion et toolVersion.

Ecrire votre stage de cette manière présente de nombreux inconvénients:

  • C’est inutile: le copier / coller n’ajoute aucune plus value.
  • Cela n’aide pas pour la lisibilité: beaucoup de lignes sont remplies de données inintéressantes.
  • La maintenance est fastidieuse: vous devrez changer la même valeur à plusieurs endroits.
  • Il est sujet aux erreurs: vous devrez vous assurer de remplacer tous les paramètres par la même valeur. L’utilisation de variables dans le template permettrait toutefois de limiter les sources d’erreurs.

Optimisation

Avec cela en tête, voyons comment nous pouvons optimiser cela. L’idée est d’itérer sur les configurations de chaque environnement avec le même template YAML et de mutualiser les paramètres qui sont dupliqués.

Créons un template intermédiaire appelé: jobs_build_app.yml, qui bouclera sur les configurations pour chaque job.


# jobs_build_app.yml
parameters:
  frameworkVersion: ''
  toolVersion: ''
  envs: {}

jobs:
- ${{ each env in parameters.envs }}:
  - template: job_build_app.yml
    parameters:
      name: ${{ env.name }}
      frameworkVersion: ${{ parameters.frameworkVersion }}
      toolVersion: ${{ parameters.toolVersion }}
      certificate: ${{ env.certificate }}

Comme vous pouvez le voir ci-dessus, les paramètres communs frameworkVersion et toolVersion sont définis une fois et le template job_build_app.yml n’est configuré qu’une seule fois aussi.

Le point clé ici est la ligne ci-dessous qui est essentiellement une boucle for sur les autres environnements: envs: {}::


${{ each env in parameters.envs }}

Mettons à jour notre stage de nightly build maintenant:


# nightly_builds.yml
stages:
- stage: Build
  jobs:
  - template: jobs_build_app.yml
    parameters:
      frameworkVersion: '5.0'
      toolVersion: '1.0'
      envs:
        - env:
          name: 'dev'
          certificate: 'certificat-dev'
        - env:
          name: 'staging'
          certificate: 'certificat-staging'
        - env:
          name: 'production'
          certificate: 'certificat-production'

Comme vous pouvez le voir, cette syntaxe fait exactement la même chose que la première mais elle est plus lisible et directe.

Touche finale

Vous avez maintenant la possibilité de simplifier 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 pour ne pas rater mon prochain tutoriel !