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.

Du kan använda faser i pipelinen för att markera en avgränsning av ansvarsområden. 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).

Under CI-faserna kontrollerar du giltigheten för de ändringar som har gjorts i koden. CI-faser ger kvalitetssäkring. Du kan köra dem utan att påverka din produktionsmiljö.

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-steg har körts framgångsrikt bör du känna dig mer säker på att de ändringar du har gjort också kommer att distribueras lyckat. Under CD-faser distribuerar du koden till var och en av dina miljöer. Du börjar vanligtvis med testmiljöer och andra icke-produktionsmiljöer och fortsätter sedan till produktionsmiljöer. I den här modulen distribuerar du 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. Till exempel kan du konfigurera CD-faserna så att de bara körs efter att CI-faserna har körts framgångsrikt. Eller så kan du ha flera CI-steg som måste köras i följd, till exempel för att skapa din kod och sedan testa den. Du kan också inkludera en återställningsfas som endast körs om tidigare distributionssteg misslyckas.

Flytta åt vänster

Genom att använda steg kan du kontrollera kodens kvalitet innan du distribuerar den. Att använda dessa steg kallas ibland vänsterflyttning.

Överväg en tidslinje för de aktiviteter som du utför när du skriver kod. Tidslinjen börjar med planerings- och designfaserna. Sedan flyttas den till bygg- och testfaserna. Slutligen distribuerar och stöder du din lösning. Följande diagram visar dessa steg på en tidslinje.

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äl förstådd regel i programvaruutveckling att du tidigare i processen hittar ett fel (ju närmare till vänster på 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 i diagrammet. 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-förfrågan är redo att slås ihop.

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 pipelinen bara har en 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 filen 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 som har ett valideringssteg, en distributionsfas i USA och en Distribuera Europa-fas i den ordningen.

Observera att det här exemplet har tre steg. Valideringssteget liknar ett CI-stadium. Faserna DeployUS och DeployEurope körs härnäst. 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 lyckas. 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 USA-fas och en Distribuera Europa-fas. De två distributionsfaserna körs 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 är uppfyllda 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.

Du kanske vill 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 som har ett deploy-steg och ett villkor så att ett fel i deploy-steget leder till att ett rollback-steg 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 startar 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 i Azure Resource Manager för att söka efter problem som kan uppstå under distributionen.
Förhandsversion: Använd kommandot what-if för att verifiera en lista över ändringar som ska tillämpas mot din Azure-miljö. Låt en människa granska konsekvensanalysen manuellt och godkänna pipelinen innan den fortsätter.
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:

Hur pipelines stoppar distributionsprocessen om något oväntat händer under någon av de föregående stegen.
Så här konfigurerar du din pipeline så att den pausas tills du manuellt verifierar vad som hände i en tidigare fas.