Utiliser des déclencheurs pour contrôler le moment d’exécution de votre pipeline

Effectué

Vous disposez maintenant d’un pipeline de travail qui déploie votre fichier Bicep dans votre environnement Azure. Toutefois, chaque fois que vous modifiez votre fichier, vous devez exécuter manuellement votre pipeline. Dans cette unité, vous allez apprendre à déclencher l’exécution automatique de votre pipeline chaque fois que votre code Bicep change.

Notes

Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.

Qu’est-ce qu’un déclencheur de pipeline ?

Un déclencheur de pipeline est une condition qui, lorsqu’elle est remplie, exécute automatiquement votre pipeline en fonction des règles que vous créez. Vous pouvez configurer des déclencheurs pour exécuter votre pipeline à intervalles planifiés. Vous pouvez également définir des déclencheurs pour exécuter votre pipeline chaque fois qu’un fichier de votre référentiel est modifié. Vous pourriez choisir la deuxième option, car il est en effet judicieux d’exécuter tous vos tests et étapes de déploiement chaque fois que quelqu’un modifie votre code.

Si vous n’utilisez pas de déclencheur automatique, quelqu’un peut apporter une modification à un fichier Bicep et même le valider et l’envoyer dans le référentiel. Mais s’ils oublient d’exécuter le pipeline, il y aura une différence entre les définitions de ressource dans votre fichier Bicep et les ressources qui sont déployées dans votre environnement Azure. Supposons qu’un plus grand nombre de commits et d’envois sont effectués, mais pas déployés. Si quelqu’un introduit une erreur ou une configuration inexistante dans le fichier Bicep dans l’une de ces modifications, il peut être difficile de détecter l’erreur parmi les multiples validations qui sont ensuite déployées simultanément. Après un certain temps, vous n’aurez plus confiance dans le fait que votre code Bicep représente véritablement votre infrastructure et il perd alors une partie de sa valeur.

Lorsque vous configurez votre pipeline pour qu’il s’exécute chaque fois que vous mettez à jour vos fichiers, le moment où vos modifications sont envoyées, le pipeline commence à s’exécuter. Vous recevez des commentaires instantanés sur la validité de vos modifications et vous pouvez vous assurer que votre environnement de production est toujours à jour.

Déclencheurs de branche

Un type déclencheur commun est un déclencheur de branche, aussi appelé déclencheur d’intégration continue ou déclencheur CI. Lorsque vous utilisez ce déclencheur de branche, chaque fois que vous apportez une modification à une branche spécifique, le pipeline est exécuté. Si vous commitez et poussez un changement vers une branche différente, le pipeline n’est pas déclenché et ne s’exécute pas. Il est courant d’utiliser ce type de déclencheur sur votre branche main ou votre branche par défaut, avec ce code :

trigger:
- main

Déclencher quand plusieurs branches changent

Vous pouvez configurer des déclencheurs pour exécuter votre pipeline sur une branche spécifique ou sur des ensembles de branches. Par exemple, supposons que vous créez des branches de version qui contiennent le code que vous allez déployer pour une version spécifique de votre projet. Vous pouvez utiliser des noms de branche comme release/v1, release/v2, etc. Vous souhaitez exécuter votre pipeline chaque fois que votre code change sur une branche qui commence par le nom release/. Vous pouvez utiliser la propriété include avec un caractère générique * :

trigger:
  branches:
    include:
    - main
    - release/*

Vous pouvez exclure certaines branches aussi. Supposons que vous collaboriez avec des membres de votre équipe sur le projet. Vos collègues créent des branches de fonctionnalités pour tester leurs idées dans les fichiers Bicep. Toutes ces branches de fonctionnalités reçoivent des noms comme feature/add-database, feature/improve-performance, etc. Vous souhaitez exécuter automatiquement votre pipeline sur toutes les branches, à l’exception des branches de fonctionnalités créées par vos collègues. Avec la propriété exclude, vous vous assurez que le pipeline n’est pas automatiquement déclenché pour les modifications apportées aux branches de fonctionnalités :

trigger:
  branches:
    include:
    - '*'
    exclude:
    - feature/*

Conseil

Notez les guillemets autour du caractère générique dans le filtre include. Pour le format de fichier YAML, vous devez placer un seul caractère * entre guillemets lorsque vous l’utilisez comme caractère générique.

Filtres de chemin

Parfois, certains fichiers de votre référentiel ne sont pas liés à votre déploiement. Par exemple, dans votre référentiel, vous pouvez avoir un dossier deploy qui contient votre code Bicep et un dossier docs distinct qui contient vos fichiers de documentation. Vous souhaitez déclencher votre pipeline quand une modification est effectuée sur un des fichiers Bicep dans le dossier deploy, mais vous ne souhaitez pas déclencher le pipeline si quelqu’un modifie uniquement un fichier dans la documentation. Pour configurer un déclencheur en vue de répondre aux modifications apportées à un dossier spécifique dans votre référentiel, vous pouvez utiliser un filtre de chemin d’accès :

trigger:
  branches:
    include:
    - main
  paths:
    exclude:
    - docs
    include:
    - deploy

Si quelqu’un valide une modification qui ne met à jour qu’un fichier de documentation, le pipeline ne s’exécute pas. Mais si quelqu’un modifie un fichier Bicep, ou même s’il modifie un fichier Bicep en plus d’un fichier de documentation, le déclencheur exécute le pipeline.

Planifier pour que votre pipeline s’exécute automatiquement

Vous pouvez exécuter votre pipeline selon une planification définie, et non en réponse à une modification de fichier. Par exemple, vous pouvez exécuter une version de votre code Bicep toutes les nuits ou déployer automatiquement un environnement de test tous les matins. Utilisez le mot clé schedules à la place de trigger et définissez la fréquence à l’aide d’une expression cron :

schedules:
- cron: "0 0 * * *"
  displayName: Daily environment restore
  branches:
    include:
    - main

Notes

Une expression cron est une séquence de caractères mise en forme qui spécifie la fréquence à laquelle un événement doit se produire. Dans cet exemple, 0 0 * * * signifie une exécution tous les jours à minuit UTC.

Vous pouvez également définir la branche de votre référentiel à utiliser dans l’événement planifié. Lorsque le pipeline démarre, il utilise la version la plus récente du code de la branche que vous avez définie dans la planification.

Utiliser des déclencheurs multiples

Vous pouvez combiner des déclencheurs et des planifications, comme dans cet exemple :

trigger:
- main

schedules:
- cron: "0 0 * * *"
  displayName: Deploy test environment
  branches:
    include:
    - main

Quand vous créez un déclencheur de branche et un déclencheur planifié dans le même pipeline, le pipeline s’exécute chaque fois qu’un fichier est changé sur la branche définie dans le déclencheur et selon le calendrier que vous avez défini. Dans cet exemple, le pipeline s’exécute tous les jours à minuit UTC, mais aussi chaque fois qu’une modification est envoyée à la branche primaire.

Conseil

Une bonne pratique consiste à définir des déclencheurs pour chaque pipeline. Si vous ne définissez pas de déclencheurs, par défaut, votre pipeline s’exécute automatiquement dès qu’un fichier est modifié sur une branche quelconque, ce qui n’est souvent pas ce que vous souhaitez.

Contrôle d’accès concurrentiel

Par défaut, Azure Pipelines permet l’exécution simultanée de plusieurs instances de votre pipeline. Cela peut arriver si vous effectuez plusieurs validations dans une branche en peu de temps.

Dans certains cas, le fait d’avoir plusieurs exécutions simultanées de votre pipeline ne pose aucun problème. Toutefois, quand vous travaillez avec des pipelines de déploiement, il peut être difficile de s’assurer que vos exécutions de pipeline n’écrasent pas vos ressources ou votre configuration Azure de manière inattendue.

Pour éviter ces problèmes, vous pouvez utiliser le mot clé batch avec un déclencheur, comme dans cet exemple :

trigger:
  batch: true
  branches:
    include:
    - main

Quand votre déclencheur est activé, Azure Pipelines attend la fin de toute exécution de pipeline active. Il démarre ensuite une nouvelle exécution avec toutes les modifications qui ont été accumulées depuis la dernière exécution.