Hva er CI/CD?

CI/CD er en forkortelse som utviklere tar for gitt, men som sjelden blir forklart for den som bestiller programvaren. Likevel er det en av arbeidsmåtene som mest direkte påvirker hvor raskt og trygt dere får nye funksjoner. Nedenfor forklarer vi hva det betyr, og hvorfor du bør bry deg.

Et samlebånd for kode

CI/CD er den automatiserte flyten som tar en kodeendring hele veien til en produksjonssatt funksjon: å bygge, teste og levere programvare uten manuelle håndgrep. Tenk på det som et samlebånd i en fabrikk. En endring legges inn i den ene enden, og ut i den andre kommer en testet, ferdig funksjon i produksjon, uten at noen trenger å skru for hånd underveis.

Alternativet er å bygge, teste og produksjonssette manuelt, og det er tregt og risikabelt. Hvert manuelt steg er en mulighet for menneskelige feil, og det gjør at man kvier seg for å levere ofte. CI/CD automatiserer bort disse stegene slik at det å levere noe nytt blir hverdag i stedet for en nervøs begivenhet.

Forkortelsen rommer to deler, og de er verdt å skille fra hverandre.

CI og CD hver for seg

CI (continuous integration) handler om å integrere ny kode fortløpende. Så snart en utvikler gjør en endring, integreres den med resten av koden og testes automatisk. Poenget er å oppdage problemer med en gang, mens de er små og lette å rette, i stedet for å la feil hope seg opp i det stille til alt skal settes sammen til slutt.

CD (continuous delivery) tar over der CI slutter, og fører den testede koden videre mot produksjon, også det automatisert. I sin fulle form (continuous deployment) går en godkjent endring hele veien ut til brukerne av seg selv. Kjernen er at veien fra «koden fungerer» til «koden er i drift» skal være kort og pålitelig.

Sammen danner de en ubrutt flyt: endre, integrere, teste og levere, automatisk, om og om igjen.

Nytten for deg som kunde: Lite og ofte slår mye og sjelden

Dette er ikke bare teknisk hygiene. Det påvirker direkte hva dere får ut som kunde. Den sentrale innsikten er at små, hyppige leveranser er tryggere enn store, sjeldne.

Slipper man ut én liten endring om gangen, er det enkelt å peke ut hva som gikk galt hvis noe svikter, og å rette det raskt. En stor versjon som samler måneder med arbeid, blander inn dusinvis av endringer på én gang. Går noe galt, blir det detektivarbeid å finne årsaken, og skaden rekker å bli større. Med CI/CD når nye funksjoner og rettelser brukerne oftere, med mindre risiko, og teamet bruker tiden på å bygge i stedet for på å presse ut nye versjoner manuelt.

Tenk deg forskjellen konkret. Et team uten CI/CD samler opp tre måneders endringer og slipper alt ut en fredag kveld. Noe går galt, men hvilken av alle endringene som forårsaket det, er umulig å vite med en gang, og helgen går med til feilsøking under press. Et team med CI/CD ville i stedet ha sluppet ut hver lille bit fortløpende gjennom de tre månedene. Hadde noe gått galt underveis, ville det ha vist seg umiddelbart, knyttet til akkurat den endringen, og kunnet rettes på minutter. Det er det samme arbeidet, men med dramatisk ulik risiko.

Spørsmålet du bør stille leverandøren

Du trenger ikke å forstå de tekniske detaljene for å se om en leverandør har orden på dette. Det holder med ett spørsmål:

Hvor lang tid tar det hos dere fra en godkjent endring til den er i produksjon?

Svaret sier overraskende mye. Handler det om minutter eller timer, har de trolig en moden, automatisert flyt og kan levere trygt og ofte. Handler det om uker, med manuelle steg og egne «publiseringsvinduer», tyder det på en tungvint og risikofylt arbeidsmåte. Det er et enkelt spørsmål som avslører mer om hvordan et team faktisk jobber, enn mange dyptgående tekniske diskusjoner.

Vil dere ha hjelp til å sette opp en flyt som gjør leveransene deres raske og trygge, tar vi i Weapp gjerne med dette i systemarbeidet fra start.