Uw resources testen na de implementatie

6 minuten

Door uw Bicep-implementatie te valideren en een voorbeeld ervan te bekijken, kunt u erop vertrouwen dat uw Bicep-bestanden met succes worden geïmplementeerd. Maar implementatie is niet het hele verhaal. Nadat de implementatie is voltooid, is het ook handig om te controleren of uw implementatie heeft gedaan wat u had verwacht.

In deze les leert u meer over tests die u kunt uitvoeren nadat de implementatie is voltooid. U krijgt ook informatie over het terugdraaien van uw implementatie als de dingen niet naar verwachting blijken.

Betrouwbaarheidstests en negatieve tests uitvoeren

Wanneer u resources in een Bicep-bestand definieert, is het niet alleen uw doel om resources te maken in Azure. Het is om waarde te leveren aan uw organisatie tijdens het voldoen aan de vereisten van uw organisatie. Wanneer u uw Bicep-bestanden valideert en bekijkt, weet u zeker dat de resourcedefinities geldig zijn, maar u weet niet per se dat de resources daadwerkelijk doen wat u wilt.

Stel dat u een nieuwe logische Azure SQL-server implementeert met behulp van een Bicep-implementatiepijplijn. Uw Bicep-definitie voor de server is geldig, zodat deze de linter- en preflight-validatiefasen doorgeeft. Met de wat-als-opdracht ziet u dat er een server wordt gemaakt. Dit is wat u verwacht. De implementatie is ook voltooid. Maar aan het einde van het implementatieproces hebt u mogelijk nog steeds geen werkende databaseserver die klaar is voor gebruik. Mogelijke oorzaken zijn:

U hebt geen firewallregels geconfigureerd om netwerkverkeer toe te staan uw server te bereiken.
U hebt Microsoft Entra-verificatie ingeschakeld op uw server wanneer u dat niet zou moeten hebben, of omgekeerd.

Zelfs wanneer u alleen eenvoudige Bicep-bestanden implementeert, is het de moeite waard te overwegen hoe u kunt controleren of de resources die u implementeert, daadwerkelijk werken en aan uw vereisten voldoen. Hier volgen voorbeelden van hoe u dit principe kunt toepassen:

Wanneer u een website implementeert, probeert u de webtoepassing te bereiken vanuit uw pijplijn. Controleer of uw pijplijn verbinding maakt met de website en een geldige antwoordcode ontvangt.
Wanneer u een CDN (Content Delivery Network) implementeert, probeert u via het CDN verbinding te maken met een resource. Controleer of de pijplijn verbinding maakt met het CDN en een geldige antwoordcode ontvangt.

Deze tests worden ook wel betrouwbaarheidstests van infrastructuur genoemd. Betrouwbaarheidstests zijn een eenvoudige vorm van testen die zijn ontworpen om grote problemen in uw implementatie te ontdekken.

Notitie

Sommige Azure-resources zijn niet eenvoudig te bereiken vanuit een door Microsoft gehoste pijplijnagent. Mogelijk moet u overwegen om een zelf-hostende agent te gebruiken om betrouwbaarheidstestfasen uit te voeren als ze toegang nodig hebben tot resources via privénetwerken.

Het is ook een goed idee om negatieve tests uit te voeren. Negatieve tests helpen u te bevestigen dat uw resources geen ongewenst gedrag hebben. Wanneer u bijvoorbeeld een virtuele machine implementeert, is het een goede gewoonte om Azure Bastion te gebruiken om veilig verbinding te maken met de virtuele machine. U kunt een negatieve test toevoegen aan uw pijplijn om te controleren of u niet rechtstreeks verbinding kunt maken met een virtuele machine met behulp van Verbinding met extern bureaublad of SSH.

Belangrijk

Het doel van deze tests is niet om te controleren of Bicep uw resources correct heeft geïmplementeerd. Door Bicep te gebruiken, gaat u ervan uit dat hiermee de resources worden geïmplementeerd die u opgeeft in uw Bicep-bestanden. In plaats daarvan is het doel om te controleren of de resources die u hebt gedefinieerd, geschikt zijn voor uw situatie en voldoen aan uw vereisten.

Tests uitvoeren vanuit Azure Pipelines

Er zijn veel manieren waarop u tests in uw pijplijn kunt uitvoeren. In deze module gebruiken we Pester. Dit is een opensource-hulpprogramma waarmee tests worden uitgevoerd die zijn geschreven via PowerShell. U kunt ervoor kiezen om een ander testframework te gebruiken of zelfs uw tests zonder testhulpprogramma uit te voeren. Een ander testhulpprogramma waarmee u rekening moet houden, is bijvoorbeeld PSRule voor Azure, waaronder vooraf gedefinieerde regels en tests voor Azure. Het kan validatie uitvoeren op uw sjablonen en ook tests uitvoeren op uw geïmplementeerde Azure-resources. In de samenvatting wordt een koppeling naar PSRule gemaakt.

Wanneer u een ondersteund testframework gebruikt, begrijpt Azure Pipelines de resultaten van elke test. De testresultaten worden weergegeven naast de informatie over de pijplijnuitvoering en de geschiedenis van elke test wordt in de loop van de tijd bijgehouden. In de volgende oefening ziet u hoe u Azure Pipelines kunt gebruiken met betrouwbaarheidstests voor infrastructuur.

Gegevens doorgeven tussen stappen en fasen

Wanneer u uw pijplijn in meerdere fasen verdeelt, elk met een eigen verantwoordelijkheid, moet u soms gegevens doorgeven tussen deze fasen. Een fase kan bijvoorbeeld een Azure-resource maken waarmee een andere fase moet werken. Als u gegevens wilt doorgeven, moet de tweede fase de naam weten van de resource die is gemaakt. De betrouwbaarheidstestfase moet bijvoorbeeld toegang hebben tot de resources die de implementatiefase heeft geïmplementeerd.

Uw Bicep-bestand implementeert de resources, zodat het toegang heeft tot de resource-eigenschappen en deze als implementatie-uitvoer kan publiceren. U hebt toegang tot een implementatie-uitvoer in uw pijplijn. In Azure Pipelines is er een speciale syntaxis voor het publiceren van variabelen om deze beschikbaar te maken in fasen.

Eerst moet u een uitvoervariabele voor een pijplijnfase publiceren. Als u de variabele wilt uitvoeren, schrijft u een speciaal opgemaakte tekenreeks naar het pijplijnlogboek, wat Azure Pipelines weet te begrijpen. In het volgende voorbeeld wordt een variabele met de naam myVariable ingesteld op de waarde myValue:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines leest en interpreteert de tekenreeks uit het pijplijnlogboek en maakt de waarde van de variabele beschikbaar als uitvoer. U kunt deze waarde combineren met meer scripts om de waarde van een Bicep-implementatie-uitvoer te publiceren als uitvoervariabele voor een pijplijnfase. In de volgende oefening ziet u hoe u dit doet.

Ten tweede moet u de variabele beschikbaar maken voor de taak van uw betrouwbaarheidstestfase. U definieert een variabele voor de taak en gebruikt een andere speciaal opgemaakte YAML-tekenreeks:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Nu hebben alle stappen binnen de betrouwbaarheidstesttaak toegang tot de myVariable waarde zoals elke andere variabele, met behulp van de syntaxis $(myVariable). In de volgende oefening gebruikt u een variabele.

Andere testtypen

Functionele tests en integratietests worden vaak gebruikt om te valideren dat de geïmplementeerde resources werken zoals verwacht. Een integratietest kan bijvoorbeeld verbinding maken met uw website en een testtransactie indienen en vervolgens wachten om te bevestigen dat de transactie is voltooid. Met behulp van integratietests kunt u de oplossing testen die uw team bouwt, samen met de infrastructuur waarop deze wordt uitgevoerd. In een toekomstige module ziet u hoe deze typen tests kunnen worden toegevoegd aan uw pijplijn.

Het is ook mogelijk om andere soorten tests uit te voeren vanuit een implementatiepijplijn, waaronder prestatietests en beveiligingspenetratietests. Deze tests vallen buiten het bereik van deze module, maar ze kunnen waarde toevoegen aan een geautomatiseerd implementatieproces.

Terugdraaien of vooruitdraaien

Stel dat uw pijplijn uw resources met succes implementeert, maar dat uw tests mislukken. Wat moet je dan doen?

Eerder in deze module hebt u geleerd dat u met Azure Pipelines terugdraaifasen kunt maken die worden uitgevoerd wanneer een vorige fase mislukt. U kunt deze methode gebruiken om een terugdraaifase te maken wanneer uw testfase een onverwacht resultaat rapporteert. U kunt uw wijzigingen ook handmatig terugdraaien of de hele pijplijn opnieuw uitvoeren als u denkt dat de fout is veroorzaakt door een tijdelijk probleem dat sindsdien is opgelost.

Notitie

Wanneer u een implementatie naar Azure Resource Manager verzendt, kunt u aanvragen dat Resource Manager uw laatste geslaagde implementatie automatisch opnieuw uitvoert als deze mislukt. Hiervoor moet u de Azure CLI-stap gebruiken om uw bestand te implementeren en de --rollback-on-error parameter toevoegen wanneer u de implementatie verzendt met behulp van de az deployment group create opdracht.

Het is vaak lastig om de stappen uit te werken die een terugdraaifase moet uitvoeren. Over het algemeen zijn Bicep-implementaties complex en het is niet eenvoudig om wijzigingen terug te draaien. Het is vooral moeilijk om terug te draaien wanneer uw implementatie andere onderdelen bevat.

Stel dat uw pijplijn een Bicep-bestand implementeert dat een Azure SQL-database definieert en vervolgens enkele gegevens toevoegt aan de database. Wanneer uw implementatie wordt teruggedraaid, moeten de gegevens worden verwijderd? Moet de database ook worden verwijderd? Het is moeilijk te voorspellen hoe elke fout en elke terugdraaiactie van invloed kunnen zijn op uw actieve omgeving.

Daarom kiezen veel organisaties ervoor om vooruit te rollen, wat betekent dat ze snel de reden voor de fout oplossen en vervolgens opnieuw implementeren. Door een geautomatiseerd implementatieproces van hoge kwaliteit te bouwen en door alle aanbevolen procedures te volgen die u tijdens deze leertrajecten hebt geleerd, kunt u snel problemen oplossen en uw Bicep-bestanden opnieuw implementeren en tegelijkertijd hoge kwaliteit behouden.

Tip