Testautomatisering og leveringspipeline
- 5 minutter
Du har lært om løbende udrulning og levering af software og tjenester, men de to er faktisk en del af en triad. DevOps-praksisser har til formål at opnå løbende integration, udrulning og levering.
Nu er det tid til at sikkerhedskopiere og diskutere det første af disse: integration. Dette er en del af den udviklingsproces, der kommer før udrulningen. DevOps anbefaler en udviklingspraksis, hvor teammedlemmer ofte integrerer kode i et delt lager, der indeholder en enkelt kodebase af typen "main" eller "trunk". Målet er at få alle til at bidrage til den kode, der sendes vs. arbejder ud på deres kopi og kun bringe alt sammen i sidste minut.
Automatiseret test kan derefter bekræfte hvert teammedlems integration. Denne test hjælper med at fastslå, at koden er "sund" efter hver ændring og tilføjelse. Testen er en del af det, vi kalder en pipeline. Vi taler om pipelines om et øjeblik, fordi dette undermodul fokuserer på integrerede test- og leveringspipelines.
Den kontinuerlige leveringspipeline
Hvis du vil forstå den rolle, automatiserede test spiller i den kontinuerlige udrulningsmodel for levering, skal du se på, hvor den passer ind i leveringspipelinen. En kontinuerlig leveringspipeline er implementeringen af den kode for trin, der gennemgås, efterhånden som der foretages ændringer under udviklingsprocessen, før den udrulles til produktion. Her er en grafisk gengivelse af eksempeltrin i en forenklet leveringspipeline:
Lad os gennemgå denne pipeline trinvist.
En forekomst af pipelinen starter, når kode- eller infrastrukturændringer sendes til et kodelager, måske ved hjælp af en pullanmodning.
Derefter kører enhedstests – måske integration eller komplette test – og ideelt set kommunikeres disse testresultater tilbage til den anmodende part.
På dette tidspunkt scannes koden i lageret måske for hemmeligheder, sårbarheder og aspekter af konfigurationen.
Når alt er tjekket ud, bygges og klargøres koden til udrulning.
Derefter installeres koden i et testmiljø. En person får muligvis besked om den nye udrulning for at give præproduktionsløsningen et udseende. Denne person kan derefter godkende eller afvise udrulningen til produktion, hvilket starter den sidste del af udrulningsprocessen, der frigiver koden til produktion.
I denne pipeline kan du notere afgrænsning mellem integration og udrulning. De røde mærker peger på nogle logiske steder, hvor du kan stoppe pipelinen gennem inkluderet logik og automatisering eller muligvis endda menneskelig indgriben.
Værktøjer til løbende integration og levering: Azure Pipelines
Hvis du vil bruge kontinuerlig integration og kontinuerlig levering, skal du bruge de rigtige værktøjer. Azure Pipelines er en del af Azure DevOps Services, som du kan bruge til at automatisere opbygning og konsekvent teste din kode. Du kan også bruge Azure Pipelines til at udrulle koden til Azure-tjenester, virtuelle maskiner og andre mål både i cloudmiljøet og i det lokale miljø.
Inputtet til en pipeline (vores kode eller konfigurationer) findes i et versionskontrolsystem, f.eks. GitHub eller en anden Git-udbyder.
Azure Pipelines, der kører på en beregning, f.eks. en virtuel maskine eller en objektbeholder, tilbyder buildagenter, der kører Windows, Linux og macOS. Det tilbyder også integration med plug-ins til test, sikkerhed og kodekvalitet. Endelig er det nemt at udvides, så du kan overføre din egen automatisering til Azure Pipelines.
Pipelines defineres ved hjælp af YAML-syntaks eller via den klassiske brugergrænseflade på Azure Portal. Når du bruger en YAML-fil, kan du gemme filen sammen med din kode. Pipelines indeholder også skabeloner, som du kan bruge til nemt at oprette pipelines. en pipeline, der opretter et Docker-billede eller et Node.js projekt. Du kan også genbruge en eksisterende YAML-fil.
Uanset om du bruger en YAML-fil eller classic-grænsefladen, er her de grundlæggende trin:
- Konfigurer Azure Pipelines til at bruge dit Git-lager.
- Definer dit build, enten ved at redigere azure-pipelines.yml-filen eller ved hjælp af editoren Klassisk.
- Send din kode til dit versionsstyringslager. Denne handling udløser pipelinen for at bygge og teste din kode.
Når koden er blevet opdateret, bygget og testet, kan du udrulle den til det ønskede mål.
Der er nogle funktioner (f.eks. kørsel af objektbeholderjob), der kun er tilgængelige, når du bruger YAML, og andre (f.eks. opgavegrupper), der kun er tilgængelige ved hjælp af den klassiske brugergrænseflade.
Azure Pipeline-konstruktion
Rørledninger er struktureret i:
Job: Et job er en gruppering af opgaver eller trin, der kører på en enkelt buildagent. Et job er den mindste komponent i arbejdet, som du kan planlægge at køre. Alle trin i et job kører sekventielt. Disse trin kan være enhver form for handling, du ønsker, herunder bygning/kompilering af software, forberedelse af eksempeldata til test, kørsel af specifikke test osv.
faser: En fase er en logisk gruppering af relaterede job.
Hver pipeline har mindst én fase. Brug flere faser til at organisere pipelinen i større divisioner og markere punkterne i pipelinen, hvor du kan afbryde og udføre kontroller.
Pipelines kan være så enkle eller komplekse som ønsket. Der er fremragende selvstudier om pipelinekonstruktion og -brug i Build-programmer med Azure DevOps læringsforløb.
Miljøsporing
Der er et andet aspekt af pipelines, der er relateret til pålidelighed, der er værd at nævne. Du kan konstruere dine pipelines på en sådan måde, at det er muligt at sammenholde det, der kører i produktionen, med en bestemt buildforekomst. Ideelt set bør vi kunne spore et build tilbage til en bestemt pullanmodning eller kodeændring. Dette kan være enormt nyttigt, enten under en hændelse eller bagefter under gennemgangen efter hændelsen, når du forsøger at identificere, hvilken ændring der har bidraget til et problem. Nogle CI/CD-systemer (f.eks. Azure Pipelines) gør det nemt at gøre dette, mens andre kræver, at du manuelt konstruerer en pipeline, der overfører en slags "build-id" gennem alle faserne.