Prévisualiser et approuver votre déploiement

  • 5 minutes

Vous savez à présent ce que sont les phases de pipeline et comment vous pouvez ajouter une phase de pipeline pour valider votre code Bicep. L’étape suivante pour être encore plus confiant dans votre déploiement consiste à ajouter une autre phase qui doit vérifier avec précision ce que votre déploiement va changer.

Dans cette unité, vous allez découvrir comment utiliser la commande de simulation what-if dans un pipeline. Vous allez également apprendre à ajouter des approbations, ce qui vous donnera l’opportunité de vérifier manuellement la sortie de la commande avant l’exécution du déploiement.

L’opération de simulation

Un fichier Bicep décrit l’état dans lequel vous voulez que votre environnement Azure se trouve à la fin d’un déploiement. Quand vous soumettez un déploiement, Azure Resource Manager modifie votre environnement Azure pour qu’il corresponde à l’état décrit dans votre fichier Bicep.

Un déploiement peut entraîner le déploiement de nouvelles ressources dans votre environnement ou la mise à jour de ressources existantes. Quand vous exécutez un déploiement en mode complet, cela peut entraîner la suppression de ressources existantes.

Quand des ressources sont créées, mises à jour ou supprimées, il y a un risque que les choses changent de façon inattendue. C’est une bonne pratique d’ajouter une étape supplémentaire pour vérifier quelles ressources exactement sont créées, mises à jour et supprimées. Cette vérification est bénéfique pour votre processus d’automatisation. Quand vous effectuez un déploiement sur un environnement de production, il est important de valider les modifications qui seront apportées à votre environnement.

Resource Manager fournit l’opération de simulation, que vous pouvez exécuter sur votre fichier Bicep dans votre phase du pipeline :

Diagram of a pipeline that includes Lint, Validate, and Preview stages. The Preview stage executes a what-if operation against Azure.

Vous pouvez utiliser la commande Azure CLI az deployment group what-if à partir de votre définition de pipeline pour exécuter l’étape de simulation :

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

Conseil

Dans ce module, nous allons utiliser l’interface Azure CLI pour exécuter l’opération de simulation. Si vous créez votre propre pipeline basé sur PowerShell, vous pouvez utiliser l’applet de commande New-AzResourceGroupDeployment avec le commutateur -Whatif ou vous pouvez utiliser l’applet de commande Get-AzResourceGroupDeploymentWhatIfResult.

L’opération de simulation n’apporte aucune modification à votre environnement. À la place, elle décrit les ressources qui sont créées ou supprimées, les propriétés de ressource qui sont mises à jour et les ressources qui sont supprimées.

Une opération de simulation peut parfois indiquer qu’une ressource changera alors qu’aucune modification ne se produira. Ce feedback est appelé bruit. Nous nous efforçons de réduire ces problèmes, mais nous avons besoin de votre aide pour nous signaler ces problèmes.

Une fois que vous avez vu le résultat de l’opération de simulation, vous pouvez déterminer s’il faut poursuivre le déploiement. Cette étape implique généralement qu’une personne passe en revue le résultat de la commande de simulation, puis décide si les modifications identifiées sont raisonnables. Si une personne qui fait le passage en revue décide que les modifications sont raisonnables, il peut approuver manuellement l’exécution du pipeline.

Pour en savoir plus sur la commande de simulation, consultez le module Microsoft Learn Prévisualiser les modifications du déploiement Azure en utilisant la simulation.

Environnements

Dans Azure Pipelines, un environnement représente l’emplacement sur lequel votre solution est déployée. Les environnements offrent différentes fonctionnalités qui vous aident à mener à bien des déploiements complexes. Dans un prochain module, vous en apprendrez davantage sur les environnements et leurs fonctionnalités. Pour l’instant, nous allons nous concentrer sur la possibilité qu’ils offrent d’ajouter des approbations manuelles à votre pipeline.

Comme vous le savez déjà, vous utilisez des travaux pour définir une séquence d’étapes dans une phase de pipeline. Quand vous incluez des environnements dans votre pipeline, vous devez utiliser un type spécial de travail appelé travail de déploiement. Un travail de déploiement est similaire à un travail normal, mais il offre des fonctionnalités supplémentaires. L’une de ces fonctionnalités permet notamment de définir l’environnement utilisé par le travail de déploiement :

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Notez que dans la définition YAML d’un travail de déploiement, il y a quelques différences clés par rapport à un travail normal :

  • Au lieu de commencer par le mot job, un travail de déploiement est défini sous la forme deployment.
  • Le mot clé environment spécifie le nom de l’environnement à cibler. Dans l’exemple précédent, le déploiement est suivi par rapport à un environnement nommé MyAzureEnvironment.
  • Le mot clé strategy spécifie comment Azure Pipelines exécute les phases du déploiement. Les stratégies de déploiement prennent en charge des processus de déploiement complexes, en particulier quand vous avez plusieurs environnements de production. Dans ce module, nous utilisons la stratégie de déploiement runOnce. Cette stratégie se comporte de la même façon que les autres travaux que vous avez déjà utilisés.

Vérifications et approbations des phases

Après avoir créé un environnement, vous pouvez définir des vérifications. Les vérifications sont utilisées pour vérifier les conditions qui doivent être remplies pour qu’un pipeline puisse utiliser l’environnement. Une approbation est un type de vérification qui nécessite qu’une personne donne une approbation manuelle.

Les vérifications sont définies sur l’environnement, et non pas sur le pipeline. Les auteurs du fichier YAML de pipeline ne peuvent pas supprimer ni ajouter ces vérifications et approbations. Seuls les administrateurs d’un environnement peuvent gérer les vérifications et approbations sur cet environnement.

Dans beaucoup d’organisations, le propriétaire d’un environnement dans Azure Pipelines est la personne responsable de l’environnement sur lequel le déploiement est effectué. Les vérifications et approbations aident à s’assurer que les bonnes personnes sont impliquées dans le processus de déploiement.

Comment fonctionnent les vérifications et les approbations ?

Les vérifications et approbations sont évaluées juste avant le début d’une phase de pipeline. Quand Azure Pipelines est sur le point d’exécuter une phase du pipeline, il examine toutes les ressources du pipeline utilisées par la phase, y compris les environnements. Les environnements peuvent être soumis à des vérifications qui doivent être satisfaites.

Une approbation est un type de vérification. Quand vous configurez une vérification d’approbation, vous affectez un ou plusieurs utilisateurs qui doivent approuver la poursuite de votre pipeline.

Azure Pipelines fournit également d’autres types de vérifications. Par exemple, vous pouvez appeler une API pour exécuter une logique personnalisée, contrôler les heures de bureau pendant lesquelles une phase peut s’exécuter, et même interroger Azure Monitor pour vérifier qu’un déploiement a réussi. Dans ce module, nous abordons uniquement les vérifications d’approbation, mais nous proposons des liens vers des informations supplémentaires sur les autres vérifications dans le résumé.

Notes

Des vérifications peuvent également être configurées sur les pools d’agents et les connexions de service. Vous pouvez aussi utiliser une étape spéciale appelée « tâche d’approbation manuelle ». Cependant, dans ce module, nous allons nous concentrer sur les environnements et les vérifications qui y sont associés.

Quand votre pipeline a commencé et qu’il atteint une étape nécessitant une vérification d’approbation, son exécution est suspendue. Tous les utilisateurs qui ont été désignés comme approbateurs reçoivent un message dans Azure DevOps et par e-mail.

Les approbateurs peuvent inspecter les journaux du pipeline, notamment les modifications détectées par l’opération de simulation. En s’appuyant sur ces informations, ils approuvent ou rejettent ensuite la modification. S’ils approuvent la modification, le pipeline reprend. S’ils la refusent ou s’ils ne répondent pas dans un délai d’attente configurable, la phase échoue.

Diagram of a pipeline that includes Lint, Validate, Preview, and Deploy stages, with an approval check before the Deploy stage.

L’importance des bonnes pratiques

La fonctionnalité des environnements dans Azure Pipelines vous permet de lier vos déploiements à un environnement, le déploiement héritant ensuite des vérifications et des approbations définies par le propriétaire de l’environnement. Cependant, rien n’oblige les nouveaux pipelines à utiliser des environnements.

Il est important que votre organisation et vous-même établissiez de bonnes pratiques pour la revue des définitions de pipeline. Par exemple, vous pouvez configurer votre dépôt pour exiger des revues des demandes de tirage sur toutes les modifications apportées à votre branche primaire, en utilisant des stratégies de protection de branche. Vous en apprendrez davantage sur ce concept dans un prochain module.

Vous pouvez également ajouter des vérifications et des approbations aux connexions de service qui garantissent que l’approbation est obtenue avant qu’un déploiement puisse utiliser les informations d’identification d’un principal de service. Toutefois, les approbations affectent également la capacité de votre pipeline à exécuter la validation préliminaire et l’opération de simulation, car elles nécessitent également une connexion de service.

Vous pourriez utiliser une autre connexion de service distincte pour la phase de simulation avec son propre principal de service. Le principal de service utilisé pour les phases de prévisualisation et de validation préalable doit avoir un rôle Azure personnalisé défini pour garantir qu’il dispose des autorisations minimales dont il a besoin pour effectuer son travail.