Vad är CI / CD? Kontinuerlig integration och kontinuerlig leverans förklaras

Kontinuerlig integration (CI) och kontinuerlig leverans (CD) förkroppsligar en kultur, en uppsättning driftprinciper och insamling av metoder som gör att applikationsutvecklingsteam kan leverera kodändringar oftare och mer tillförlitligt. Implementeringen är också känd som CI / CD- pipelinen. 

CI / CD är en av de bästa metoderna för devops-team att implementera. Det är också en smidig metodik bästa praxis, eftersom det gör det möjligt för programvaruutvecklingsteam att fokusera på att uppfylla affärskrav, kodkvalitet och säkerhet eftersom distributionsstegen är automatiserade.

CI / CD definierad

Kontinuerlig integration  är en kodningsfilosofi och en uppsättning metoder som driver utvecklingsgrupper att implementera små ändringar och checka in kod till versionskontrollförvar ofta. Eftersom de flesta moderna applikationer kräver utveckling av kod i olika plattformar och verktyg behöver teamet en mekanism för att integrera och validera sina förändringar.

Det tekniska målet för CI är att skapa ett konsekvent och automatiserat sätt att bygga, paketera och testa applikationer. Med konsekvens i integrationsprocessen är det mer troligt att team begår kodändringar oftare, vilket leder till bättre samarbete och mjukvarukvalitet.

Kontinuerlig leverans  tar fart där kontinuerlig integration slutar. CD automatiserar leverans av applikationer till utvalda infrastrukturmiljöer. De flesta team arbetar med flera andra miljöer än produktionen, till exempel utvecklings- och testmiljöer, och CD säkerställer att det finns ett automatiserat sätt att skicka kodändringar till dem.

CI / CD-verktyg hjälper till att lagra miljöspecifika parametrar som måste förpackas med varje leverans. CI / CD-automatisering utför sedan alla nödvändiga serviceanrop till webbservrar, databaser och andra tjänster som kan behöva startas om eller följa andra procedurer när applikationer distribueras.

Kontinuerlig integration och kontinuerlig leverans kräver  kontinuerlig testning  eftersom målet är att leverera kvalitetsapplikationer och kod till användare. Kontinuerlig testning implementeras ofta som en uppsättning automatiserad regression, prestanda och andra tester som utförs i CI / CD-pipelinen.

En mogen CI / CD devops-praxis har möjlighet att implementera kontinuerlig distribution där applikationsändringar körs via CI / CD-pipelinen och passande builds distribueras direkt till produktionsmiljöer. Team som övar kontinuerlig leverans väljer att distribuera till produktion enligt ett dagligt eller till och med timschema, även om kontinuerlig leverans inte alltid är optimal för alla affärsapplikationer.  

Relaterad video: Hur man levererar kod snabbare med CI / CD

Hur kontinuerlig integration förbättrar samarbete och kvalitet

Kontinuerlig integration är en utvecklingsfilosofi som stöds av processmekanik och viss automatisering. När man tränar CI, utvecklar utvecklare sin kod i versionskontrollförvaret ofta och de flesta lag har en minimal standard för att begå kod åtminstone dagligen. Motivet bakom detta är att det är lättare att identifiera defekter och andra problem med mjukvarukvalitet på mindre koddifferenser snarare än större som utvecklats under lång tid. Dessutom, när utvecklare arbetar med kortare åtagandecykler är det mindre troligt att flera utvecklare redigerar samma kod och kräver en sammanslagning när de begår.

Team som implementerar kontinuerlig integration börjar ofta med konfiguration av versionskontroll och definitioner av övningar. Även om incheckningskoden görs ofta implementeras funktioner och korrigeringar på både korta och längre tidsramar. Utvecklingsteam som övar kontinuerlig integration använder olika tekniker för att kontrollera vilka funktioner och kod som är redo för produktion.

Många lag använder funktionsflaggor , en konfigurationsmekanism för att aktivera eller inaktivera funktioner och kod vid körning. Funktioner som fortfarande är under utveckling förpackas med funktionsflaggor i koden, distribueras med huvudgrenen till produktion och stängs av tills de är redo att användas. Enligt en nyligen genomförd undersökning rapporterar 63 procent av team som använder funktionsflaggor bättre testning och programvara av högre kvalitet. Funktionsflaggningsverktyg som CloudBees-utrullning, Optimalt utrullningar och LaunchDarkly integreras med CI / CD-verktyg och möjliggör konfigurationer på funktionsnivå.

En annan teknik för hantering av funktioner är  versionskontrollgrenning . En förgreningsstrategi som Gitflow väljs för att definiera protokoll över hur ny kod slås samman till standardgrenar för utveckling, testning och produktion. Ytterligare funktionsgrenar skapas för sådana som tar längre utvecklingscykler. När funktionen är klar kan utvecklarna slå samman ändringarna från funktionsgrenar till den primära utvecklingsgrenen. Detta tillvägagångssätt fungerar bra, men det kan bli svårt att hantera om det finns många funktioner som utvecklas samtidigt.

Själva byggprocessen automatiseras sedan genom att förpacka all programvara, databas och andra komponenter. Till exempel, om du utvecklade ett Java-program, skulle CI paketera alla statiska webbserverfiler som HTML, CSS och JavaScript tillsammans med Java-applikationen och eventuella databasskript.

CI paketerar inte bara all programvara och databaskomponenter utan automatiseringen kommer också att utföra enhetstester och andra tester. Denna testning ger feedback till utvecklare att deras kodändringar inte bryter mot några befintliga enhetstester.

De flesta CI / CD-verktyg låter utvecklare starta builds on demand, utlöst av kodförpliktelser i versionskontrollförvaret eller enligt ett definierat schema. Team måste diskutera det byggschema som fungerar bäst för teamets storlek, antalet förväntade dagliga åtaganden och andra applikationsöverväganden. En bästa praxis för att säkerställa att åtaganden och byggningar är snabba, annars kan det hindra framstegen hos lag som försöker koda snabbt och begå ofta.

Kontinuerlig testning går utöver testautomatisering

Automatiserade testramar hjälper kvalitetssäkringsingenjörer att definiera, utföra och automatisera olika typer av tester som kan hjälpa utvecklingsteam att veta om en programvarukonstruktion klarar eller misslyckas. De inkluderar funktionstester som utvecklas i slutet av varje sprint och samlas till ett regressionstest för hela applikationen. Dessa regressionstester informerar sedan teamet om en kodändring misslyckades med ett eller flera av de tester som utvecklats över alla funktionella områden i applikationen där det finns testtäckning.

En bästa praxis är att aktivera och kräva att utvecklare kör alla eller en delmängd av regressionstester i sina lokala miljöer. Det här steget säkerställer att utvecklare endast begår kod för versionskontroll efter att regressionstest skickar kodändringarna vidare.

Regressionstest är bara början. Prestandatestning, API-testning, statisk kodanalys, säkerhetstestning och andra testformulär kan också automatiseras. Nyckeln är att kunna utlösa dessa tester antingen via kommandorad, webhook eller webbtjänst och att de svarar med framgång eller misslyckas med statuskoder.

När testet är automatiserat innebär kontinuerlig testning att automatiseringen är integrerad i CI / CD-pipelinen. Vissa enhets- och funktionstester kan integreras i CI som flaggar problem före eller under integrationsprocessen. Tester som kräver en fullständig leveransmiljö som prestanda och säkerhetstest integreras ofta i CD och utförs efter att bygg levereras till målmiljöer.

CD-pipelinen automatiserar ändringar i flera miljöer

Kontinuerlig leverans är automatiseringen som driver applikationer till leveransmiljöer. De flesta utvecklingsteam har vanligtvis en eller flera utvecklings- och testmiljöer där applikationsändringar genomförs för testning och granskning. Ett CI / CD-verktyg som Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo eller Travis CI används för att automatisera stegen och tillhandahålla rapportering.

En typisk CD-pipeline har bygga, testa och distribuera steg. Mer sofistikerade rörledningar inkluderar många av dessa steg:

  • Hämtar kod från versionskontroll och kör en build.
  • Utföra alla nödvändiga infrastruktursteg som automatiseras som kod för att stå upp eller riva ner molninfrastruktur.
  • Flytta kod till måldatumiljön.
  • Hantera miljövariablerna och konfigurera dem för målmiljön.
  • Att skicka applikationskomponenter till deras lämpliga tjänster, såsom webbservrar, API-tjänster och databastjänster.
  • Utföra alla steg som krävs för att starta om tjänster eller sluta servicepunkter som behövs för nya kodtryckningar.
  • Utföra kontinuerliga tester och återställningsmiljöer om tester misslyckas.
  • Tillhandahåller loggdata och varningar om leveransstatus.

Som ett exempel definierar Jenkins-användare sina pipelines i en Jenkinsfile som beskriver olika stadier som att bygga, testa och distribuera. Miljövariabler, alternativ, hemliga nycklar, certifieringar och andra parametrar deklareras i filen och refereras sedan i steg. Inläggssektionen hanterar felvillkor och meddelanden.  

Mer sofistikerad CD kan ha andra steg som att utföra datasynkronisering, arkivera informationsresurser eller utföra program- och biblioteksplåster. CI / CD-verktyg stöder vanligtvis en marknadsplats för plug-ins. Till exempel listar Jenkins mer än 1 500 insticksprogram som stöder integration med tredjepartsplattformar, användargränssnitt, administration, källkodshantering och bygghantering.

När ett CI / CD-verktyg har valts måste utvecklingsteam se till att alla miljövariabler är konfigurerade utanför applikationen. CI / CD-verktyg gör det möjligt att ställa in dessa variabler, maskera variabler som lösenord och kontonycklar och konfigurera dem vid tidpunkten för distribution för målmiljön.

CD-verktyg ger också instrumentpanel och rapporteringsfunktioner. Om bygg eller leveranser misslyckas varnar de utvecklare med information om misslyckandena. De integreras med versionskontroll och smidiga verktyg, så att de kan användas för att leta upp vilka kodändringar och användarberättelser som utgör en byggnad.

Implementering av CI / CD-rörledningar med Kubernetes och serverlösa arkitekturer 

Många lag som driver CI / CD-rörledningar i molnmiljöer använder också behållare som Docker och orkestrationssystem som Kubernetes. Behållare möjliggör förpacknings- och leveransapplikationer på standard, bärbara sätt. Behållare gör det enkelt att skala upp eller riva ner miljöer med varierande arbetsbelastning.

Det finns många sätt att använda containrar, infrastruktur som kod och CI / CD-rörledningar tillsammans. Du kan utforska alternativen genom att arbeta igenom handledning som Kubernetes med Jenkins eller Kubernetes med Azure DevOps.

Serverlösa datorarkitekturer presenterar en annan väg för att distribuera och skala applikationer. I en serverlös miljö hanteras infrastrukturen helt av molntjänstleverantören och applikationen förbrukar resurser efter behov baserat på dess konfiguration. På AWS kan till exempel serverlösa applikationer köras som Lambda-funktioner och distributioner integreras i en Jenkins CI / CD-pipeline med ett plugin-program. 

CI / CD möjliggör mer frekventa koddistributioner

För att sammanfatta, bygger CI-paket och testar programvara och varnar utvecklare om deras ändringar misslyckades med några enhetstester. CD är automatiseringen som levererar ändringar i infrastrukturen och utför ytterligare tester. 

CI / CD-rörledningar är utformade för företag som vill förbättra applikationer ofta och kräver en pålitlig leveransprocess. Den extra ansträngningen att standardisera byggnader, utveckla tester och automatisera distributioner är tillverkningsprocessen för distribution av kodändringar. En gång på plats gör det det möjligt för team att fokusera på processen att förbättra applikationer och mindre på systemdetaljerna för att leverera den till datormiljöer.

CI / CD är en devops bästa praxis eftersom den åtgärdar feljusteringen mellan utvecklare som vill driva ändringar ofta, med operationer som vill ha stabila applikationer. Med automatisering på plats kan utvecklare driva ändringar oftare. Verksamhetsteam ser större stabilitet eftersom miljöer har standardkonfigurationer, det testas kontinuerligt i leveransprocessen, miljövariabler är separerade från applikationen och återställningsprocedurer automatiseras.

Effekten av implementering av CI / CD-rörledningar kan mätas som en devops key performance indicator (KPI). KPI: er som distributionsfrekvens, ändring av ledtid och genomsnittlig tid till återställning (MTTR) från en incident förbättras ofta när CI / CD med kontinuerlig testning implementeras. CI / CD är dock bara en process som kan driva dessa förbättringar, och det finns andra förutsättningar för att förbättra distributionsfrekvenser.

Att komma igång med CI / CD kräver utvecklingsteam och operativa team att samarbeta om teknik, praxis och prioriteringar. Team måste utveckla enighet om rätt tillvägagångssätt för sin verksamhet och teknik så att när CI / CD är på plats är teamet ombord med följande metoder konsekvent.