Utforma pipelinen

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

När du planerar en versionspipeline börjar du vanligtvis med att identifiera faser, eller större delar, 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 distributionsfas som mappades till en Azure App Service-instans.

I den här modulen höjer du upp ändringar från en fas till en annan. I varje fas distribuerar du 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:

Mötet

Hela Tailspin-webbteamet samlas. Tidigare planerade teamet sina uppgifter för den aktuella sprinten. Varje uppgift handlar om att skapa sin lanseringspipeline för Space Game-webbplatsen .

Teamet bestämde sig för dessa fem uppgifter för sin sprint:

• Skapa en pipeline med flera steg
• Ansluta webbappen till en databas
• Automatisera kvalitetstester
• Automatisera prestandatester
• Förbättra versionstakt

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 idén om 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: Precis! Vi måste lägga till andra steg. För närvarande har vi till exempel ingen plats för ett teststeg.

Tim: Dessutom behöver vi ett steg där vi kan visa nya funktioner för hanteringen. Jag kan inte skicka något till produktion utan hanteringsgodkännande.

Andy: Självklart! 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: Nu ska vi 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:Byggfasen skapar källkoden och skapar ett paket. I vårt fall är paketet en .zip fil. Distributionssteget installerar .zip-filen, som är webbplatsen för Space Game, 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 utvecklingsfas. 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 space game-webbplatsens rankningsfunktion höga poä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 Utvecklingsfas 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-stadiet.

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

Mara: Att bygga kontinuerligt ger oss viktig feedback om vår bygg- och testhälsa. Men vi vill bara höja upp till Utvecklingssteget när vi sammanfogar kod till någon central gren: antingen huvudgrenen 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 Utvecklingssteget när ändringar sker på en versionsgren.

Vad är villkor?

I Azure Pipelines använder du ett villkor för att köra en uppgift eller ett 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:

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 release.

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 använder du det här villkoret för att köra Dev-steget endast när det aktuella branchnamnet ä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 release.

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.

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

En mer fullständig beskrivning av villkor i Azure Pipelines finns i dokumentationen om uttryck.

Mara: Med hjälp av villkor kan du styra vilka ändringar som höjs 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 slå samman ändringarna till en versionsgren och flytta upp den versionen till Utvecklingsfasen .

Lägg till teststeget

Mara: Hittills har vi Byggnads- och Utvecklingsstegen. Vad kommer härnäst?

Amita: Kan vi lägga till teststeget härnäst? Det verkar vara rätt plats för mig att testa de senaste ändringarna.

Mara lägger till teststeget 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: Säker. 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 teststeget klockan 03.00 varje dag.

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 etapp 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 få en version att köras 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 Dagar, Månader och Veckodagar .

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

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 dessa två behov i en fas som vi kan anropa Mellanlagring.

Andy: Bra sagt, Tim. Det är viktigt att ha en mellanlagrings- 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 Planering på sin ritning på whiteboarden.

Amita: Vi använder en schemalagd utlösare för att höja upp ändringar från Utvecklingssteget till testfasen . 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 versionsgodkä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 precis 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 när Amita godkänner det.

Tim: Jag kan också tänka mig att vi använder releasegodkännanden för att flytta från Staging till Production efter att ledningen har godkänt. 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.

Här är ett exempel från en befintlig pipeline som definierar en miljö i dess konfiguration för att representera en distributionsmiljö:

- 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 mellanlagringsmiljön och tilldelar dig själv som godkännare för att höja upp Space Game-webbappen från testfasen 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 testfasen , 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 våra 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 versionspipeline 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 byggfasen .
2. Flytta upp byggartefaktet till Utvecklingssteget . Det här steget sker automatiskt när byggsteget lyckas och ändringen befinner sig på versionsgrenen.
3. Flytta upp byggartefakten till teststeget varje morgon klockan 03.00. Vi använder en schemalagd utlösare för att höja upp byggartefakten automatiskt.
4. Flytta upp byggartefakten till Mellanlagring efter Amita-tester och godkänn bygget. 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 att bli svårt? 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. Till exempel finns det som händer i teststeget kvar i testfasen .

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 Utvecklingsfasen som i mellanlagringsfasen 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? Du kan inte mäta det 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, som är en funktionsapp som innehåller en HTTP-utlöst funktion. Genom att använda Azure Blob Storage skapar den en Markdown-fil när en ny version skapas i Azure DevOps.