Photo par Maksym Kaharlytsky

Gérez vos versions par environnement avec les Azure DevOps YAML templates

Utilisez le YAML pour définir les version de vos environnements

Créé par Damien Aicheh le 07/09/2021 · 8 mins

Lors de la configuration du continuous integration (CI) et du continuious delivery (CD), vous devez toujours gérer différents environnements pour votre projet.

En fonction de vos besoins vous disposerez d’au moins 3 environnements pour piloter correctement votre projet, par exemple :

  • Développement
  • Staging
  • Production

L’environnement de développement (Dev) ne sera utilisé que par l’équipe d’ingénieurs. C’est l’environnement le plus instable, c’est là que tout se crée. Le Staging sera le miroir de l’environnement de production, où l’équipe de test vérifiera tout avant de pousser le code en production. Enfin, l’environnement de production est utilisé pour les utilisateurs finaux. Bien sûr, tout doit être aussi parfait que possible.

Bien entendu, le nom et le nombre d’environnements sont toujours définis par votre équipe en fonction de vos besoins.

Maintenant, comment traduire ces besoins dans Azure Pipelines YAML ?

Le workflow

Imaginons ce scénario : vous devez exécuter un ensemble de tests unitaires et de tests d’interface utilisateur pour valider que tout est fait correctement. En parallèle vous buildez votre application pour pouvoir la déployer. Si ces deux conditions sont valides, vous pouvez déployer sur l’environnement de développement.

Let’s imaging this scenerio: you have to run a set of multiple unit tests and UI tests to validate that everything is done correctly. In parallel you build your application to be able to deploy it to production. If these two conditions are valid you can deploy to the Dev environment.

Ouvrons Azure DevOps et traduisons ça en YAML !

trigger: none

pool:
  vmImage: ubuntu-latest

stages:
- stage: Tests
  jobs:
  - job: 
    displayName: Unit tests
    steps:
    - script: echo simulate running your unit tests!
      displayName: 'Run unit tests'
  - job: 
    displayName: UI tests
    steps:
    - script:  echo simulate running your ui tests!
      displayName: 'Run unit tests'

- stage: Build
  dependsOn: [] # This will remove implicit dependency and run in parallel with the stage: Tests above 
  jobs:
  - job:
    displayName: Build the application
    steps:
    - script: |
        echo Running all builds commands...
        echo ... commands successfully completed.
      displayName: 'Run build scripts & tasks'

- stage: Dev
  dependsOn:
  - Tests
  - Build
  jobs:
  - deployment:
    displayName: Dev deploy
    environment: Dev
    strategy:
     runOnce:
       deploy:
         steps:
           - script: echo Running in the Dev environment as deployment job
             displayName: 'Dev based stage'

Comme vous pouvez le voir ci-dessus, le stage de Tests et le stage de Build se font en parallèle. Le stage de Dev sera lancé s’ils réussissent tous les deux. L’environnement de développement est déclaré à l’aide du mot clé environment :

environment: Dev

Si vous exécutez ce pipeline, vous verrez dans Pipelines > Environments l’environnement de Dev apparaître automatiquement :

Dev Environment

Avec cela, vous pourrez suivre tous les déploiements effectués dans cet environnement en cliquant simplement dessus :

Dev environment list

Ajouter d’autres environnements

Avec notre environnement de développement prêt, nous pouvons maintenant ajouter deux étapes qui représenteront l’environnement de staging et de production en utilisant le même processus :

- stage: Staging
  jobs:
  - deployment:
    displayName: Staging deploy
    environment: Staging
    strategy:
     runOnce:
       deploy:
         steps:
           - script: echo Running in the Staging environment as deployment job
             displayName: 'Staging based stage'

- stage: Production
  jobs:
  - deployment: 
    displayName: Production deploy
    environment: Production
    strategy:
     runOnce:
       deploy:
         steps:
           - script: echo Running in the Production environment as deployment job
             displayName: 'Production based stage'

Maintenant, si vous exécutez le pipeline, vous verrez quelque chose comme ceci :

All environments deployed once

Maintenant, nos environnements sont prêts à fonctionner, mais comme vous l’avez probablement déjà remarqué, lorsque nous exécutons le pipeline, tous les environnements sont déployés une fois, ce qui n’est pas exactement ce que nous voulons. N’oubliez pas, nous devons laisser le temps à l’équipe de test pour valider tous les nouveaux développements sur l’environnement de Staging avant de le pousser vers celui de production.

Alors comment faire ?

Configurez vos environnements

Si vous entrez dans l’environnement de production par exemple et appuyez sur les 3 points dans le coin supérieur droit, puis sélectionnez Approvals and checks vous serez redirigé vers une page de configuration pour votre environnement. En cliquant sur le bouton plus, vous aurez une liste de différentes options pour contrôler votre environnement :

Add checks

Pour notre cas d’utilisation, nous choisirons les Approvals et nous pouvons maintenant ajouter une liste de personnes pour valider le déploiement du Staging à la Production. Nous avons également la possibilité d’ajouter un délai d’attente de 30 jours maximum pour accepter ou rejeter cette action.

Approvals example

Vous pouvez bien entendu définir différentes conditions pour tous vos environnements en fonction de vos besoins.

Avec cette règle créée sur l’environnement de production lorsque vous exécuterez à nouveau votre pipeline, vous verrez que le stage de l’environnement de production attend une approbation manuelle pour confirmer ou non le déploiement :

Approvals example

Les utilisateurs répertoriés comme approbateurs recevront un e-mail à ce sujet et seront invités à accepter ou non le déploiement en production dans Azure DevOps.

Touche finale

Comme vous l’avez vu, il est très facile de créer et de gérer vos versions à l’aide de vos environnements. De cette façon, vous pouvez maintenant tout faire en utilisant le YAML et l’enregistrer dans votre référentiel Git.

Vous trouverez un exemple de code sur ce répertoire Github.

Happy coding!

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

Sources:

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