Oversigt over CI/CD-arbejdsgangen: Hvorfor du bør kende til den

Kontinuerlig integration og kontinuerlig levering (CI/CD) er de gravitationsfelter, som den moderne DevOps-arbejdsgang kredser omkring. Organisationer, der ønsker at bygge omkostningseffektiv og relativt fejlfri kode med høj hastighed, må omfavne CI/CD-pipelines som en vital arkitektur i deres softwareleveringssystem.

Før pipelines til kontinuerlig integration og kontinuerlig levering blev populære, blev kodeændringer introduceret manuelt i produktionssystemer gennem ad hoc-arbejdsgange, ofte uden standardiseret testning. Heldigvis har jeg overlevet til at fortælle de gruopvækkende historier om at arbejde i softwaretestmiljøer, der mangler disse vitale processer.

Omvendt har jeg på første hånd set, hvordan CI/CD-værktøjer og -processer udgør en effektiv ramme for hurtigt og pålideligt at levere software af høj kvalitet.

Med udgangspunkt i min arbejdserfaring vil jeg forklare, hvad der udgør en CI/CD-pipeline, hvordan den fungerer, og hvorfor softwareudviklingsteams både praktisk og filosofisk har taget den til sig sammen med andre principper såsom den agile testmetode.

Hvad er en CI/CD-pipeline?

En CI/CD-pipeline er en transparent, automatiseret og pålidelig proces til softwareudvikling og -levering. En CI/CD-leveringspipeline består af to særskilte komponenter: kontinuerlig integration og kontinuerlig levering, som understøtter en agil DevOps-arbejdsgang.

Begge komponenter er i høj grad afhængige af automatisering for at reducere fejl og sikre softwareudvikling af høj kvalitet ved at eliminere besværlige manuelle processer. Grundlæggende leverer en CI/CD-pipeline derfor en række trin til automatiseret softwarelevering.

CI-delen opfordrer udviklere, programmører og softwareingeniører til at bygge software ved hyppigt at skrive kode og køre test. De opfordres til regelmæssigt at tjekke deres kodeændringer og nye funktionalitet ind i små kildekodebatcher i et kodelager.

CD-delen sikrer derimod, at en softwareorganisation altid har en implementeringsklar softwareartefakt, som allerede er kvalitetssikret og valideret gennem sikkerhedstjek.

De fire vigtigste faser i en CI/CD-pipeline

Kildefase

Dette er begyndelsen på pipelinen. Den udløses eller initieres, når en udvikler foretager en ændring i en kodebase. Det sker typisk, når en udvikler udfører kommandoen git push eller git merge for at indsende kildekode til kodelageret i et versionsstyringssystem.

Byggefase

Byggefasen er for det meste kompileringsfasen. I containerbaserede mikrotjenestesystemer som Docker indebærer dette, at projektets kildekode og dens afhængigheder samles i selvstændige enheder. Disse kompileres efterfølgende for at bygge en kørbar instans af softwareapplikationen. Det skal dog bemærkes, at kompileringstrinnet er nødvendigt for sprog som Java og C++. Kompilering springes imidlertid over for fortolkede sprog som Python og JavaScript.

Når en softwareartefakt ikke består denne fase, indikerer det ofte fundamentale underliggende problemer som dårlig arkitektonisk konfiguration. Det betyder uundgåeligt, at softwarearkitekterne og -ingeniørerne må begynde forfra for at løse problemet.

Testfase

Som navnet antyder, er dette pipelinefasens testfase. Her viser den indbyggede automatisering i en CI/CD-pipeline sit værd ved at spare teamet for tid og kræfter. Forskellige test som basistests, enhedstest og integrationstest automatiseres og udføres for at vurdere applikationens gyldighed og logik.

Implementeringsfase

I implementeringsfasen frigives den testede, kørbare instans af applikationen til det påkrævede implementeringsmiljø. Organisationer vedligeholder typisk flere stagingmiljøer af forskellige årsager.

Alfa-miljøer bruges for eksempel til brugeraccepttest for at identificere fejl i applikationen, før den frigives til produktbrugere. Beta er en begrænset udgivelse til nogle få udvalgte brugere; derefter er der produktionsmiljøet til den brede offentlighed. Implementeringsfasen eksemplificeres af behovet for at opretholde et acceptabelt niveau af kvalitetssikring.

Hvad er kontinuerlig integration (CI)?

CI betyder kontinuerlig integration, mens CD står for kontinuerlig levering. Sammen sikrer de, at DevOps-teams har en bæredygtig metode til at generere pålidelige softwareudgivelser. Sammen forkorter de tidsforløbet mellem idé, konceptudvikling og produktion af brugbar software. 

Disse to søjler i den moderne softwareleveringspipeline er dog hverken to sider af samme mønt eller yin og yang for det samme fænomen.

Både kontinuerlig integration og kontinuerlig levering er nuancerede og tilstrækkeligt forskellige til at fortjene hver sin behandling og en dybdegående definition.

Hvorfor er CI nødvendigt?

CI's rolle er at levere en strømlinet, pålidelig og automatiseret proces til at skrive, bygge og teste softwareapplikationer. Som proces er CI rettet mod at bygge, teste og flette kildekode ind i et projekts kodebase flere gange om dagen.

CI-processen søger også at levere et ensartet niveau af softwareproduktivitet. Det opnås ved at fremme DevOps-praksisser, der tilskynder til automatiseret test og hyppig fletning af ny kode ind i et centralt repository.

Udviklere producerer typisk regelmæssigt store mængder kildekode, enten for at bygge ny funktionalitet eller rette fejl i eksisterende funktioner. Programmører arbejder dog sjældent isoleret; de indgår i udviklingsteams, hvor samarbejde med andre kodere er afgørende for projektets succes.

Derfor er det skadeligt for resten af teamet at lade deres kode ligge på deres lokale computere i længere tid. Blandt andre årsager kan integration af ny kode for sent i udgivelsescyklussen utilsigtet ødelægge anden funktionalitet.

Værktøjer til kontinuerlig integration maksimerer praksissen med at tilskynde udviklere til at flette deres kodeændringer ind i teamets delte repository. Helst flere gange om dagen.

Hvad er kontinuerlig levering (CD)?

Som nævnt ovenfor kommer kontinuerlig levering efter kontinuerlig integration. Det omfatter de processer og den infrastruktur, der understøtter forberedelsen af kodeændringer til udgivelse i produktionsmiljøet. Det overordnede mål med CD er at sikre, at en organisation altid har et bygget, testet, valideret og udrulningsklart softwareartefakt i sin pipeline.

CD-infrastrukturen til klargøring og udrulning søger at levere en hurtig, men bæredygtig og fejlfri pipeline til forberedelse og udgivelse af softwarebuilds i produktion. Den søger også at reducere den tid, der kræves til at udføre sikkerhedskontroller og udrulle softwareartefakter.

Hvorfor CD?

Ligesom kontinuerlig integration er CD-værktøjer i høj grad afhængige af automatisering og automatiserede tests for at validere integriteten af et softwarebuild, før det udrulles. Processen gør det også muligt for softwareingenørteams at etablere en kvalitetsbaseline for deres kode før produktion.

Det skal bemærkes, at selvom kontinuerlig levering er en automatiseret proces, er manuel indgriben stadig nødvendig i denne fase af pipelinen.

Forskellen mellem kontinuerlig levering og kontinuerlig udrulning

Både kontinuerlig levering og udrulning har samme formål, men udførelsen er markant forskellig.

• Kontinuerlig udrulning: Alle kodeændringer, der flettes ind i kodebasen, udrulles automatisk i produktion. Der er ingen godkendelsesmekanisme eller manuel proces, der fungerer som en forebyggende sikkerhedsventil. Det er en fuldt automatiseret proces til selve udrulningen.
• Kontinuerlig levering er en delvist manuel proces, men den gør det langt mere sandsynligt, at udgivelsesstrategien bliver sikrere og bæredygtig.

Hvorfor er en CI/CD-pipeline vigtig i DevOps?

Et historisk perspektiv er nødvendigt for at forstå behovet for og udviklingen af nutidens metoder til softwarelevering. I de tidlige faser af udviklingen af softwareapplikationer var vandfaldsmodellen populær.

Denne simple model håndterede et softwareprojekt ved at opdele det i sekventielle, lineære faser. Den fulgte en rigid metode, der ikke tillod overlapning af faserne – én fase skulle være afsluttet, før den næste kunne begynde. Desuden var hvert trin afhængigt af leverancerne fra det foregående.

Derfor krævede den overordnede model en vis specialisering af opgaverne for at fungere. Denne specialisering tvang imidlertid softwareingeniør- og testteams til at være adskilt i deres egne siloer, hvor udviklere, testere og driftspålidelighedsingeniører ofte arbejdede isoleret.

Vandfaldsmodellen

Vandfaldsmodellen var ideel i en tid, hvor softwarevirksomheder sendte produkter til forbrugerne på indpakkede cd'er med offentligt annoncerede lanceringsdatoer. Modellen er dog uegnet til den moderne tid, hvor der lægges vægt på produktion af kode i højt tempo. Det gælder især med cloud computing og de allestedsnærværende software-som-en-tjeneste-modeller (SaaS), som har øget slutbrugernes forventninger til løbende softwareforbedringer og kontinuerlig implementering af funktioner.

Af et utal af årsager har vandfaldsmodellen vist sig at være utilstrækkelig.

Sammen med bedste praksis såsom den agile metode integrerer moderne DevOps-teams CI/CD-pipelines for at levere software af høj kvalitet, der er grundigt testet, med høj hastighed og på en bæredygtig måde.

Gennem DevOps tilbyder CI/CD en praktisk måde at bygge bro mellem siloerne mellem programmører, driftsteams og andre deltagere i processen for softwareudvikling og -levering.

Principperne bag CI/CD reducerer risiko og usikkerhed, især i forbindelse med komplekse projekter, der skal være fleksible nok til at imødekomme ofte skiftende krav.

Fordelene ved at implementere en CI/CD-pipeline

Nogle af fordelene ved en CI/CD-pipeline er åbenlyse, såsom indbygget automatisering, der drastisk reducerer fejlbehæftede manuelle processer. Her er et par andre fordele ved CI/CD-pipelines:

• At gøre udrulningsprocesser så friktionsfri som muligt. En CI/CD-pipeline giver IT-operatører en relativt brugervenlig og enkel proces, der reducerer kompleksiteten ved at bygge og udrulle applikationer. Denne forenklede proces understøttes i høj grad af den indbyggede automatiseringsfunktionalitet i CI/CD.
• At øge driftshastigheden. Hurtigere produktiteration er mulig på grund af automatisering og hurtigere feedbacksløjfer. Automatisering giver DevOps-teknikere øjeblikkelig information om, hvorvidt en kompilering er levedygtig.
  
  Det er de mindre CI-integrationer og mindre CD-udrulninger, der forbedrer DevOps-målinger såsom den gennemsnitlige tid til løsning (MTTR). MTTR måler den gennemsnitlige tid, det tager at rette ødelagte funktioner og fejl, herunder at diagnosticere underliggende problemer. Den samlede CI/CD-proces reducerer den tid, der kræves til fejlfinding, test, kompilering og udrulning af en applikation.
• At øge produktiviteten: Det vigtigste princip i kontinuerlig integration er at opfordre udviklere til ofte at flette deres kode ind i organisationens hovedgren. Dette øger sandsynligheden for, at alle medlemmer af DevOps-teamet har den seneste fungerende kode.
  
  Dette er afgørende, eftersom arbejdet med den seneste iteration af kodebasen beskytter alle mod at arbejde ud fra forældede antagelser om projektet, dets aktuelle funktioner og muligheder. Det øger produktiviteten og samarbejdet om softwareprojekter. Det forbedrer igen organisationens samlede leveringstid til markedet for produkter.
• At forkorte udgivelsescyklussen og samtidig have mulighed for at udgive software efter behov. I vores digitale tidsalder har virksomheder brug for fleksibilitet for at forblive levedygtige ved hurtigt at reagere på markedsændringer. Teknologikyndige kunder efterspørger i stigende grad avancerede funktioner såsom personalisering og banebrydende AI-funktionalitet.
  
  For at følge med tidens skiftende krav hjælper CI/CD-pipelines ikke kun organisationer med at øge hastigheden på softwareleveringen, så de kan reagere på markedet, men også med at holde deres softwarearsenal i en tilstand, hvor det altid kan udgives.
• At have mulighed for at prioritere udrulninger af funktioner. Ud over at øge driftshastigheden gør CI/CD-infrastrukturen det muligt for siteingeniører at fremhæve de funktioner, der skal udrulles med det samme eller prioriteres over andre.
• At opdage fejl hurtigere og udbedre problemer hurtigere. Da kodeændringer integreres oftere, gør CI det lettere at opdage og rette fejl, fejlkoder og andre inkompatibiliteter langt tidligere i softwareudviklingsprocessen. Dette er især relevant ved fejlrettelser med høj prioritet for udrulning, særligt dem, der retter nul-dagsfejl.
• At reducere fejl og begrænse risikoen. CI/CD giver flere lag af sikkerhedsforanstaltninger og beskyttelse gennem hele udviklingslivscyklussen og udrulningsfaserne. Den kumulative effekt af disse fejlsikre og fejlbegrænsende mekanismer reducerer den risikoeksponering, som softwareudviklingsteams står over for, når de skal producere levedygtig kode.
  
  Den indbyggede automatisering og automatiserede test i CI/CD-pipelinen fremmer kontinuerlig test med procedurer såsom enhedstest, integrationstest, regressionstest og så videre. CI/CD-systemer udsender også forskellige notifikationer under kompileringsfasen, som advarer IT-chefer og siteingeniører, når noget går galt.
• Forbedrer kvalitetskontrollen og minimerer risikoen for menneskelige fejl. Automatisering fjerner behovet for fejlbehæftet menneskelig indgriben. CI udløser en ny kompilering, hver gang kodeændringer flettes ind i det centrale arkiv. Dette ledsages normalt af enhedstest og integrationstest for at sikre, at den nye kode er kompatibel med systemet. Denne stort set friktionsfri proces er bedste praksis, som tilfører systemet en grad af kvalitetskontrol og kvalitetssikring.
• At fremme eksperimentering og innovation. DevOps-tankegangen med at introducere små kodebidder styrker innovation. Primært fordi processen indebærer en langt mindre risikoeksponering, hvilket giver teams større frihed til at eksperimentere og innovere. Dette fremmer opstartsmentaliteten om at "bevæge sig hurtigt og ødelægge ting."
• At skabe pålidelige udgivelser. Som nævnt ovenfor indebærer udrulning af hyppige, men små softwarebatcher mindre risiko. Det mindre udrulningsomfang er også lettere at administrere, især når det gælder om at finde ud af, om der er introduceret fejl i systemet. I de fleste tilfælde kan det være så enkelt som at identificere den seneste udrulning, der udløste fejlen. 

Afsluttende tanker

CI/CD-pipelines er en vigtig funktion i moderne softwareudvikling og bidrager til at producere softwareprodukter af høj kvalitet i en hastigt udviklende softwarebranche. 

Hvis du vil lære mere om moderne, banebrydende fremskridt i techbranchen, abonnér på The QA Lead-nyhedsbrevet.