Förstå pipelinesteg

7 minuter

Med pipelines kan du automatisera stegen i distributionsprocessen. Processen kan innehålla flera logiska grupper med jobb som du vill köra. I den här lektionen får du lära dig mer om pipelinesteg och hur du använder dem för att lägga till kvalitetskontrollprocesser i dina Bicep-distributioner.

Vad är pipelinesteg?

Steg hjälper dig att dela upp din pipeline i flera logiska block. Varje steg kan innehålla ett eller flera jobb. Jobb innehåller en ordnad lista med steg som ska slutföras, som att köra kommandoradsskript.

Diagram som visar en pipeline med ett steg som innehåller ett jobb. Jobbet innehåller fyra steg.

Steg kan användas i pipelinen för att markera en separation av problem. När du till exempel arbetar med Bicep-kod är validering av koden ett separat problem än att distribuera Bicep-filen. När du använder en automatiserad pipeline kallas det ofta kontinuerlig integrering (CI) för att skapa och testa koden. Distribution av kod i en automatiserad pipeline kallas ofta kontinuerlig distribution (CD).

I CI-steg kontrollerar du giltigheten för de ändringar som har gjorts i koden. CI-faser ger kvalitetssäkring. De kan köras utan att påverka din liveproduktionsmiljö.

På många programmeringsspråk måste kod skapas innan någon kan köra den. När en Bicep-fil distribueras konverteras den, eller överförs, från Bicep till JSON. Verktyget utför den här processen automatiskt. I de flesta fall behöver du inte manuellt skapa Bicep-kod till JSON-mallar i din pipeline. Vi använder fortfarande termen kontinuerlig integrering när vi pratar om Bicep-kod, eftersom de andra delarna av CI fortfarande gäller, till exempel verifiering av din kod.

När dina CI-faser har körts bör du ha ökat ditt förtroende för att även de ändringar du har gjort kommer att distribueras. I CD-faser distribuerar du koden till var och en av dina miljöer. Du börjar vanligtvis med testmiljöer och andra miljöer som inte är produktionsmiljöer och går vidare till produktionsmiljöer. I den här modulen distribuerar vi till en enda miljö. I en framtida modul får du lära dig hur du utökar distributionspipelinen till att distribuera till flera miljöer, till exempel icke-produktions- och produktionsmiljöer.

Faser körs i en sekvens. Du kan styra hur och när varje steg körs. Du kan till exempel konfigurera dina CD-faser så att de bara körs när dina CI-faser har körts. Eller så kan du ha flera CI-steg som måste köras i följd, till exempel för att skapa koden och sedan testa den. Du kan också inkludera en återställningsfas som endast körs om tidigare distributionssteg misslyckades.

Flytta åt vänster

Genom att använda steg kan du kontrollera kodens kvalitet innan du distribuerar den. De här stegen kallas ibland för att skifta åt vänster.

Överväg en tidslinje för de aktiviteter som du utför när du skriver kod. Tidslinjen börjar från planerings- och designfaserna. Sedan flyttas den till bygg- och testfaserna. Slutligen distribuerar du och måste sedan stödja din lösning.

Diagram med en tidslinje på den vågräta axeln, kostnad på den lodräta axeln och en rad som visar att kostnaden ökar ju senare ett fel identifieras.

Det är en välförstådd regel i programvaruutveckling som du tidigare i processen hittade ett fel (ju närmare till vänster om tidslinjen), desto enklare, snabbare och billigare är det att åtgärda. Ju senare i processen du får ett fel, desto svårare är det att åtgärda.

Målet är därför att flytta identifieringen av problem till vänster om föregående diagram. I den här modulen får du se hur du kan lägga till mer validering och testning i pipelinen allt eftersom.

Du kan till och med lägga till validering i god tid innan distributionen börjar. När du arbetar med verktyg som Azure DevOps representerar pull-begäranden vanligtvis ändringar som någon i ditt team vill göra i koden på huvudgrenen. Det är bra att skapa en annan pipeline som automatiskt kör dina CI-steg under granskningsprocessen för pull-begäran. Den här tekniken hjälper till att verifiera att koden fortfarande fungerar, även med de föreslagna ändringarna. Om valideringen lyckas kan du vara säker på att ändringen inte orsakar problem när den sammanfogas till huvudgrenen. Om kontrollen misslyckas vet du att det finns mer arbete att göra innan pull-begäran är redo att slås samman.

Viktigt!

Automatiserad validering och tester är bara lika effektiva som de tester du skriver. Det är viktigt att tänka på de saker du behöver testa och de steg du behöver utföra för att vara säker på att distributionen är OK.

Definiera en pipelinefas

Varje pipeline innehåller minst ett steg. Om din pipeline bara har en enda fas behöver du inte uttryckligen definiera den. Azure Pipelines definierar det automatiskt åt dig. När du har flera steg i en pipeline måste du definiera var och en. Faser körs i en sekvens som du anger.

Anta att du har skapat en Bicep-fil som du behöver distribuera två gånger: en gång till infrastruktur i USA och en gång till infrastruktur i Europa. Innan du distribuerar verifierar du Bicep-koden. Här är en bild av en pipeline för flera steg som definierar den här processen:

Diagram som visar en pipeline med ett Valideringssteg, en Distribuera U S-fas och en Deploy Europe-fas som körs i följd.

Observera att det här exemplet har tre steg. Valideringssteget liknar ett CI-stadium. Sedan körs faserna DeployUS och DeployEurope . Var och en distribuerar koden till en av miljöerna.

Så här definieras stegen i en YAML-pipelinefil:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

Kontrollera sekvensen av faser

Som standard körs stegen i den ordning som du definierar. En fas körs endast om den föregående fasen lyckades. Du kan lägga till beroenden mellan stegen för att ändra ordningen.

Om du fortsätter med föregående exempel kan du tänka dig att du vill köra båda distributionerna parallellt, så här:

Diagram som visar en pipeline med ett valideringssteg, en Distribuera U S-fas och en Distribution Europa-fas, med de två distributionsstegen igång parallellt.

Du kan ange beroenden mellan faser med hjälp av nyckelordet dependsOn :

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

När du använder nyckelordet dependsOn väntar Azure Pipelines på att den beroende fasen ska slutföras innan nästa steg påbörjas. Om Azure Pipelines upptäcker att alla beroenden för flera steg har uppfyllts kan de köras parallellt.

Kommentar

I verkligheten körs faser och jobb parallellt endast om du har tillräckligt med agenter för att köra flera jobb samtidigt. När du använder Microsoft-värdbaserade agenter kan du behöva köpa ytterligare parallella jobb för att uppnå detta.

Ibland vill du köra en fas när en tidigare fas misslyckas. Här är till exempel en annan pipeline. Om distributionen misslyckas körs ett steg med namnet Återställning omedelbart efteråt:

Diagram som visar en pipeline med en distributionsfas och ett villkor så att ett fel i distributionssteget resulterar i att återställningsfasen körs.

Du kan använda nyckelordet condition för att ange ett villkor som ska uppfyllas innan en fas körs:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

I föregående exempel, när allt går bra, kör Azure Pipelines fasen Validate först och kör sedan distributionssteget. Den hoppar över återställningssteget. Men om distributionssteget misslyckas kör Azure Pipelines återställningsfasen. Du får lära dig mer om återställning senare i den här modulen.

Varje jobb körs på en ny agent. Det innebär att varje jobb börjar från en ren miljö, så i varje jobb behöver du vanligtvis checka ut källkoden som ditt första steg.

Bicep-distributionssteg

En typisk Bicep-distributionspipeline innehåller flera steg. När pipelinen rör sig genom stegen är målet att bli alltmer säker på att de senare stegen kommer att lyckas. Här är de vanliga stegen för en Bicep-distributionspipeline:

Diagram som visar en Bicep-distributionspipeline med fem steg: Lint, Validate, Preview, Deploy och Smoke Test.

Lint: Använd Bicep-lintern för att verifiera att Bicep-filen är väl utformad och inte innehåller några uppenbara fel.
Verifiera: Använd valideringsprocessen för Förhandstestning i Azure Resource Manager för att söka efter problem som kan uppstå när du distribuerar.
Förhandsversion: Använd kommandot what-if för att verifiera listan över ändringar som ska tillämpas mot din Azure-miljö. Be en människa att manuellt granska konsekvensresultatet och godkänna pipelinen för att fortsätta.
Distribuera: Skicka distributionen till Resource Manager och vänta tills den har slutförts.
Röktest: Kör grundläggande kontroller efter distributionen mot några av de viktiga resurser som du har distribuerat. Dessa granskningar kallas infrastrukturröktester.

Din organisation kan ha en annan sekvens med steg, eller så kan du behöva integrera dina Bicep-distributioner i en pipeline som distribuerar andra komponenter. När du förstår hur stegen fungerar kan du utforma en pipeline som passar dina behov.

I den här modulen lär du dig mer om de steg som anges här, och du skapar gradvis en pipeline som innehåller varje steg. Du får också lära dig: