Opbygning af en CI-pipeline med Azure Pipelines

Kontinuerlig integration (CI) er en praksis, hvor kodeændringer ofte flettes ind i en delt gren, og hver fletning automatisk udløser en build og en testkørsel. Målet er at opdage integrationsfejl tidligt — før de vokser sammen til store problemer, der er svære at løse. En god CI-pipeline bygger koden, kører enhedstests, måler kodedækning, udfører statisk analyse og producerer et artefakt, der kan udrulles, på få minutter. Azure Pipelines leverer automatiseringsmotoren til denne praksis.

Azure Pipelines' CI-pipelines defineres i en azure-pipelines.yml-fil i roden af dit repository. YAML-filen angiver udløsere (hvornår pipelinen skal køre), en agentpulje (hvilken type agent der skal bruges) og et hierarki af faser, jobs og trin. Faser kører som standard sekventielt. Jobs i en fase kører som standard parallelt. Trin i et job kører sekventielt. Denne struktur giver dig detaljeret kontrol over pipelineforløbet.

Azure Pipelines understøtter flere typer udløsere. Grenudløsere kører pipelinen, når kode pushes til angivne grene. Udløsere for pullanmodninger (PR-udløsere) kører, når en PR oprettes eller opdateres mod målgrene — det er afgørende for at validere kode før en fletning. Planlagte udløsere kører på et fast tidspunkt (f.eks. natlige builds). Pipelineudløsere kæder pipelines sammen. Angiv trigger: none for at deaktivere automatiske kørsler og kun tillade manuel kørsel.

Pipeline-trin er enten scripts (bash- eller PowerShell-kommandoer) eller opgaver (forudbyggede, parameteriserede enheder fra Azure DevOps Marketplace). Opgaver som NodeTool@0, DotNetCoreCLI@2 og Maven@3 indkapsler almindelige build-handlinger. Brug displayName på hvert trin, så pipeline-loggene er nemme at læse. Hvert trin kører i rækkefølge, og pipelinen mislykkes, hvis et trin afsluttes med en kode, der ikke er nul, medmindre du angiver continueOnError: true.

Når du har kørt tests, skal du udgive resultaterne til Azure DevOps ved hjælp af opgaven PublishTestResults. Azure Pipelines fortolker resultatfiler i formaterne JUnit, NUnit, XUnit eller VSTest og viser antal beståede og mislykkede tests, testkørslens varighed og detaljer om de enkelte tests i brugergrænsefladen for pipelinekørslen. Testhistorikken registreres over tid, så du kan opdage ustabile tests og regressioner. Det er afgørende for at synliggøre kodekvaliteten på tværs af teamet.

Udgiv rapporter om kodedækning, så Azure Pipelines viser dækningsprocenter og tendenser i pipelinebrugergrænsefladen. Opgaven PublishCodeCoverageResults accepterer rapporter i Cobertura- eller JaCoCo-format. Kombiner dette med porte for grendækning — konfigurer en minimumstærskel for dækningen, og lad buildet mislykkes, hvis dækningen falder under den. Tendenser i dækningen hjælper med at identificere, når der tilføjes ny kode uden tilsvarende tests.

Gem pipelinekonfiguration i variabler, der defineres på pipeline-, fase- eller jobniveau i YAML. Brug hemmelige variabler til følsomme værdier (API-nøgler og adgangskoder) — angiv dem i pipelinebiblioteket (brugergrænsefladen) eller i variabelgrupper, og referer til dem i YAML. Variabelgrupper er genanvendelige samlinger af variabler, der deles på tværs af flere pipelines. Knyt en variabelgruppe til Azure Key Vault for automatisk at synkronisere hemmeligheder fra Key Vault til pipelinevariabler.

Efter et vellykket build skal du pakke outputtet som et pipelineartefakt, så efterfølgende faser (f.eks. udrulning) kan få adgang til det. Brug PublishPipelineArtifact til at uploade filer fra buildagenten til Azure DevOps' artefaktlager. Brug DownloadPipelineArtifact i en senere fase eller et senere job til at hente artefaktet. Det afkobler buildjobbet fra udrulningsjobbene, som kan køre på andre agenter eller i andre faser.

Kør uafhængige opgaver parallelt ved at definere flere jobs i en fase. Du kan f.eks. køre enhedstests og sikkerhedsscanning samtidig i stedet for sekventielt. Parallelle jobs kræver separate buildminutter, men kan reducere den samlede pipelinevarighed markant. Brug egenskaben dependsOn til at få et job til at vente på, at et eller flere andre jobs afsluttes, før det starter, så der oprettes en afhængighedsgraf i en fase.

Knyt din CI-pipeline til en grenpolitik i Azure Repos, så den automatisk kører som en buildvalideringskontrol på pullanmodninger, der er rettet mod main. Fletning blokeres, indtil pipelinen er bestået. Kombiner flere kontroller: CI-pipelinen skal lykkes, mindst to reviewere skal godkende, alle kommentarer skal være løst, og der skal findes et tilknyttet arbejdselement. Det skaber en kvalitetsport, der gør det umuligt at flette fejlbehæftet kode ind i hovedgrenen.

Når en pipelinekørsel er afsluttet, skal du gennemgå resultaterne i Azure DevOps-portalen. Fanen Oversigt viser det samlede resultat og tidsforbruget. Fanen Tests viser alle testresultater med filtrering efter resultat. Fanen Kodedækning viser dækningsprocenten og fremhæver linjer, der ikke er dækket. Klik på et job for at se logoutputtet trin for trin. Mislykkede pipelines viser det fejlslagne trin fremhævet med rødt sammen med det fulde fejloutput, så fejlen hurtigt kan diagnosticeres.

I denne lektion har du lært, at Azure Pipelines YAML definerer CI-pipelines med faser, jobs og trin til build, test og oprettelse af artefakter, at PR-udløsere og grenpolitikker håndhæver kvalitetsporte, der blokerer fletning af fejlbehæftet kode, og at opgaverne PublishTestResults og PublishCodeCoverageResults synliggør testkvaliteten på tværs af teamet. Som det næste ser vi på kontinuerlig udrulning til Azure.