Prévisualiser et approuver votre déploiement

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 des ressources existantes mises à jour. Quand vous exécutez un déploiement en mode complet, cela peut entraîner la suppression de ressources existantes.

Lorsque des ressources sont créées, mises à jour ou supprimées, il existe un risque que les choses puissent changer d’une manière que vous ne vous attendez pas. 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 :

Vous pouvez utiliser la commande Azure CLI az deployment group what-if dans votre définition de pipeline pour exécuter l'étape d'analyse d'impact :

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

L’opération de simulation n’apporte aucune modification à votre environnement. Au lieu de cela, elle décrit les ressources qui vont être créées, les propriétés des ressources qui vont être mises à jour et les ressources qui vont être supprimées.

Une opération de simulation peut parfois indiquer qu’une ressource changera alors qu’aucune modification ne se produira. Ce retour est appelé bruit. Nous travaillons à réduire ces problèmes. Vous pouvez signaler des problèmes ici.

Après avoir vu la sortie de l’opération de simulation, vous pouvez déterminer s’il faut poursuivre le déploiement. Cette étape implique généralement un examen humain de la sortie de la commande what-if, puis de prendre une décision sur le fait que les modifications identifiées soient raisonnables. Si un relecteur décide que les modifications sont raisonnables, il peut approuver manuellement l’exécution du pipeline.

Environnements

Dans Azure Pipelines, un environnement représente l’emplacement où 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 tâches pour définir une séquence d’étapes dans un pipeline. Lorsque 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 existe 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 lorsque vous avez plusieurs environnements de production. Dans ce module, vous utilisez 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 exige qu’un humain fournisse 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 de pipeline, il examine toutes les ressources de pipeline utilisées par l’étape, y compris les environnements. Les environnements peuvent être soumis à des vérifications qui doivent être satisfaites.

Une approbation est un type de vérification. Lorsque vous configurez une vérification d’approbation, vous attribuez un ou plusieurs réviseurs qui doivent approuver la continuation du 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 d’ouverture pendant lesquelles une étape peut s’exécuter, et même interroger Azure Monitor pour vous assurer qu’un déploiement a réussi. Seuls les contrôles d’approbation sont abordés dans ce module, mais le résumé du module inclut des liens vers des informations supplémentaires sur les vérifications.

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 réviseurs désignés comme approbateurs sont envoyés 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.

L’importance des bonnes pratiques

La fonctionnalité d’environnements dans Azure Pipelines vous permet de lier vos déploiements à un environnement. Le déploiement hérite ensuite des vérifications et 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 configurez votre référentiel pour requérir des revues de pull request sur les modifications apportées à votre branche principale en utilisant des stratégies de protection de branches. 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éversion et de validation doit avoir un rôle Azure personnalisé défini pour s’assurer qu’il dispose des autorisations minimales nécessaires pour effectuer son travail.