Tester vos ressources après le déploiement

6 minutes

En validant et en prévisualisant votre déploiement Bicep, vous savez que vos fichiers Bicep seront correctement déployés. Mais le déploiement n’est pas le tout. Une fois le déploiement terminé, il est également utile de vérifier que votre déploiement a fait ce que vous aviez prévu.

Dans cette unité, vous allez découvrir les tests que vous pouvez effectuer après le déploiement. Vous allez aussi découvrir comment annuler votre déploiement si les choses ne se passent pas comme prévu.

Exécuter des tests de détection de fumée et des tests négatifs

Quand vous définissez des ressources dans un fichier Bicep, votre objectif n’est pas seulement de créer des ressources dans Azure. C’est aussi de produire de la valeur ajoutée pour votre organisation tout en répondant à ses exigences. Quand vous validez et que vous prévisualisez vos fichiers Bicep, votre confiance dans la validité des définitions de ressource augmente. Toutefois, vous ne savez pas nécessairement si les ressources vont réellement faire que vous voulez.

Par exemple, imaginez que vous déployez un nouveau serveur logique Azure SQL en utilisant un workflow de déploiement Bicep. Votre définition Bicep pour le serveur est valide : elle réussit donc les travaux de linting et de validation préalable. La commande de simulation indique qu’un serveur va être créé, qui est ce que vous attendez. Le déploiement s’est également terminé avec succès. Mais à la fin du processus de déploiement, vous pourriez ne pas avoir un serveur de base de données opérationnel qui soit prêt à l’emploi. En voici les raisons possibles :

Vous n’avez pas configuré de règles de pare-feu pour autoriser le trafic réseau à accéder à votre serveur.
Vous avez activé l’authentification Microsoft Entra sur votre serveur alors que vous n’auriez pas dû, ou vice versa.

Même quand vous déployez seulement des fichiers Bicep de base, il est bon de réfléchir à la façon dont vous pouvez vérifier que les ressources que vous déployez fonctionnent réellement et répondent à vos exigences. Voici des exemples de la façon dont vous pouvez appliquer ce principe :

Quand vous déployez un site web, essayez d’atteindre l’application web à partir de votre workflow. Vérifiez que votre workflow réussit à se connecter au site web et reçoit un code de réponse valide.
Quand vous déployez un réseau de distribution de contenu (CDN), essayez de vous connecter à une ressource via le CDN. Vérifiez que le workflow réussit à se connecter au CDN et reçoit un code de réponse valide.

Ces tests sont parfois appelés tests de détection de fumée d’infrastructure. Le test de détection de fumée est une forme simple de test conçue pour dévoiler des problèmes majeurs dans votre déploiement.

Notes

Certaines ressources Azure ne sont pas faciles à atteindre à partir des exécuteurs hébergés par GitHub. Il peut être nécessaire d’envisager d’utiliser un exécuteur auto-hébergé pour exécuter des travaux de tests de détection de fumée s’ils ont besoin d’accéder à des ressources via des réseaux privés.

Il est également judicieux d’effectuer des tests négatifs. Un test négatif vous permet de vérifier que vos ressources n’ont pas un comportement indésirable. Par exemple, quand vous déployez une machine virtuelle, c’est une bonne pratique que d’utiliser Azure Bastion pour se connecter de façon sécurisée à la machine virtuelle. Vous pouvez ajouter un test négatif à votre workflow pour vérifier que vous ne pouvez pas vous connecter à une machine virtuelle directement en utilisant Connexion Bureau à distance ou SSH.

Important

L’objectif de ces tests n’est pas de vérifier que Bicep a déployé vos ressources correctement. En utilisant Bicep, vous faites l’hypothèse qu’il va déployer les ressources que vous spécifiez dans vos fichiers Bicep. À la place, l’objectif est de vérifier que les ressources que vous avez définies fonctionnent dans votre situation et répondent à vos exigences.

Exécuter des tests à partir de workflows GitHub

Il existe de nombreuses façons d’exécuter des tests dans votre workflow. Dans ce module, nous utilisons Pester, un outil open source qui exécute des tests écrits via PowerShell. Pester est préinstallé sur les exécuteurs hébergés par GitHub. Vous n’avez rien de spécial à faire pour l’utiliser dans une étape de script.

Vous pouvez choisir d’utiliser un autre framework de tests ou même d’exécuter vos tests sans outil de test. Par exemple, un autre outil de test possible est PSRule pour Azure, qui comprend plusieurs règles et tests prédéfinis pour Azure. Il peut effectuer une validation sur vos modèles et exécuter des tests sur vos ressources Azure déployées. Nous donnons un lien vers PSRule dans le récapitulatif.

Lorsque vous exécutez des tests à partir d’un workflow, les échecs de test doivent en principe arrêter le workflow. Dans l’exercice suivant, vous verrez comment vous pouvez utiliser des workflows avec les tests de détection de fumée d’infrastructure.

Les résultats des tests sont écrits dans le journal du workflow. La Place de marché GitHub contient également des actions non-Microsoft qui peuvent afficher et suivre les résultats des tests au fil du temps.

Transmettre des données entre les travaux

Quand vous divisez votre workflow en plusieurs travaux, chacun avec sa propre responsabilité, vous devez parfois transmettre des données entre ces travaux. Par exemple, un travail peut créer une ressource Azure avec laquelle un autre travail doit travailler. Pour pouvoir transmettre les données, le deuxième travail doit connaître le nom de la ressource qui a été créée. Par exemple, notre travail de test de détection de fumée doit accéder aux ressources qui ont été déployées par le travail de déploiement.

Votre fichier Bicep déploie les ressources : il peut donc accéder aux propriétés de la ressource et les publier comme résultats du déploiement. Quand vous exécutez votre déploiement Bicep avec l’action arm-deploy, celle-ci stocke les sorties du déploiement Bicep dans ces sorties d’étape. Ensuite, le travail contenant l’action arm-deploy peut alors publier ces sorties d’étape en tant que sorties de travail. Le travail référence la propriété id de l’étape, que nous définissons sur deploy :

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - 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
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Vous pouvez accéder à la sortie d’un travail dans n’importe quel travail suivant qui dépend du travail générateur de la sortie :

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Vous pouvez également transmettre les sorties d’un script de workflow en employant une syntaxe spéciale. Nous proposons des liens vers des informations supplémentaires dans le résumé.

Autres types de tests

Les tests fonctionnels et les tests d’intégration sont souvent utilisés pour vérifier que les ressources déployées se comportent comme prévu. Par exemple, un test d’intégration peut se connecter à votre site web et soumettre une transaction de test, puis attendre pour vérifier que la transaction s’est terminée avec succès. En utilisant des tests d’intégration, vous pouvez tester la solution créée par votre équipe ainsi que l’infrastructure sur laquelle elle s’exécute. Dans un module ultérieur, vous verrez comment ces types de tests peuvent être ajoutés à votre workflow.

Il est également possible d’exécuter d’autres types de tests à partir d’un workflow de déploiement, notamment des tests de performances et des tests d’intrusion de sécurité. Ces tests ne sont pas traités dans ce module, mais ils peuvent apporter de la valeur ajoutée à un processus de déploiement automatisé.

Restaurer ou restaurer par progression

Supposons que votre workflow déploie correctement vos ressources, mais que vos tests échouent. Que devez-vous faire ?

Plus tôt dans ce module, vous avez appris que GitHub Actions vous permet de créer des travaux de restauration qui s’exécutent en cas d’échec d’un travail précédent. Vous pouvez utiliser cette approche pour créer un travail de restauration quand votre travail de test signale un résultat inattendu. Vous pouvez également restaurer manuellement vos changements ou réexécuter l’intégralité de votre workflow si vous pensez que l’échec est dû à un problème temporaire qui a été résolu depuis.

Remarque

Quand vous envoyez un déploiement à Azure Resource Manager, vous pouvez demander à Resource Manager de réexécuter automatiquement votre dernier déploiement réussi en cas d’échec. Pour cela, utilisez le paramètre --rollback-on-error quand vous soumettez le déploiement en utilisant la commande Azure CLI az deployment group create.

Par exemple, vous pouvez ajouter un travail de restauration à votre workflow. Le travail de restauration s’exécute lorsque le travail de test de détection de fumée échoue :

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Le travail dépend du travail de test de détection de fumée. Il s’exécute uniquement en cas d’échec du test. Par défaut, GitHub Actions arrête le workflow dès qu’un travail précédent échoue. La condition if comprend une vérification always() pour substituer ce comportement. Si always() n’est pas inclus dans l’expression, le travail de restauration est ignoré quand un travail précédent échoue.

Il est souvent difficile de déterminer les étapes qu’un travail de restauration doit effectuer. Les déploiements Bicep sont généralement complexes et il n’est pas facile d’annuler les modifications. Il est particulièrement difficile de restaurer quand votre déploiement comprend d’autres composants.

Par exemple, imaginez que votre workflow déploie un fichier Bicep qui définit une base de données Azure SQL, puis ajoute des données à la base de données. Si votre déploiement est annulé, les données doivent-elles être supprimées ? La base de données doit-elle aussi être supprimée ? Vous pouvez difficilement prédire comment chaque échec et chaque restauration peuvent impacter votre environnement d’exécution.

Pour cette raison, de nombreuses organisations préfèrent restaurer par progression, ce qui signifie qu’elles corrigent rapidement la raison de l’échec, puis redéploient. En créant un processus de déploiement automatisé de haute qualité et en suivant toutes les bonnes pratiques que vous avez apprises dans ces parcours d’apprentissage, vous pouvez résoudre rapidement les problèmes et redéployer vos fichiers Bicep tout en conservant une haute qualité.

Conseil