Kontinuerlig integration och kontinuerlig leverans – CI och CD – är en uppsättning driftsprinciper och insamling av metoder som blivit allt populärare. De gör det möjligt för applikationsutvecklingsteam att leverera kodändringar oftare och mer pålitligt.

Vår amerikanska systertidning Infoworld har tittat närmare på vad det egentligen handlar om.

Vad är CI och CD?

Continuous integration, kontinuerlig integration eller CI är i grunden en kodningsfilosofi och en uppsättning metoder som ska driva på utvecklingsteam att att med täta mellanrum implementera små förändringar i koden och sedan hantera den nya versionen i kodbaser.

I grunden handlar det om att de flesta moderna applikationer kräver utveckling av kod i olika plattformar och verktyg och då behöver teamen en mekanism för att integrera och validera dess förändringar.

Det tekniska målet för kontinuerlig integtation är att etablera ett konsekvent och automatiserat sätt att bygga, paketera och testa applikationer. Om det finns en konsekvent integrationsprocess på plats blir det helt enkelt enklare för utvecklingsteamen att göra kodändringar oftare och tanken är att det leder till bättre samarbete och att mjukvaran får bättre kvalitet.

Continuous delivery, kontinuerlig leverans eller CD tar vid där CI slutar genom att automatisera leveransen av applikatoner till utvalda infrastrukturmiljöer De flesta team arbetar med fler miljöer än bara produktionen – som utvecklings- och testmiljöer. CD ser till att det finns ett automatiserat sätt att överföra kodändringar mellan dem.

Med CI- och CD-verktyg lagras de parametrar från de olika miljöerna som måste paketeras med varje leverans. Sedan automatiserar de 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.

I nästa steg kräver CI och CD ytterligare ett continuous – nämligen kontinuerlig testning eftersom målet är att leverera kvalitetsapplikationer och kod till användare. Kontinuerlig testning implementeras ofta som en del i den automatiseringspipeline som byggs av CI och CD.

Hur kan CI förbättra kvaliteten?

De som använder kontinuerlig integration lägger också sin kod i kodbaser där den nya versionen hanteras och de flesta team har en miniminivå där de lägger in kod åtminstone en gång om dagen.

Skälet till det är att det är lättare att identifiera problem med mjukvarukvaliteten när det skiljer mindre i koden än när det skiljer mer efter att ha utvecklats under lång tid. Dessutom, när utvecklare arbetar i kortare cykler, är det mindre troligt att flera utvecklare redigerar samma kod som sedan måste slås ihop.

Team som implementerar kontinuerlig integration börjar ofta med versionskonfigurering och att definiera hur det ska göras. Trots att kontroll av kod utförs ofta så implementeras samtidigt funktioner och korrigeringar med både kortare och längre tidsramar. Utvecklingsteam som utövar kontinuerlig integration använder olika tekniker för att ha koll på vilka funktioner och kod som är redo för produktion.

Många team använder sig av så kallade feature flags som är en konfigurationsmekanism för att slå på och av funktioner och kod under körning. Funktioner som fortfarande utvecklas flaggas i koden och när koden distribueras för produktion är funktionen avstängd tills den är redo att användas.

Ett annat sätt att hantera olika funktioner är att förgrena versionshanteringen. Exempelvis kan man välja strategin Gitflow för att definiera protokoll för hur ny kod slås samman till standardgrenar för utveckling, testning och produktion. Ytterligare funktionsgrenar skapas för sådana som har längre utvecklingscykler.

När funktionen väl är klar så kan utvecklarna slå samman ändringarna från funktionsgrenarna till den primära utvecklingsgrenen. Det är en strategi som fungerar bra, men det kan bli svårt att hantera om det finns många funktioner som utvecklas samtidigt.

Vad innebär kontinuerlig testning?

Ramverk för automatiserad testning är ett stöd för att definiera, genomföra och automatisera olika typer av tester som kan hjälpa utvecklingsteam att se om mjukvara de arbetar med kommer att godkännas eller inte.

De inkluderar funktionalitetstester som utvecklas i slutet av varje sprint och sammanförs till ett regressionstest – där man kollar om den befintliga koden påverkas av den nya – för hela applikationen.

En etablerad praxis är att kräva att utvecklare kör hela eller en delmängd sådana regressionstester i sina lokala miljöer. På så sätt kan man se till att utvecklarna endast skriver kod som går till versionshantering efter att ändringarna klarat ett regressionstest.

Men regressionstester är bara början. Prestandatestning, api-testning, statisk kodanalys, säkerhetstestning och andra testformer kan också automatiseras. Nyckeln är att kunna utlösa dessa tester genom exempelvis en kommandorad eller en webbtjänst och att de ger svar genom statuskoder för framgång eller misslyckande.

När testningen är automatiserad innebär kontinuerlig testning att automatiseringen är integrerad i CI- och CD-pipelinen. Vissa enhets- och funktionalitetstester kan integreras i den kontinuerliga integrationen som flaggar problem före eller under integrationsprocessen och test som kräver en full leveransmiljö som prestanda och säkerhetstest integreras ofta i den kontinuerliga leveransen.

Hur automatiseras ändringar till olika miljöer?

Kontinuerlig leverans är den automatisering som får ut applikationer till leveransmiljöer. En typisk CD- pipeline har stadier för att bygga, testa och distribuera. I mer sofistikerade pipelines kan det också finnas fler steg som exempelvis att flytta kod till datormiljön, hantera variabler för olika miljöer och konfigurera dem för målmiljön, skjuta ut applikationskomponenter till deras lämpliga tjänster, till exempel webbservrar, api-tjänster och databastjänster eller att tillhandahålla loggdata och varningar om leveransen.

När man valt ett CI- och CD-verktyg så måste utvecklingsteamen se till att de olika miljövariablerna konfigureras utanför applikationen. Verktygen ser till att maskera variabler som läsenord och konfigurera dem när de distribueras till målmiljön.

Hur fungerar det med serverlös arkitektur?

Många team som använder sig av CI- och CD-pipelines i molnmiljöer använder sig också av containrar som Docker och orkestreringssystem som Kubernetes som automatiserar samordning av program och tjänster för att utföra en uppgift i ett datorsystem. Containrar gör det lätt att skala upp eller riva ner miljöer som har varierande belastning.

Serverlösa datorarkitekturer använder sig av andra sätt för att distribuera och skala applikationer. I en serverlös miljö hanteras infrastrukturen helt av molntjänsteleverantören och applikationen förbrukar resurser efter behov baserat på dess konfiguration.

Vad är vitsen för verksamheten?

Med CI och CD kan man komma till rätta med obalansen mellan utvecklare som vill få ut förändringar hela tiden och verksamheten som vill ha stabila applikationer. När det finns fungerande automatisering går det att göra ändringar oftare utan att stabiliteten påverkas eftersom miljöerna är konfigurerade på ett standardiserat sätt, testande sker kontinuerligt i leveransprocessen och miljövariablerna är separerade från applikationen.

Läs också: SPP byter plattform för hundratals miljoner – ”vi har tagit ledartröjan”