Uw resources testen na de implementatie

6 minuten

Door uw Bicep-implementatie te valideren en te bekijken, kon 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, terwijl het voldoet 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-implementatiewerkstroom. Uw Bicep-definitie voor de server is geldig, dus geeft deze de linter- en preflight-validatietaken door. 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 werkstroom. Controleer of uw werkstroom 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 werkstroom 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 door GitHub gehoste hardlopers. Mogelijk moet u overwegen om een zelf-hostende runner te gebruiken om betrouwbaarheidstesttaken uit te voeren als ze toegang nodig hebben tot resources via particuliere 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 werkstroom 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, werken voor uw situatie en voldoen aan uw vereisten.

Tests uitvoeren vanuit GitHub-werkstromen

Er zijn veel manieren waarop u tests in uw werkstroom kunt uitvoeren. In deze module gebruiken we Pester, een opensource-hulpprogramma waarmee tests worden uitgevoerd die zijn geschreven via PowerShell. Pester is vooraf geïnstalleerd op door GitHub gehoste hardlopers. U hoeft niets speciaals te doen om deze in een scriptstap te gebruiken.

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. We koppelen aan PSRule in de samenvatting.

Wanneer u tests uitvoert vanuit een werkstroom, moeten eventuele testfouten ervoor zorgen dat de werkstroom niet meer wordt voortgezet. In de volgende oefening ziet u hoe u werkstromen kunt gebruiken met betrouwbaarheidstests voor infrastructuur.

Testresultaten worden naar het werkstroomlogboek geschreven. GitHub Marketplace bevat ook niet-Microsoft-acties waarmee testresultaten in de loop van de tijd kunnen worden weergegeven en bijgehouden.

Gegevens doorgeven tussen taken

Wanneer u uw werkstroom opsplitst in meerdere taken, elk met een eigen verantwoordelijkheid, moet u soms gegevens doorgeven tussen deze taken. Eén taak kan bijvoorbeeld een Azure-resource maken waarmee een andere taak moet werken. Als u gegevens wilt doorgeven, moet de tweede taak de naam weten van de resource die is gemaakt. Onze betrouwbaarheidstesttaak moet bijvoorbeeld toegang hebben tot de resources die door de implementatietaak zijn geïmplementeerd.

Uw Bicep-bestand implementeert de resources, zodat het toegang heeft tot de resource-eigenschappen en deze als implementatie-uitvoer kan publiceren. Wanneer u uw Bicep-implementatie uitvoert via de arm-deploy actie, worden deze Bicep-implementatie-uitvoer opgeslagen in de uitvoer van de stappen. Vervolgens kan de taak met de arm-deploy actie deze stapuitvoer publiceren als taakuitvoer. De taak verwijst naar de eigenschap van id de stap, die we hebben ingesteld op 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 }}

U hebt toegang tot de uitvoer van een taak in elke volgende taak, zolang deze afhankelijk is van de taak die de uitvoer produceert:

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

U kunt ook uitvoer van een werkstroomscript doorgeven met behulp van een speciale syntaxis. We koppelen een koppeling naar meer informatie in de samenvatting.

Andere testtypen

Functionele tests en integratietests worden vaak gebruikt om te controleren of de geïmplementeerde resources zich gedragen 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 werkstroom.

Het is ook mogelijk om andere soorten tests uit te voeren vanuit een implementatiewerkstroom, 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 werkstroom 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 GitHub Actions terugdraaitaken kunt maken die worden uitgevoerd wanneer een vorige taak mislukt. U kunt deze methode gebruiken om een terugdraaitaak te maken wanneer uw testtaak een onverwacht resultaat rapporteert. U kunt uw wijzigingen ook handmatig terugdraaien of de hele werkstroom opnieuw uitvoeren als u denkt dat de fout is veroorzaakt door een tijdelijk probleem dat al 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. Gebruik hiervoor de --rollback-on-error parameter wanneer u de implementatie verzendt met behulp van de Azure CLI-opdracht az deployment group create .

U kunt bijvoorbeeld een terugdraaitaak toevoegen aan uw werkstroom. De terugdraaitaak wordt uitgevoerd wanneer de betrouwbaarheidstesttaak mislukt:

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

De taak is afhankelijk van de betrouwbaarheidstest. Deze wordt alleen uitgevoerd wanneer de betrouwbaarheidstest mislukt. GitHub Actions stopt de werkstroom standaard wanneer een vorige taak mislukt. De if voorwaarde bevat een always() controle om dit gedrag te overschrijven. Zonder de always() expressie wordt de terugdraaitaak overgeslagen wanneer een eerdere taak mislukt.

Het is vaak lastig om de stappen uit te voeren die een terugdraaitaak 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 werkstroom 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 terwijl u hoge kwaliteit behoudt.

Tip

Een van de principes van een DevOps-mindset is het leren van fouten. Als u een implementatie wilt terugdraaien, moet u zorgvuldig overwegen waarom de fout is opgetreden en geautomatiseerde tests toevoegen voordat uw implementatie wordt gestart om hetzelfde probleem te detecteren als dit in de toekomst gebeurt.