Vad är CI/CD?

CI/CD är en förkortning som utvecklare tar för given men som sällan förklaras för den som beställer mjukvaran. Ändå är det ett av de arbetssätt som mest direkt påverkar hur snabbt och tryggt ni får nya funktioner. Här är vad det betyder, och varför du bör bry dig.

Ett löpande band för kod

CI/CD är det automatiserade flödet som tar en kodändring hela vägen till en driftsatt funktion – att bygga, testa och släppa mjukvara utan manuella handgrepp. Tänk på det som ett löpande band i en fabrik: en ändring läggs in i ena änden, och ut i andra kommer en testad, färdig funktion i produktion, utan att någon behöver skruva för hand längs vägen.

Alternativet – att bygga, testa och driftsätta manuellt – är långsamt och riskabelt. Varje manuellt steg är ett tillfälle för mänskliga misstag, och det avskräcker från att släppa ofta. CI/CD automatiserar bort de stegen, så att släppa nytt blir vardag i stället för en nervös händelse.

Förkortningen rymmer två delar, och de är värda att skilja på.

CI och CD, var för sig

CI – continuous integration handlar om att foga samman ny kod löpande. Så fort en utvecklare gör en ändring integreras den med resten av koden och testas automatiskt. Poängen är att upptäcka problem direkt, medan de är små och lätta att rätta, i stället för att låta fel byggas upp i det tysta tills allt ska sättas ihop på slutet.

CD – continuous delivery tar vid där CI slutar och för den testade koden vidare mot produktion, också det automatiserat. I sin fulla form (continuous deployment) går en godkänd ändring hela vägen ut till användarna av sig själv. Kärnan är att vägen från “koden fungerar” till “koden är i drift” ska vara kort och pålitlig.

Tillsammans bildar de ett obrutet flöde: ändra, integrera, testa, släppa – automatiskt, om och om igen.

Beställarnyttan: liten och ofta slår stor och sällan

Det här är inte bara teknisk hygien – det påverkar direkt vad ni får ut som beställare. Den centrala insikten är att små, täta releaser är tryggare än stora, sällsynta.

Släpper man en liten ändring i taget är det enkelt att peka ut vad som gick fel om något krånglar, och att snabbt rätta det. En stor release som samlar månaders arbete blandar in dussintals ändringar på en gång – går något snett blir det ett detektivarbete att hitta orsaken, och skadan hinner bli större. Med CI/CD når nya funktioner och rättningar användarna oftare, med mindre risk, och teamet lägger sin tid på att bygga i stället för på att manuellt kränga ut släpp.

Tänk dig skillnaden konkret. Ett team utan CI/CD sparar ihop tre månaders ändringar och släpper allt en fredag kväll. Något går fel, men vilken av alla ändringar som orsakade det är omöjligt att veta direkt, och helgen går åt till felsökning under press. Ett team med CI/CD hade i stället släppt varje liten bit löpande under de tre månaderna – hade något gått fel längs vägen syntes det omedelbart, kopplat till just den ändringen, och kunde rättas på minuter. Det är samma arbete, men med dramatiskt olika risk.

Frågan att ställa din leverantör

Du behöver inte förstå de tekniska detaljerna för att avläsa om en leverantör har ordning på det här. Det räcker med en fråga:

Hur lång tid tar det hos er från en godkänd ändring till att den är i produktion?

Svaret säger förvånansvärt mycket. Handlar det om minuter eller timmar har de troligen ett moget, automatiserat flöde – de kan släppa tryggt och ofta. Handlar det om veckor, med manuella steg och särskilda “släppfönster”, tyder det på ett tungrott och riskfyllt arbetssätt. Det är en enkel fråga som avslöjar mer om hur ett team faktiskt arbetar än många djupt tekniska diskussioner.

Vill ni ha hjälp att sätta upp ett flöde som gör era releaser snabba och trygga, tar vi på Weapp gärna med det i systemarbetet från start.