Testningsautomatisering och leveranspipeline

Du har lärt dig om kontinuerlig distribution och leverans av programvara och tjänster, men de två ingår i en triad. DevOps-metoder syftar till att uppnå kontinuerlig integrering, leverans och distribution. Dessa metoder byggs vanligtvis upp i den ordningen, med var och en beroende på den före den.

Nu är det dags att säkerhetskopiera och diskutera det första av följande: integrering. Detta är en del av den utvecklingsprocess som kommer före distributionen. DevOps rekommenderar en utvecklingsmetod där teammedlemmar ofta integrerar kod på en delad lagringsplats som innehåller en enskild ”huvud-” eller ”stamkodbas”. Målet är att alla ska bidra till den kod som kommer att lanseras i stället för att de arbetar med egna kopior och sedan sammanför allt i sista minuten.

Automatiserad testning kan sedan verifiera varje teammedlems integrering. Den här testningen hjälper till att fastställa att koden är ”felfri” efter varje ändring och tillägg som görs. Testningen är en del av det som ofta kallas för en pipeline. Resten av denna enhet fokuserar på integrerade test- och leveransrörledningar.

Pipelinen för kontinuerlig leverans

För att förstå den automatiserade testningens roll i distributionsmodellen för kontinuerlig leverans måste du titta på var den passar in i leveranspipelinen. En pipeline för kontinuerlig leverans är implementeringen av de steg som koden genomgår när ändringar görs under utvecklingsprocessen innan den distribueras till produktion. Här är en grafisk representation av exempelsteg i en förenklad leveranspipeline:

Gå igenom den här pipelinen steg för steg:

• En instans av pipelinen startar när kod- eller infrastrukturändringar committas till en kodlagringsplats, kanske med hjälp av en pull-begäran.

• Därefter körs enhetstester, ofta följt av integrerings- eller slutpunkt-till-slutpunkt-tester. Resultatet kommuniceras tillbaka till utvecklaren som öppnade pull-begäran.

• I det här skedet genomsöks koden på lagringsplatsen ofta efter hemligheter, sårbarheter och felkonfigurationer.

• När allt stämmer kompileras koden och förbereds för distribution.

• Sedan distribueras koden till en testmiljö. En granskare kan meddelas om den nya distributionen så att de kan undersöka förproduktionslösningen. Granskaren godkänner eller nekar sedan befordran till produktion, vilket startar den sista delen av distributionsprocessen som släpper koden till produktion.

I den här pipelinen kan du notera avgränsningen mellan integrering och distribution. De markerade markörer pekar ut några logiska platser där du kan stoppa pipelinen genom inkluderad logik och automatisering, eller potentiellt till och med mänsklig inblandning.

Verktyg för kontinuerlig integrering och leverans: Azure-pipelines och GitHub Actions

För att använda kontinuerlig integrering och kontinuerlig leverans behöver du rätt verktyg. Microsoft erbjuder två CI/CD-alternativ från första part för att skapa och distribuera till Azure: Azure-pipelines (del av Azure DevOps) och GitHub Actions. Båda kan automatisera skapande och konsekvent testning av din kod, och båda kan distribueras till Azure tjänster, virtuella datorer och andra mål i molnet och lokalt. Många team antar GitHub Actions när källkoden redan finns i GitHub, medan Azure-pipelines fortfarande är ett starkt val för team som är standardiserade på Azure DevOps.

Resten av den här lektionen fokuserar på Azure-pipelines, men GitHub Actions använder liknande idéer på hög nivå även om terminologin skiljer sig åt. I GitHub Actions innehåller arbetsflöden jobb och steg, actions paketerar återanvändbar automatisering, runners kör arbetet och miljöer kan skydda distributioner.

Indata till en pipeline (din kod eller dina konfigurationer) finns i ett versionskontrollsystem, till exempel GitHub eller någon annan Git-provider.

Azure-pipelines körs på beräkningsresurser, till exempel en virtuell dator eller en container, och erbjuder Microsoft-värdbaserade byggagenter som körs på Windows, Linux och macOS. Du kan också registrera dina egna lokalt installerade agenter när du behöver fullständig kontroll över byggmiljön. Det erbjuder också integrering med plugin-program för testning, säkerhet och kodkvalitet. Slutligen är det enkelt att utökningsbara, så du kan ta med din egen automatisering till Azure-pipelines.

Pipelines definieras med YAML-syntax som lagras tillsammans med din kod på en Git-lagringsplats. YAML-pipelines är den rekommenderade metoden för nya projekt. Ett klassiskt användargränssnitt i Azure DevOps finns också tillgängligt för äldre flöden, men de flesta nya funktionaliteter (inklusive containerjobb och många avancerade funktioner) finns endast i YAML. Pipelines innehåller också mallar som du kan använda för att enkelt skapa pipelines, till exempel en mall för en Docker-avbildning eller ett Node.js projekt. Du kan dessutom återanvända en befintlig YAML-fil.

De grundläggande stegen för att konfigurera en pipeline är:

1. Konfigurera Azure-pipelines att använda din Git-lagringsplats.
2. Definiera din version genom att redigera azure-pipelines.yml -filen (eller, för äldre pipelines, med hjälp av den klassiska redigeraren).
3. Skicka koden till lagringsplatsen för versionskontroll. Den här åtgärden utlöser pipelinen för att kompilera och testa koden.

När koden har uppdaterats, kompilerats och testats kan du distribuera den till valfritt mål.

Azure Pipeline-konstruktion

Pipelines är indelade i:

• Jobb: Ett jobb är en gruppering av uppgifter eller steg som körs på en enda byggagent. Ett jobb är den minsta arbetsuppgift som du kan schemalägga för att köra. Alla steg i ett jobb körs sekventiellt. Dessa steg kan vara alla åtgärder du behöver, inklusive att skapa eller kompilera programvara, förbereda exempeldata för testning, köra specifika tester och så vidare.

• Steg: En fas är en logisk gruppering av relaterade jobb.

Varje pipeline har minst en fas. Använd flera faser för att organisera pipelinen i större avsnitt och markera punkter i pipelinen där du kan pausa och utföra kontroller.

Pipelines kan vara så enkla eller komplexa som du behöver. Självstudier om pipelinekonstruktion och användning finns i lärvägen Build applications with Azure DevOps.

Miljöspårbarhet

Det finns en annan aspekt av pipelines som rör tillförlitlighet som är värt att nämna. Du kan konstruera dina pipelines på ett sådant sätt att det är möjligt att korrelera det som körs i produktion med en specifik bygginstans. Helst bör du kunna spåra en version tillbaka till en specifik pull-begäran eller kodändring. Den här spårningsbarheten är ovärderlig under en incident och efteråt under granskningen efter incidenten när du försöker identifiera vilken ändring som bidrog till ett problem. Vissa CI/CD-system (till exempel Azure-pipelines och GitHub Actions) gör den här korrelationen enkel, medan andra kräver att du manuellt skapar en pipeline som sprider ett bygg-ID genom varje steg.