Prévisualiser et approuver votre déploiement

5 minutes

Vous savez maintenant ce que sont les travaux de workflow et comment ajouter un travail au workflow pour valider votre code Bicep. L’étape suivante pour être encore plus confiant dans votre déploiement consiste à ajouter un autre travail 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 workflow. Vous allez également apprendre à ajouter des règles de protection à l’environnement, 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.

Chaque fois que des ressources sont créées, mises à jour ou supprimées, il y a un risque que certaines choses changent d’une façon inattendue. C’est une bonne pratique que d’ajouter une étape supplémentaire pour vérifier ce qui sera exactement créé, mis à jour et supprimé. 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 what-if, que vous pouvez exécuter sur votre fichier Bicep dans votre travail de workflow :

Diagramme d’un workflow qui montre les travaux Lint, Validate et Preview. Le travail Preview exécute une opération de simulation sur Azure.

L’action arm-deploy prend en charge le déclenchement de l’opération de simulation en utilisant la propriété additionalArguments :

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

Le code mis en évidence équivaut à exécuter le déploiement en utilisant Azure CLI, avec l’argument --what-if inclus.

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 type de sortie est appelé bruit. Nous nous efforçons de réduire ces problèmes, mais nous avons besoin de votre aide. Signalez les problèmes de simulation.

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 la personne qui fait la revue décide que les modifications sont raisonnables, elle peut approuver manuellement l’exécution du workflow.

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 GitHub Actions, 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 nous concentrons sur la possibilité qu’ils offrent d’ajouter les réviseurs nécessaires à votre workflow.

Vous créez un environnement à partir de l’interface web GitHub. Vous pouvez créer des environnements quand vous utilisez un dépôt GitHub public ou un compte GitHub Enterprise.

Après avoir créé un environnement, vous pouvez le référencer dans n’importe quel travail de votre workflow :

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Remarque

Quand l’identité de la charge de travail de votre workflow de déploiement interagit avec Resource Manager au sein d’un environnement, elle a besoin d’informations d’identification fédérées configurées avec le nom de l’environnement. Vous en apprendrez davantage sur les environnements dans les prochains modules. Quand vous exécutez les exercices de ce module, vous créez les informations d’identification fédérées nécessaires.

Règles de protection de l’environnement

Une fois l’environnement créé, vous pouvez définir des règles de protection. Les règles de protection servent à vérifier les conditions devant être remplies pour qu’une étape puisse utiliser l’environnement. La règle de protection Réviseurs nécessaires est un type de vérification qui nécessite qu’une personne donne une approbation manuelle.

Les règles de protection sont définies sur l’environnement, et non pas sur le workflow. Les auteurs du fichier YAML du workflow ne peuvent pas supprimer ni ajouter ces règles de protection. Seuls les administrateurs d’un dépôt ou le propriétaire du compte peuvent gérer des environnements et leurs règles de protection associées.

Les règles de protection de l’environnement aident à s’assurer que les bonnes personnes sont impliquées dans le processus de déploiement.

Comment les règles de protection de l’environnement fonctionnent-elles ?

Lorsque vous associez un environnement à une étape, les règles de protection de l’environnement sont évaluées juste avant le début de l’étape.

La règle Réviseurs nécessaires est un type de règle de protection. Quand vous configurez une règle de protection Réviseurs nécessaires, vous définissez un ou plusieurs utilisateurs GitHub qui devront approuver la poursuite de votre workflow.

Les environnements fournissent également d’autres types de règles de protection. Par exemple, vous pouvez restreindre les branches Git qui peuvent être déployées dans des environnements spécifiques. Dans ce module, nous abordons uniquement la règle Réviseurs nécessaires, mais nous vous proposons des liens vers des informations supplémentaires sur les autres règles de protection dans le résumé.

Quand votre workflow a commencé et qu’il atteint une étape nécessitant un réviseur, son exécution est suspendue. Tous les utilisateurs qui sont désignés comme réviseurs reçoivent un message dans GitHub et par e-mail.

Les réviseurs peuvent inspecter les journaux du workflow, notamment les modifications ayant été 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 workflow reprend son exécution. S’ils la refusent ou s’ils ne répondent pas dans le délai imparti, l’exécution du travail échoue.

Diagramme d’un workflow qui comprend les travaux Lint, Validate, Preview et Deploy, avec une vérification d’approbation ajoutée avant le travail Deploy.

L’importance des bonnes pratiques

La fonctionnalité des environnements dans GitHub vous permet de lier vos déploiements à un environnement, le déploiement héritant ensuite des règles de protection définies par l’administrateur de l’environnement. Cependant, rien n’oblige les nouveaux workflows à utiliser des environnements.

Il est important que votre organisation établisse de bonnes pratiques pour la révision de vos définitions de workflow. Par exemple, configurez votre dépôt pour exiger des revues des demandes de tirage sur toutes les modifications apportées à votre branche primaire, en utilisant des règles de protection de branche. Vous en apprendrez davantage sur ce concept dans un prochain module.