- Azure
- Azure DevOps
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.
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:
job
(job_build_app.yml
).frameworkVersion
et toolVersion
.Ecrire votre stage
de cette manière présente de nombreux inconvénients:
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.
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é !