- Azure
- Azure DevOps
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 :
Avec cela, vous pourrez suivre tous les déploiements effectués dans cet environnement en cliquant simplement dessus :
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 :
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 :
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.
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 :
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: