Continuous Integration, Delivery och Deployment: Vad är skillnaden?

Den här gången bygger CI/CD, eller Continuous Integration och Continuous Delivery/Continuous Deployment, väl vidare på varandra. Alla tre ligger i själva kärnan av vad DevOps strävar efter att uppnå. Därför är det dags att reda ut förkortningarna.

Vad är Continuous Integration?

Det första steget är CI, som står för Continuous Integration.

I Continuous Integration skickas en kodändring till ett externt repository när utvecklaren har gjort ändringen och bedömt den som klar. Då körs en uppsättning automatiserade tester av hela den ändrade koden på en server. Testerna, som omfattar regressionstester, säkerställer att ingen funktionalitet har gått förlorad när ny funktionalitet har lagts till eller förbättrats.

Beprövad praxis är dock att använda gated commits. Det innebär att en individs nyligen committade kod faktiskt testas innan den delas med andra utvecklare eller testare. Det uppmuntrar små ändringar som mergas ofta. Ändringarna blir därmed enkla att hantera, och mjukvarans status förbättras kontinuerligt eftersom den nya koden testas.

För att citera en avhandling av en person på Eficode: ”Continuous Integration utvecklades för att motverka problemen med \[en\] sekventiell modell för mjukvaruutveckling. När kraven samt analys-, design- och implementeringsfaserna var klara uppstod ofta betydande problem i integrationsfasen av mjukvaruprojekt.” (sida 11)

Sammanfattningsvis innebär Continuous Integration att du ofta bidrar med ny kod, och i dag triggar detta i de flesta fall automatiserade tester. Enligt de flesta är det en förutsättning för CD, eller Continuous Delivery.

CI kommer alltså tidigare i processen än Continuous Delivery och Continuous Deployment, som vi går igenom härnäst.

Vad är skillnaden mellan Continuous Delivery och Continuous Deployment?

CD kan betyda Continuous Deployment eller Continuous Delivery. Det finns bara en liten skillnad mellan de två DevOps-metoderna, och den ligger i den sista fasen.

Deployment definieras vanligtvis som att göra applikationen tillgänglig i en specifik miljö. Det är oftast produktionsmiljön som användarna har tillgång till.

Om applikationen körs på en webbplats eller hanteras av en centraliserad IT-avdelning har användarna inget annat val än att använda den. En deployment kan ändå innehålla funktioner som användarna inte känner till (kallas ”dark launch”) och som testas inför en framtida release. Som ordet antyder kommuniceras en release offentligt. När det gäller nedladdningsbar mjukvara är det också i hög grad upp till användaren om hen vill testa den eller inte.

I Continuous Delivery levereras applikationen genom acceptanstester i en isolerad testmiljö till ett läge där deployment till produktion bara är ett knapptryck bort. Vanligtvis fattas beslutet att trycka på knappen strategiskt av ledningen.

Eller som Eficodes Severi Haverila uttryckte det i sin avhandling: ”...den viktigaste principen för Continuous Delivery är att hålla mjukvaran i ett kontinuerligt driftsättningsbart tillstånd.” (sida 11)

Continuous Deployment (eller automatiserad deployment) är automatiskt hela vägen tills slutanvändarna får tillgång till den. Det tekniska förberedelsearbetet för båda CD-varianterna är därför i praktiken detsamma: att automatisera hela deployment-processen och göra den sista fasen manuellt styrbar om målet är Continuous Delivery.

Debatten fortsätter!

Precis som för alla definitioner – även definitionen av DevOps – pågår en debatt om vilken definition som är den slutgiltiga.

Ledande verktygsleverantörer som Atlassian och Puppet verkar ha nått en liknande syn på CI/CD som den som presenterades tidigare i texten.

Det är kanske för tidigt att säga om den kan betraktas som en de facto-definition. Precis som alla andra vanligt förekommande begrepp behöver den alltid förses med en tydlig definition utifrån det aktuella användningsfallet.

Samtidigt kommer framtidens studenter att behöva hantera förkortningar som fortfarande håller på att skapas. Branschen verkar dock vara överens om att CI/CD, eller automatisering i en vidare bemärkelse, är det som för utvecklare och drift närmare varandra.

I slutändan bör det göra att den utvecklade mjukvaran skapar värde på kortare tid.