Planera en versionspipeline med hjälp av Azure Pipelines

Slutförd

I det här avsnittet följer du med Andy och Mara när de planerar en grundläggande CD-pipeline som körs på Azure Pipelines.

När det är klart demonstrerar de det för resten av teamet. Pipelinen kommer att fungera som en POC som de förbättrar och expanderar när de lär sig mer och får feedback från Tim och Amita.

Vilka är delarna i en grundläggande CD-pipeline?

En grundläggande CD-pipeline innehåller en utlösare för att få igång processen och minst en faseller distributionsfasen. En fas består av jobb. Ett jobb är en serie steg som definierar hur du skapar, testar eller distribuerar ditt program.

Andy: Vi har redan skapa artefakt. Det är den .zip fil som vår befintliga byggpipeline skapar. Men hur distribuerar vi den till en livemiljö?

Vad är en pipelinefas?

En fas är en del av pipelinen som kan köras separat och utlösas av olika mekanismer. En mekanism kan vara framgången för föregående steg, ett schema eller till och med en manuell utlösare. Du får lära dig mer om de här mekanismerna i nästa modul.

Mara: Vi kan ha en fas som skapar appen och en annan fas som kör tester.

Mara: Vi har redan definierat uppgifterna för byggfasen i pipelinen. Vårt distributionssteg kan vara liknande, inklusive uppgifter som distribuerar bygget till en miljö.

Frågan är, var ska vi distribuera artefakten?

Vad är en miljö?

Du har förmodligen använt termen miljö för att referera till var programmet eller tjänsten körs. Till exempel kan din produktionsmiljö vara där slutanvändarna kommer åt ditt program.

I det här exemplet kan produktionsmiljön vara:

• En fysisk dator eller virtuell dator (VM).
• En containerbaserad miljö, till exempel Kubernetes.
• En hanterad tjänst, till exempel Azure App Service.
• En serverlös miljö, till exempel Azure Functions.

En artefakt utplaceras till en miljö. Azure Pipelines gör det enkelt att distribuera till nästan alla typer av miljöer, oavsett om de är lokala eller i molnet.

I Azure Pipelines har termen miljö en andra betydelse. Här är en miljö en abstrakt representation av distributionsmiljön, till exempel ett Kubernetes-kluster, en App Service-instans eller en virtuell dator.

En Azure Pipelines-miljö registrerar distributionshistoriken som hjälper dig att identifiera källan till ändringar. Genom att använda Azure Pipelines-miljöer kan du också definiera säkerhetskontroller och sätt att styra hur en artefakt befordras från en fas i en pipeline till en annan. Vad en miljö innehåller beror på vad du vill göra med artefakten. En miljö där du vill testa artefakten definieras förmodligen annorlunda än en miljö där du vill distribuera artefakten för dina slutanvändare.

Ett sätt att definiera en Azure Pipelines-miljö är med en YAML-fil. YAML-filen innehåller ett environment avsnitt som anger Azure Pipelines-miljön, där du distribuerar artefakten.

När du planerar versionspipelinen måste du bestämma var programmet eller tjänsten ska köras. Låt oss lyssna in och se vad Andy och Mara bestämmer.

Andy: På hög nivå, vilken typ av miljö vill vi ha? Vill vi distribuera lokalt eller till molnet?

Mara: Vi kan be Tim att skapa en virtuell dator åt oss i labbet, men han har alltid slut på maskinvara. Det blir snabbt och enkelt att konfigurera en POC själva om vi använder molnet.

Andy: jag håller med; men det finns så många molnalternativ att tänka på, och vi kan använda Azure Pipelines för att distribuera till någon av dem. Vad ska vi försöka med?

Mara: Teamen som utvecklar våra spel använder Azure som värd för några av sina backend-system. De satte upp det snabbt och verkar gilla det. Jag tycker att vi ska hålla oss till Azure för vårt moln.

Andy: OK, det är vettigt! Men Azure har så många beräkningsalternativ. Vad ska vi välja?

Andy listar dessa alternativ på whiteboarden:

• Virtuella datorer
• Behållare
• Azure App Service
• Serverlös databehandling

Not

Du hittar mer information om vart och ett av dessa beräkningsalternativ i slutet av den här modulen.

Mara: jag vet att containrar och serverlös databehandling är populära just nu. Jämfört med virtuella datorer är de båda lätta när det gäller resurser. De är också lätta att ersätta och skala ut. Båda är intressanta, men jag är nervös för att lära mig två nya tekniker samtidigt. Jag koncentrerar mig hellre på att bygga pipelinen.

Andy: jag är med dig. Då återstår virtuella datorer eller App Service. Jag tror att virtuella datorer skulle vara ett bättre val om vi flyttade en verksamhetsspecifik app – en app som kräver fullständig åtkomst till en viss miljö – till molnet. Vi gör inget så betydelsefullt.

Mara: Då återstår App Service, som skulle vara mitt val. Den är utformad för att fungera med Azure DevOps och har fördelar. Det är en PaaS-miljö (plattform som en tjänst) för webbappar, så det tar mycket av bördan från oss. Vi behöver inte bekymra oss om infrastrukturen. Den levereras också med säkerhetsfunktioner och gör att vi kan utföra belastningsutjämning och automatisk skalning.

Andy: App Service låter som det vi behöver. Nu ska vi använda App Service. Vi skapar bara ett konceptbevis ändå. Vi kan alltid ändra beräkningsalternativet om vi vill prova något annat senare.

Hur utför Azure Pipelines distributionssteg?

För att distribuera ditt program måste Azure Pipelines först autentisera med målmiljön. Azure Pipelines tillhandahåller olika autentiseringsmekanismer. Vilken du använder beror på vilken målmiljö du distribuerar till. Du hittar mer information om dessa mekanismer i slutet av den här modulen.

Andy: Vi har vårt byggobjekt och vi vet att vi kommer att bygga och distribuera i etapper av pipelinen. Vi har också definierat målmiljön för distributionen. Det är App Service. Min fråga är nu, hur autentiserar Azure Pipelines med App Service? Jag vet att detta kommer att vara en av Tims bekymmer. Vi måste se till att processen är säker.

Efter lite efterforskningar kommer Andy och Mara med de allmänna stegen som gör att Azure Pipelines kan distribueras till App Service:

1. Ange måldistributionsmiljön i pipelinekonfigurationen.
2. Ge Azure Pipelines ett sätt att autentisera åtkomsten till den miljön.
3. Använd Azure Pipelines-uppgifter för att distribuera byggartefakten till den miljön.

Mara: Enligt vår forskning måste vi skapa en tjänstanslutning för att ange målmiljön och autentisera åtkomsten till den. När vi har definierat tjänstanslutningen blir den tillgänglig för alla våra uppgifter att använda. Sedan måste vi använda de inbyggda uppgifterna DownloadPipelineArtifact för att ladda ned byggartefakten till pipelineagenten och AzureWebApp- för att distribuera vårt program till Azure App Service.

Vad är jobb och strategier?

Din befintliga byggpipeline definierar en byggagent, pipelinevariabler och de uppgifter som krävs för att skapa din programvara.

Utplaceringsdelen av din pipeline innehåller samma element. Distributionskonfigurationen definierar vanligtvis också ett eller flera jobb, en pipelinemiljö och strategier. Tidigare lärde du dig om pipelinemiljöer.

Här är en exempelkonfiguration som du ska köra senare i den här modulen. Den här konfigurationen distribuerar webbplatsen Space Game till Azure App Service.

- stage: 'DeployDev'
  displayName: 'Deploy to dev environment'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: 'Release Pipeline'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppName)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

Jobb

Ett jobb är en serie steg eller uppgifter som körs sekventiellt som en enhet. Varje pipelinesteg har som standard ett jobb, även om den fasen inte använder nyckelordet job.

Ett jobb kan köras i en agentpool, på en container eller direkt på Azure DevOps-servern. Exempeljobbet som visas här körs på en Microsoft-hanterad Ubuntu-agent.

Du kan ange under vilka villkor varje jobb körs. Exempeljobbet som visas här definierar inga villkor. Som standard körs ett jobb om det inte är beroende av något annat jobb, eller om alla jobb som det beror på har slutförts.

Du kan också köra jobb parallellt eller sekventiellt. Med din befintliga bygg-pipeline som exempel kan du använda parallella jobb för att skapa programvara i Windows, Linux och macOS-agenter samtidigt.

Ett distributionsjobb är en särskild typ av jobb som spelar en viktig roll i distributionsstegen. Distributionsjobb registrerar statusen för dina distributioner i Azure Pipelines, vilket ger dig en spårningslogg. Distributionsjobb hjälper dig också att definiera distributionsstrategin, vilket vi kommer att göra inom kort.

Strategier

En strategi definierar hur applikationen distribueras. Du lär dig mer om strategier som blågrön och canary i en framtida modul. För tillfället använder du strategin runOnce för att ladda ned Space Game-paketet från pipelinen och distribuera det till Azure App Service.

Hur ansluter Azure Pipelines till Azure?

Om du vill distribuera din app till en Azure-resurs, till exempel en virtuell dator eller App Service, behöver du en tjänstanslutning. En tjänstanslutning ger säker åtkomst till din Azure-prenumeration med någon av de två metoderna:

• Autentisering för tjänstehuvudnamn
• Hanterade identiteter för Azure-resurser

Du kan lära dig mer om dessa säkerhetsmodeller i slutet av den här modulen, men kort och kort:

• En tjänsteprincip är en identitet med en begränsad roll som har åtkomst till Azure-resurser. Tänk på ett servicehuvudkonto som ett tjänstkonto som kan utföra automatiserade uppgifter åt dig.
• Hanterade identiteter för Azure-resurser är en funktion i Microsoft Entra ID som förenklar processen genom att arbeta med serviceprincipaler. Eftersom hanterade identiteter finns i Microsoft Entra-klientorganisationen kan Azure-infrastrukturen automatiskt autentisera tjänsten och hantera kontot åt dig.

Hanterade identiteter förenklar processen med att arbeta med tjänstens huvudnamn. men i den här modulen använder vi autentisering med tjänstens huvudnamn eftersom en tjänstanslutning automatiskt kan identifiera dina Azure-resurser och tilldela lämpliga roller för tjänstens huvudnamn åt dig.

Planen

Andy och Mara är redo att börja. De kommer att:

• Bygga vidare på deras befintliga Azure Pipelines-byggkonfiguration.
• Definiera en byggfas som skapar artefakten.
• Definiera ett distributionssteg som distribuerar artefakten till App Service.

Andy: Är den här ritningen korrekt? Vi använder Azure Pipelines för att distribuera till Azure App Service . För att göra det tar vi kompileringsartefakten som indata till distributionssteget . Uppgifterna i distributionssteget laddar ner artefakten och använder en tjänsteanslutning för att distribuera artefakten till App Service .

Mara: Det sammanfattar det hela. Nu ska vi komma igång.