Testa dina resurser efter distributionen

6 minuter

Genom att verifiera och förhandsgranska Bicep-distributionen har du kunnat skapa förtroende för att Bicep-filerna kommer att distribueras. Men distribution är inte hela historien. När distributionen är klar är det också bra att kontrollera att distributionen gjorde det du förväntade dig.

I den här lektionen får du lära dig mer om tester som du kan köra när distributionen är klar. Du får också lära dig hur du återställer distributionen om det inte blir som förväntat.

Köra röktester och negativa tester

När du definierar resurser i en Bicep-fil är målet inte bara att skapa resurser i Azure. Det är för att leverera värde till din organisation samtidigt som organisationens krav uppfylls. När du verifierar och förhandsgranskar dina Bicep-filer får du förtroende för att resursdefinitionerna är giltiga, men du vet inte nödvändigtvis att resurserna faktiskt kommer att göra vad du vill.

Anta till exempel att du distribuerar en ny logisk Azure SQL-server med hjälp av en Bicep-distributionspipeline. Din Bicep-definition för servern är giltig, så den klarar linter- och preflight-valideringsstegen. Kommandot what-if visar att en server kommer att skapas, vilket är vad du förväntar dig. Distributionen har också slutförts. Men i slutet av distributionsprocessen kanske du fortfarande inte har någon fungerande databasserver som är redo att användas. Orsaker kan vara:

Du har inte konfigurerat brandväggsregler för att tillåta nätverkstrafik att nå servern.
Du har aktiverat Microsoft Entra-autentisering på servern när du inte borde ha gjort det, eller tvärtom.

Även när du bara distribuerar grundläggande Bicep-filer är det värt att överväga hur du kan verifiera att de resurser du distribuerar faktiskt fungerar och uppfyller dina krav. Här är exempel på hur du kan tillämpa den här principen:

När du distribuerar en webbplats kan du försöka nå webbprogrammet från din pipeline. Kontrollera att din pipeline ansluter till webbplatsen och får en giltig svarskod.
När du distribuerar ett nätverk för innehållsleverans (CDN) kan du försöka ansluta till en resurs via CDN. Kontrollera att pipelinen ansluter till CDN och tar emot en giltig svarskod.

Dessa tester kallas ibland för infrastrukturröktester. Röktestning är en enkel form av testning som är utformad för att upptäcka stora problem i distributionen.

Kommentar

Vissa Azure-resurser är inte lätta att nå från en Microsoft-värdbaserad pipelineagent. Du kan behöva överväga att använda en lokalt installerad agent för att köra rökteststeg om de kräver åtkomst till resurser via privata nätverk.

Det är också en bra idé att utföra negativa tester. Negativ testning hjälper dig att bekräfta att dina resurser inte har oönskade beteenden. När du till exempel distribuerar en virtuell dator är det bra att använda Azure Bastion för att ansluta på ett säkert sätt till den virtuella datorn. Du kan lägga till ett negativt test i pipelinen för att kontrollera att du inte kan ansluta till en virtuell dator direkt med hjälp av anslutning till fjärrskrivbord eller SSH.

Viktigt!

Målet med dessa tester är inte att verifiera att Bicep har distribuerat dina resurser korrekt. Genom att använda Bicep antar du att det distribuerar de resurser som du anger i dina Bicep-filer. Målet är i stället att kontrollera att de resurser som du har definierat fungerar för din situation och uppfyller dina krav.

Köra tester från Azure Pipelines

Det finns många sätt att köra tester i pipelinen. I den här modulen använder vi Pester, som är ett verktyg med öppen källkod som kör tester skrivna via PowerShell. Du kan välja att använda ett annat testramverk eller till och med välja att köra dina tester utan ett testverktyg. Ett annat testverktyg att överväga är till exempel PSRule för Azure, som innehåller fördefinierade regler och tester för Azure. Den kan köra validering på dina mallar och även köra tester mot dina distribuerade Azure-resurser. Vi länkar till PSRule i sammanfattningen.

När du använder ett testramverk som stöds förstår Azure Pipelines resultatet av varje test. Den visar testresultaten tillsammans med pipelinekörningsinformationen och spårar historiken för varje test över tid. I nästa övning får du se hur du kan använda Azure Pipelines med röktester för infrastruktur.

Skicka data mellan steg och steg

När du delar upp din pipeline i flera steg, var och en med sitt eget ansvar, måste du ibland skicka data mellan dessa steg. En fas kan till exempel skapa en Azure-resurs som en annan fas måste arbeta med. För att kunna skicka data måste den andra fasen känna till namnet på resursen som skapades. Till exempel måste vårt rökteststeg komma åt de resurser som distributionsfasen har distribuerat.

Bicep-filen distribuerar resurserna så att den kan komma åt resursegenskaperna och publicera dem när distributionen utdata. Du kan komma åt distributionsutdata i pipelinen. I Azure Pipelines finns det en särskild syntax för publicering av variabler för att göra dem tillgängliga i flera steg.

Först måste du publicera en utdatavariabel för en pipelinefas. Om du vill mata ut variabeln skriver du en särskilt formaterad sträng till pipelineloggen, som Azure Pipelines vet hur man förstår. I följande exempel anges en variabel med namnet myVariable till värdet myValue:

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

Azure Pipelines läser och tolkar strängen från pipelineloggen och gör variabelns värde tillgängligt som utdata. Du kan kombinera det här värdet med fler skript för att publicera ett Bicep-distributionsutdatavärde som en utdatavariabel för en pipelinefas. Du får se hur du gör det här skriptet i nästa övning.

För det andra måste du göra variabeln tillgänglig för ditt rökteststegs jobb. Du definierar en variabel för jobbet och använder en annan speciellt formaterad YAML-sträng:

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

Nu kan alla steg i röktestjobbet myVariable komma åt värdet som vilken annan variabel som helst med hjälp av syntaxen $(myVariable). Du använder en variabel i nästa övning.

Andra testtyper

Funktionstester och integreringstester används ofta för att verifiera att de distribuerade resurserna fungerar som förväntat. Ett integreringstest kan till exempel ansluta till din webbplats och skicka en testtransaktion och sedan vänta för att bekräfta att transaktionen har slutförts. Genom att använda integreringstester kan du testa lösningen som ditt team skapar, tillsammans med infrastrukturen som den körs på. I en framtida modul ser du hur dessa typer av tester kan läggas till i din pipeline.

Det är också möjligt att köra andra typer av tester från en distributionspipeline, inklusive prestandatester och säkerhetspenetreringstester. Dessa tester ligger utanför omfånget för den här modulen, men de kan ge mervärde till en automatiserad distributionsprocess.

Rulla tillbaka eller rulla framåt

Anta att din pipeline distribuerar dina resurser, men dina tester misslyckas. Vad ska du göra då?

Tidigare i den här modulen lärde du dig att Azure Pipelines gör att du kan skapa återställningsfaser som körs när en tidigare fas misslyckas. Du kan använda den här metoden för att skapa en återställningsfas när teststeget rapporterar ett oväntat resultat. Du kan också återställa ändringarna manuellt eller köra hela pipelinen igen om du tror att felet berodde på ett tillfälligt problem som sedan dess har lösts.

Kommentar

När du skickar en distribution till Azure Resource Manager kan du begära att Resource Manager automatiskt kör den senaste lyckade distributionen igen om den misslyckas. För att göra detta måste du använda Azure CLI-steget för att distribuera filen och lägga till parametern --rollback-on-error när du skickar distributionen med hjälp az deployment group create av kommandot .

Det är ofta svårt att komma fram till de steg som en återställningsfas ska utföra. I allmänhet är Bicep-distributioner komplexa och det är inte lätt att återställa ändringar. Det är särskilt svårt att återställa när distributionen innehåller andra komponenter.

Anta till exempel att din pipeline distribuerar en Bicep-fil som definierar en Azure SQL-databas och sedan lägger till vissa data i databasen. Ska data tas bort när distributionen återställs? Ska databasen också tas bort? Det är svårt att förutsäga hur varje fel och varje återställning kan påverka din miljö som körs.

Därför föredrar många organisationer att gå vidare, vilket innebär att de snabbt åtgärdar orsaken till felet och sedan distribuerar igen. Genom att skapa en automatiserad distributionsprocess av hög kvalitet och genom att följa alla metodtips som du har lärt dig under de här utbildningsvägarna kan du snabbt åtgärda problem och distribuera om dina Bicep-filer samtidigt som du bibehåller hög kvalitet.

Dricks