Tester vos ressources après le déploiement
En validant et en prévisualisant votre déploiement Bicep, vous avez pu gagner en confiance sur la réussite du déploiement de vos fichiers Bicep. 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 découvrirez également 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. Mais vous ne savez pas nécessairement si les ressources vont faire réellement ce que vous voulez.
Par exemple, imaginez que vous déployez un nouveau serveur logique Azure SQL en utilisant un pipeline de déploiement Bicep. Votre définition Bicep pour le serveur est valide : elle réussit donc les phases de validation du linter et de prévisualisation. 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 à atteindre votre serveur.
- Vous avez activé l’authentification Microsoft Entra sur votre serveur alors que vous n’auriez pas dû le faire, 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 pipeline. Vérifiez que votre pipeline 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 votre pipeline 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 d’un agent de pipeline hébergé par Microsoft. Il peut être nécessaire d’envisager d’utiliser un agent auto-hébergé pour exécuter des phases 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 pipeline 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. Au lieu de cela, l’objectif est de vérifier que les ressources que vous avez définies vont fonctionner pour votre situation et répondre à vos exigences.
Exécuter des tests depuis Azure Pipelines
Il existe de nombreuses façons d’exécuter des tests dans votre pipeline. Dans ce module, nous allons utiliser Pester, un outil open source qui exécute des tests écrits avec PowerShell. 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 vous donnerons un lien vers PSRule dans le récapitulatif.
Quand vous utilisez un framework de tests pris en charge, Azure Pipelines comprend les résultats de chaque test. Il affiche les résultats des tests en même temps que les informations d’exécution du pipeline, et il effectue le suivi de l’historique de chaque test au fil du temps. Dans l’exercice suivant, vous verrez comment vous pouvez utiliser Azure Pipelines avec les tests de détection de fumée d’infrastructure.
Passer des données entre des étapes et des phases
Quand vous divisez votre pipeline en plusieurs phases, chacune avec sa propre responsabilité, vous devez parfois transmettre des données entre ces phases. Par exemple, une phase peut créer une ressource Azure avec laquelle une autre phase doit travailler. Pour pouvoir transmettre les données, la deuxième phase doit connaître le nom de la ressource qui a été créée. Par exemple, notre phase de test de détection de fumée doit accéder aux ressources qui ont été déployées par la phase 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. Vous pouvez accéder aux résultats d’un déploiement dans votre pipeline. Dans Azure Pipelines, il existe une syntaxe spéciale pour publier des variables afin de les rendre disponibles pour d’autres phases.
Tout d’abord, vous devez publier une variable de sortie pour une phase du pipeline. Pour produire la variable en sortie, vous allez écrire une chaîne spécialement mise en forme dans le journal du pipeline, qu’Azure Pipelines sait comment interpréter. Dans l’exemple suivant, une variable nommée myVariable est définie sur la valeur myValue :
echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"
Azure Pipelines lit et interprète la chaîne du journal du pipeline, et rend la valeur de la variable disponible en tant que sortie. Vous pouvez combiner cette valeur avec d’autres scripts pour publier une valeur de sortie du déploiement Bicep en tant que variable de sortie pour une phase du pipeline. Vous verrez comment le faire dans l’exercice suivant.
Ensuite, vous devez rendre la variable disponible pour le travail de votre phase de test de détection de fumée. Vous définirez une variable pour le travail et vous utiliserez une autre chaîne YAML spécialement mise en forme :
- stage: SmokeTest
jobs:
- job: SmokeTest
variables:
myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]
À présent, toutes les étapes du travail de test de détection de fumée peuvent accéder à la valeur de myVariable comme à n’importe quelle autre variable, en utilisant la syntaxe $(myVariable). Vous allez utiliser cette variable dans l’exercice suivant.
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 pipeline.
Il est également possible d’exécuter d’autres types de tests à partir d’un pipeline 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 pipeline déploie correctement vos ressources, mais que vos tests échouent. Que devez-vous faire ?
Plus tôt dans ce module, vous avez appris qu’Azure Pipelines vous permet de créer des phases de restauration qui s’exécutent en cas d’échec d’une phase précédente. Vous pouvez utiliser cette approche pour créer une phase de restauration quand votre phase de test signale un résultat inattendu. Vous pouvez également restaurer manuellement vos modifications ou réexécuter l’intégralité de votre pipeline si vous pensez que l’échec est dû à un problème temporaire qui a été depuis résolu.
Notes
Quand vous soumettez un déploiement à Azure Resource Manager, vous pouvez demander que Resource Manager réexécute automatiquement votre dernier déploiement réussi en cas d’échec. Pour ce faire, vous devez utiliser l’étape Azure CLI pour déployer votre fichier et ajouter le paramètre --rollback-on-error lorsque vous soumettez le déploiement à l’aide de la commande az deployment group create.
Il est souvent difficile de déterminer les étapes qu’une phase 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 pipeline 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 pourrez résoudre rapidement les problèmes et redéployer vos fichiers Bicep tout en conservant une haute qualité.
Conseil
Un des principes d’un état d’esprit DevOps est d’apprendre des erreurs. Si vous devez annuler un déploiement, déterminez avec soin pourquoi l’erreur s’est produite et ajoutez des tests automatisés avant que votre déploiement ne commence à détecter le même problème s’il se produit à l’avenir.