Utforma pipelinen

Slutförd

I den här lektionen följer du Tailspin-webbteamet när de definierar deras lanseringspipeline för webbplatsen Space Game.

När du planerar en versionspipeline börjar du vanligtvis med att identifiera de faserna, eller större divisioner, i den pipelinen. Varje steg mappar vanligtvis till en miljö. I den föregående modulen hade till exempel Andy och Maras grundläggande pipeline en Deploy-fas som mappades till en Azure App Service-instans.

I den här modulen du främja ändringar från ett stadie till nästa. I varje fas du distribuera webbplatsen Space Game till miljön som är associerad med den fasen.

När du har definierat vilka steg du behöver bör du fundera på hur ändringarna höjs upp från en fas till en annan. Varje steg kan definiera de framgångsvillkor som måste uppfyllas innan bygget kan flyttas till nästa steg. Azure Pipelines innehåller flera sätt att styra hur och när ändringar flyttas genom pipelinen. Som helhet används dessa metoder för versionshantering.

I det här avsnittet ska du:

• Lär dig skillnaderna mellan vanliga pipelinesteg, till exempel Build, Dev, Testoch Staging.
• Förstå hur du använder manuella, schemalagda och kontinuerliga utlösare för att styra när en artefakt flyttas till nästa steg i pipeline.
• Se hur ett versionsgodkännande pausar pipelinen tills en godkännare accepterar eller avvisar versionen.

Mötet

Hela Tailspin-webbteamet samlas. I Skapa en versionspipeline med Azure Pipelinesplanerade teamet sina uppgifter för den aktuella sprinten. Varje uppgift har att göra med att bygga deras versionspipeline för webbplatsen Space Game.

Kom ihåg att teamet bestämde sig för dessa fem uppgifter för sin sprint:

• Skapa en flerfasrörledning.
• Anslut webbappen till en databas.
• Automatisera kvalitetstester.
• Automatisera prestandatester.
• Förbättra utgivningstakten.

Teamet träffas för att prata om den första uppgiften Skapa en flerstegs pipeline. När teamet har definierat pipelinen kan det gå från sitt grundläggande proof of concept till en releasepipeline som innehåller fler steg, kvalitetskontroller och godkännanden.

Amita och Tim tittar på Andy och Mara som demonstrerar distributionspipelinen en andra gång. De ser att artefakten har skapats och installerats på App Service.

Vilka pipelinesteg behöver du?

När du vill implementera en versionspipeline är det viktigt att först identifiera vilka steg du behöver. Vilka steg du väljer beror på dina krav. Låt oss följa med teamet när de bestämmer sig för sina steg.

Tim: OK, jag förstår tanken på en automatiserad pipeline. Jag gillar hur det är enkelt att distribuera till Azure. Men vart ska vi gå från den här demonstrationen? Vi behöver något som vi faktiskt kan använda för våra utgåvor.

Amita: Ja! Vi måste lägga till andra steg. För närvarande har vi till exempel ingen plats för ett teststeg.

Tim: Plus behöver vi en scen där vi kan visa nya funktioner för ledningen. Jag kan inte skicka något till produktion utan hanteringsgodkännande.

Andy: Absolut! Nu när vi har koll på vad en versionslinje gör, hur får vi den här pipelinen att göra det vi behöver?

Mara: Låt oss skissa på våra krav för att hjälpa oss att planera våra nästa steg. Vi börjar med det vi har.

Mara flyttar till whiteboarden och skissar den befintliga pipelinen.

Mara: Steget Build skapar källkoden och skapar ett paket. I vårt fall är paketet en .zip fil. Steget Deploy installerar filen .zip, som är Space Game-webbplatsen, på en App Service-instans. Vad saknas i vår utgivningspipeline?

Lägg till Utvecklingssteget

Andy: jag kanske är partisk, men jag tror att vi behöver en Dev fas. Det här steget bör vara det första stoppet för artefakten när den har skapats. Utvecklare kan inte alltid köra hela tjänsten från sin lokala utvecklingsmiljö. Ett e-handelssystem kan till exempel kräva en webbplats, produktdatabas och ett betalningssystem. Vi behöver en fas som innehåller allt som appen behöver.

I vårt fall läser leaderboard-funktionen på Space Game-webbplatsen in toppoäng från en extern källa. Just nu läser den in fiktiva poäng från en fil. Att konfigurera en Dev-fas skulle ge oss en miljö där vi kan integrera webbappen med en riktig databas. Den databasen kanske fortfarande innehåller fiktiva poäng, men den för oss ett steg närmare vår slutliga app.

Mara: jag gillar det. Vi kommer inte att integrera med en riktig databas än. Men i en Dev-fas kan vi distribuera till en miljö där vi kan lägga till en databas.

Mara uppdaterar sin ritning på whiteboarden. Hon ersätter "Deploy" med "Dev" för att visa Dev-fasen.

Andy: Du tar upp en intressant punkt. Vi skapar appen varje gång vi skickar en ändring till GitHub. Betyder det att varje version befordras till Dev-fasen när den har slutförts?

Mara: Building ger oss kontinuerligt viktig feedback om vår bygg- och testhälsa. Men vi vill bara flytta upp till Dev-fasen när vi sammanfogar kod till någon central gren: antingen huvudgren eller någon annan versionsgren. Jag uppdaterar ritningen för att visa det kravet.

Mara: jag tror att denna befordran kommer att vara lätt att åstadkomma. Vi kan definiera ett -villkor som endast befordras till Dev-fasen när ändringar sker på en versionsgren.

Vad är villkor?

I Azure Pipelines använder ett villkor för att köra uppgift eller jobb baserat på pipelinens tillstånd. Du arbetade med villkor i tidigare moduler.

Kom ihåg att några av de villkor som du kan ange är:

• Endast när alla tidigare beroende uppgifter har slutförts.
• Även om ett tidigare beroende har misslyckats, såvida inte körningen avbröts.
• Även om ett tidigare beroende har misslyckats, även om körningen avbröts.
• Endast när ett tidigare beroende har misslyckats.
• Vissa anpassade villkor.

Här är ett grundläggande exempel:

steps:
  - script: echo Hello!
    condition: always()

Villkoret always() gör att den här aktiviteten skriver ut "Hello!" villkorslöst, även om tidigare aktiviteter misslyckades.

Det här villkoret används om du inte anger något villkor:

condition: succeeded()

Den succeeded() inbyggda funktionen kontrollerar om den tidigare uppgiften lyckades. Om den föregående aktiviteten misslyckas hoppas den här aktiviteten och senare aktiviteter som använder samma villkor över.

Här vill du skapa ett villkor som anger:

• Föregående uppgift lyckades.
• Namnet på den aktuella Git-grenen är version.

Om du vill skapa det här villkoret använder du den inbyggda funktionen and(). Den här funktionen kontrollerar om var och en av dess villkor är sanna. Om något villkor inte är sant misslyckas det övergripande villkoret.

Om du vill hämta namnet på den aktuella grenen använder du den inbyggda Build.SourceBranchName variabeln. Du kan komma åt variabler inom ett villkor på några olika sätt. Här använder du syntaxen för variables[].

Om du vill testa en variabels värde kan du använda den inbyggda funktionen eq(). Den här funktionen kontrollerar om argumenten är lika.

Med det i åtanke tillämpar du det här villkoret för att köra Dev-fasen endast när det aktuella grennamnet är "release".

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

Det första villkoret i funktionen and() kontrollerar om den föregående uppgiften lyckades. Det andra villkoret kontrollerar om det aktuella grennamnet är lika med version.

I YAML använder du pipe-syntaxen (|) för att definiera en sträng som sträcker sig över flera rader. Du kan definiera villkoret på en enda rad, men vi skriver det på det här sättet för att göra det mer läsbart.

Anteckning

I den här modulen använder vi -versionen av-grenen som exempel. Du kan kombinera villkor för att definiera det beteende som du behöver. Du kan till exempel skapa ett villkor som endast kör steget när bygget utlöses av en pull-begäran mot huvudbranch.

I nästa lektion, när du konfigurerar Dev-fasen, arbetar du med ett mer komplett exempel.

För en mer komplett beskrivning av villkor i Azure Pipelines, se dokumentationen om uttryck.

Mara: Med hjälp av villkor kan du styra vilka ändringar som flyttas upp till vilka steg. Vi kan skapa en byggartefakt för alla ändringar för att verifiera vår version och bekräfta att den är felfri. När vi är klara kan vi sammanfoga ändringarna till en versionsgren och flytta upp den versionen till Dev-fasen.

Lägg till teststeget

Mara: Hittills har vi faserna Build och Dev. Vad kommer härnäst?

Amita: Kan vi lägga till Test nästa steg? Det verkar vara rätt plats för mig att testa de senaste ändringarna.

Mara lägger till Test fasen till sin ritning på whiteboarden.

Amita: Ett problem jag har är hur ofta jag behöver testa appen. Ett e-postmeddelande meddelar mig när Mara eller Andy gör en ändring. Förändringar sker under dagen, och jag vet aldrig när jag ska hoppa in. Jag tror att jag skulle vilja se ett bygge en gång om dagen, kanske när jag kommer in på kontoret. Kan vi göra det?

Andy: Visst. Varför distribuerar vi inte till Test under lediga timmar? Låt oss säga att vi skickar dig en programversion varje dag klockan 03.00.

Mara: Det låter bra. Vi kan alltid utlösa processen manuellt om vi behöver det. Vi kan till exempel utlösa den om du behöver verifiera en viktig felkorrigering direkt.

Mara uppdaterar sin ritning för att visa att bygget flyttas från Dev-stadiet till Test-fasen klockan 03.00 varje morgon.

Vad är utlösare?

Amita: jag mår bättre nu när vi vet hur en fas flyttas till en annan. Men hur styr vi när en fas körs?

Mara: I Azure Pipelines kan vi använda utlösare. En utlösare definierar när en fas körs. Azure Pipelines innehåller några typer av utlösare. Här är våra val:

• Utlösare för kontinuerlig integrering (CI)
• Utlösning av pull-begäran (PR)
• Schemalagd utlösare
• Utlösare för byggnadsslutförande

Med CI- och PR-utlösare kan du styra vilka grenar som deltar i den övergripande processen. Du vill till exempel skapa projektet när en ändring görs i en gren. En schemalagd utlösare startar en distribution vid en viss tidpunkt. En avslutande utlösare kör ett bygge när en annan byggprocess, till exempel en för en beroende komponent, har slutförts framgångsrikt. Det verkar som om vi vill ha en schemalagd utlösare.

Vad är schemalagda utlösare?

En schemalagd utlösare använder cron-syntax för att orsaka att en version körs enligt ett definierat schema.

I Unix- och Linux-system är cron ett populärt sätt att schemalägga jobb att köras med ett visst tidsintervall eller vid en viss tidpunkt. I Azure Pipelines använder schemalagda utlösare cron-syntaxen för att definiera när en fas körs.

Ett cron-uttryck innehåller fält som matchar vissa tidsparametrar. Här är fälten:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Det här cron-uttrycket beskriver till exempel "03.00 varje dag": 0 3 * * *

Ett cron-uttryck kan innehålla specialtecken för att ange en lista med värden eller ett värdeintervall. I det här exemplet matchar asterisken (*) alla värden för fälten Days, Monthsoch Days of week.

Det här cron-uttrycket ser ut så här:

• Vid minut 0,
• Vid den tredje timmen
• Vilken dag som helst i månaden
• Vilken månad som helst
• Vilken dag som helst i veckan
• Kör jobbet

Om du bara vill ange 03.00 dagar måndag till fredag använder du det här uttrycket: 0 3 * * 1-5

Not

Tidszonen för cron-scheman är Coordinated Universal Time (UTC), så i det här exemplet refererar 3 A.M. till 3 A.M. i UTC. I praktiken kanske du vill justera tiden i cron-schemat i förhållande till UTC så att pipelinen körs vid den förväntade tidpunkten för dig och ditt team.

Om du vill konfigurera en schemalagd utlösare i Azure Pipelines behöver du ett schedules avsnitt i YAML-filen. Här är ett exempel:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

I det här schedules avsnittet:

• cron specificerar cron-uttrycket.
• branches anger att endast distribuera från release-grenen.
• always anger om distributionen ska köras villkorslöst (true), eller bara när release-grenen har ändrats sedan den senaste körningen (false). Här anger du false eftersom du bara behöver distribuera när release-grenen har ändrats sedan den senaste körningen.

Hela pipelinen körs när Azure Pipelines kör en schemalagd utlösare. Pipelinen körs även vid andra tillfällen, till exempel när du pushar en ändring till GitHub. Om du bara vill köra en fas som svar på en schemalagd utlösare kan du använda ett villkor som kontrollerar om orsaken till bygget är en schemalagd körning.

Här är ett exempel:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Den här fasen, Test, körs endast när föregående steg lyckas och den inbyggda Build.Reason pipelinevariabeln är lika med Schedule.

Du ser ett mer komplett exempel senare i den här modulen.

Amita: jag gillar det här. Jag behöver inte ens plocka upp versionen manuellt och installera den. Den är redo för mig.

Andy: Och kom ihåg att om vi vill automatisera mer senare kan vi det. Inget är skrivet i sten. Pipelinen utvecklas samtidigt som vi förbättrar och lär oss.

Lägg till mellanlagringssteget

Tim: Det är min tur. Jag behöver en fas för att köra fler stresstester. Vi behöver också ett steg där vi kan demonstrera för ledningen för att få deras godkännande. För tillfället kan vi kombinera de två behoven i en fas som vi kan kalla Staging.

Andy: Bra sagt, Tim. Det är viktigt att ha en mellanlagringsmiljöeller förproduktionsmiljö. Den här mellanlagringsmiljön är ofta det sista stoppet innan en funktion eller buggkorrigering når våra användare.

Mara lägger till Staging till sin ritning på whiteboarden.

Amita: Vi använder en schemalagd utlösare för att höja upp ändringar från fasen Dev till Test-fasen. Men hur främjar vi ändringar från Test till Staging? Måste befordran också ske enligt ett schema?

Mara: jag tror att det bästa sättet att hantera det skulle vara ett släppgodkännande. Med ett versionsgodkännande kan du manuellt höja upp en ändring från en fas till en annan.

Amita: Det låter som exakt vad jag behöver! Ett versionsgodkännande skulle ge mig tid att testa de senaste ändringarna innan vi presenterar bygget för hantering. Jag kan höja upp bygget när jag är redo.

Mara uppdaterar sin ritning för att visa att bygget flyttas från Test till Staging endast när Amita godkänner det.

Tim: Jag kan också föreställa mig att vi använder utgivningsgodkännanden för att flytta från Mellanlagring till Produktion efter att ledningen har godkänt det. Jag kan aldrig förutsäga hur lång tid det tar. Efter att de har signerat kan jag godkänna versionen och flytta upp den till produktion manuellt. Men hur funkar godkännanden för släpp?

Vad är versionsgodkännanden?

Ett versionsgodkännande är ett sätt att pausa pipelinen tills en godkännare accepterar eller avvisar versionen. Om du vill definiera ditt versionsarbetsflöde kan du kombinera godkännanden, villkor och utlösare.

Kom ihåg att i Skapa en versionspipeline med Azure Pipelinesdefinierade du en miljö i pipelinekonfigurationen för att representera distributionsmiljön. Här är ett exempel från din befintliga pipeline:

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

Din miljö kan innehålla specifika kriterier för din version. Kriterierna kan ange vilka pipelines som kan driftsättas till den miljön och vilka mänskliga godkännanden som krävs för att främja övergången av releasen från ett steg till nästa.

Senare i den här modulen definierar du mellanlagring miljö och tilldelar dig själv som godkännare för att höja upp webbappen Space Game från Test-fasen till Mellanlagring.

Automatisera så lite eller så mycket du behöver

Azure Pipelines ger dig flexibiliteten att automatisera vissa faser samtidigt som du manuellt styr de faser som inte är redo för automatisering.

Tim: jag gillar hur vi kan definiera de kriterier som främjar förändringar från en fas till en annan. Men vi definierade några manuella kriterier i pipelinen. Jag trodde DevOps handlade om att automatisera allt.

Mara: Du tar upp en bra poäng. DevOps handlar egentligen om att automatisera repetitiva och felbenägna uppgifter. Ibland är mänsklig inblandning nödvändig. Vi får till exempel godkännande från hanteringen innan vi släpper nya funktioner. När vi får mer erfarenhet av våra automatiserade distributioner kan vi automatisera fler av våra manuella steg för att påskynda processen. Vi kan till exempel automatisera fler kvalitetskontroller i Test-fasen, så Amita behöver inte godkänna varje version.

Tim: Låter bra. Nu ska vi gå vidare med den här planen och se hur vi kan påskynda systemet senare.

Amita: På tal om vår plan, kan vi sammanfatta nästa steg?

Planen

Nu ska vi gå igenom Tailspin-teamets plan när de går mot nästa steg.

Mara: Här är den release-pipeline som vi vill skapa.

Mara pekar på whiteboarden.

Mara: För att sammanfatta är våra steg att:

1. Skapa en byggartefakt varje gång vi skickar en ändring till GitHub. Det här steget sker i fasen Build.
2. Flytta upp byggartefakten till fasen Dev. Det här steget sker automatiskt när byggsteget lyckas och ändringen befinner sig på versionsgrenen.
3. Flytta upp byggartefakten till Test-fasen varje morgon kl. 03.00. Vi använder en schemalagd utlösare för att höja upp byggartefakten automatiskt.
4. Främja byggartefakten till Staging efter att Amita testar och godkänner byggnaden. Vi använder ett versionsgodkännande för att främja byggartefakten.

När ledningen har godkänt bygget kan vi utrullera byggarartefakten till en produktionsmiljö.

Amita: Kommer det här att bli svårt att göra? Det verkar vara mycket arbete.

Mara: jag tycker inte att det är så illa. Varje steg är separat från alla andra steg. Faserna är diskreta. Varje fas har en egen uppsättning uppgifter. Vad som till exempel händer i Test-fasen finns kvar i Test-fasen.

Varje distributionssteg i pipelinen har också en egen miljö. När vi till exempel distribuerar appen till Dev eller Testär miljön en App Service-instans.

Slutligen testar vi bara en version i taget. Vi ändrar aldrig versioner mitt i pipelinen. Vi använder samma version i Dev-fasen som i Staging-fasen, och varje version har ett eget versionsnummer. Om utgåvan bryts i en av faserna korrigerar vi den och bygger om den med ett nytt versionsnummer. Den nya versionen går sedan igenom pipelinen från början.

Några ord om kvalitet

Du såg just teamet utforma en pipeline som tar deras app hela vägen från bygge till mellanlagring. Hela poängen med den här pipelinen är inte bara att göra deras liv enklare. Det är för att säkerställa kvaliteten på den programvara som de levererar till sina kunder.

Hur mäter du kvaliteten på din lanseringsprocess? Det går inte att mäta kvaliteten på lanseringsprocessen direkt. Det du kan mäta är hur bra processen fungerar. Om du ständigt ändrar processen kan det vara en indikation på att något är fel. Versioner som misslyckas konsekvent vid en viss punkt i pipelinen kan också tyda på att det finns ett problem med lanseringsprocessen.

Misslyckas utgåvorna alltid en viss dag eller tid? Misslyckas de alltid när du har distribuerat till en viss miljö? Leta efter dessa och andra mönster för att se om vissa aspekter av lanseringsprocessen är beroende eller relaterade.

Ett bra sätt att hålla reda på versionskvaliteten är att skapa visualiseringar av kvaliteten på versionerna. Lägg till exempel till en instrumentpanelswidget som visar status för varje version.

När du vill mäta kvaliteten på själva utgåvan kan du utföra alla typer av kontroller i distributionsprocessen. Du kan till exempel köra olika typer av tester, till exempel belastningstester och användargränssnittstester när du kör pipelinen.

Att använda en kvalitetsgrind är också ett bra sätt att kontrollera kvaliteten på din version. Det finns många olika kvalitetsgrindar. Till exempel kan arbetsobjektgrindar verifiera kvaliteten på din kravprocess. Du kan också lägga till fler säkerhets- och efterlevnadskontroller. Följer du till exempel principen med fyra ögon eller har du rätt spårbarhet?

När du går vidare med den här utbildningsvägen ser du många av dessa tekniker omsättas i praktiken.

När du utformar en process för kvalitetsversion bör du slutligen tänka på vilken typ av dokumentation eller viktig information som du behöver ge användaren. Det kan vara svårt att hålla dokumentationen aktuell. Du kanske vill överväga att använda ett verktyg, till exempel Azure DevOps Release Notes Generator. Generatorn är en funktionsapp som innehåller en HTTP-triggad funktion. Genom att använda Azure Blob Storage skapar den en Markdown-fil när en ny version skapas i Azure DevOps.