Oversikt over CI/CD-pipelinen: Hvorfor du bør kjenne til den

Kontinuerlig integrasjon og kontinuerlig levering (CI/CD) er gravitasjonsfeltene som den moderne DevOps-arbeidsflyten kretser rundt. Organisasjoner som ønsker å utvikle kostnadseffektiv kode med relativt få feil i høyt tempo, må omfavne CI/CD-pipelines som en avgjørende arkitektur i systemet for programvarelevering.

Før pipelines for kontinuerlig integrasjon og kontinuerlig levering ble populære, ble kodeendringer manuelt introdusert i produksjonssystemer gjennom ad hoc-arbeidsflyter, ofte uten standardiserte tester. Heldigvis har jeg overlevd for å kunne fortelle de rystende historiene fra tiden jeg jobbet i programvaretestmiljøer som manglet disse viktige prosessene.

På den annen side har jeg selv sett hvordan CI/CD-verktøy og prosesser gir et effektivt rammeverk for å levere programvare av høy kvalitet raskt og pålitelig.

Med utgangspunkt i arbeidserfaringen min skal jeg forklare hva en CI/CD-pipeline består av, hvordan den fungerer, og hvorfor programvareutviklingsteam både praktisk og filosofisk har omfavnet den, sammen med andre prinsipper som den smidige testmetodikken.

Hva er en CI/CD-pipeline?

En CI/CD-pipeline er en transparent, automatisert og pålitelig prosess for utvikling og levering av programvare. En CI/CD-leveringspipeline består av to tydelige komponenter: kontinuerlig integrasjon og kontinuerlig levering, som legger til rette for en smidig DevOps-arbeidsflyt.

Begge komponentene er i stor grad avhengige av automatisering for å redusere feil og sikre programvareutvikling av høy kvalitet ved å eliminere krevende manuelle prosesser. Grunnleggende sett tilbyr derfor en CI/CD-pipeline en serie trinn for automatisert programvarelevering.

CI-delen oppmuntrer utviklere, programmerere og programvareingeniører til å bygge programvare ved å skrive kode og kjøre tester ofte. De oppfordres til å sjekke inn kodeendringer og ny funksjonalitet regelmessig, i små kildekodepartier, i et kodelager.

CD-delen sørger derimot for at en programvareorganisasjon alltid har en distribusjonsklar programvareartefakt som allerede er kvalitetssikret og validert gjennom sikkerhetskontroller.

De fire hovedfasene i en CI/CD-pipeline

Kildefase

Dette er begynnelsen på pipelinen. Den utløses eller initieres når en utvikler gjør en endring i et kodelager. Vanligvis skjer dette når en utvikler utfører kommandoen git push eller git merge for å sende kildekode inn i kodelageret til et versjonskontrollsystem.

Byggefase

Byggefase er for det meste kompileringsfasen. I mikrotjenestebaserte containersystemer som Docker innebærer dette å samle prosjektets kildekode og avhengigheter i selvstendige enheter. Disse kompileres deretter for å bygge en kjørbar instans av programvareapplikasjonen. Det bør imidlertid bemerkes at kompileringssteget er nødvendig for språk som Java og C++. Kompilering hoppes derimot over for tolkede språk som Python og JavaScript.

Når en programvareartefakt ikke består denne fasen, tyder det ofte på grunnleggende, underliggende problemer som dårlig arkitektonisk konfigurasjon. Dette betyr uunngåelig at programvarearkitektene og ingeniørene må gå tilbake til tegnebrettet for å løse problemet.

Testfase

Som navnet antyder, er dette testfasen i pipelinen. Her viser den innebygde automatiseringen i en CI/CD-pipeline sin verdi ved å spare teamet for tid og innsats. Ulike tester, som røyktester, enhetstester og integrasjonstester, automatiseres og gjennomføres for å vurdere applikasjonens gyldighet og logikk.

Distribusjonsfase

I distribusjonsfasen lanseres den testede, kjørbare instansen av applikasjonen i det nødvendige distribusjonsmiljøet. Organisasjoner vedlikeholder vanligvis flere staging-miljøer av ulike årsaker.

Alpha-miljøer brukes for eksempel til brukerakseptansetesting for å identifisere feil i applikasjonen før den lanseres for produktbrukerne. Beta er en begrenset lansering til noen få utvalgte brukere, og deretter har man produksjonsmiljøet for allmennheten. Distribusjonsfasen illustrerer behovet for å opprettholde et akseptabelt nivå av kvalitetssikring.

Hva er kontinuerlig integrasjon (CI)?

CI betyr kontinuerlig integrasjon, mens CD står for kontinuerlig utrulling. Sammen sørger de for at DevOps-teamene har en bærekraftig metode for å generere pålitelige programvarelanseringer. Sammen forkorter de tidsperioden mellom idé, konseptutvikling og produksjon av brukbar programvare. 

Disse to grunnpilarene i den moderne pipelinen for programvarelevering er imidlertid verken to sider av samme sak eller yin og yang for samme fenomen.

Både kontinuerlig integrasjon og kontinuerlig levering er nyanserte og forskjellige nok til å fortjene en egen gjennomgang og grundig definisjon.

Hvorfor trengs CI?

CI har som oppgave å tilby en strømlinjeformet, pålitelig og automatisert prosess for å skrive, bygge og teste programvareapplikasjoner. Som prosess er CI rettet mot å bygge, teste og slå sammen kildekode i et prosjekts kodebase flere ganger om dagen.

CI-prosessen har også som mål å sikre et jevnt nivå av programvareproduktivitet. Dette oppnås ved å fremme DevOps-praksiser som oppmuntrer til automatisert testing og hyppig sammenslåing av ny kode i et sentralt repositorium.

Utviklere produserer vanligvis store mengder kildekode med jevne mellomrom, enten for å bygge ny funksjonalitet eller rette feil i eksisterende funksjoner. Programmerere arbeider imidlertid sjelden isolert; de jobber i utviklingsteam der samarbeid med andre kodere er avgjørende for prosjektets suksess.

Det er derfor skadelig for resten av teamet å la koden ligge på de lokale datamaskinene over lengre tid. Blant annet kan integrering av ny kode for sent i utgivelsessyklusen utilsiktet ødelegge annen funksjonalitet.

Verktøy for kontinuerlig integrasjon maksimerer praksisen med å oppmuntre utviklere til å slå sammen kodeendringene sine i teamets delte repositorium. Helst flere ganger om dagen.

Hva er kontinuerlig levering (CD)?

Som nevnt ovenfor kommer kontinuerlig levering etter kontinuerlig integrasjon. Det omfatter prosessene og infrastrukturen som støtter klargjøringen av kodeendringer for lansering i produksjonsmiljøet. Det overordnede målet med CD er å sikre at en organisasjon til enhver tid har et bygget, testet, validert og distribusjonsklart programvareartefakt i prosesslinjen sin.

CD-infrastrukturen for klargjøring og distribusjon skal tilby en rask, men bærekraftig og feilfri prosesslinje for klargjøring og lansering av programvarebygginger i produksjon. Den skal også redusere tiden som kreves for å utføre sikkerhetskontroller og distribuere programvareartefakter.

Hvorfor CD?

På samme måte som kontinuerlig integrasjon er CD-verktøy i stor grad avhengige av automatisering og automatiserte tester for å validere integriteten til en programvarebygging før den distribueres. Prosessen gjør det også mulig for programvareutviklingsteam å etablere et kvalitetsgrunnlag for koden sin før produksjonssetting.

Det bør bemerkes at selv om kontinuerlig levering er en automatisert prosess, er manuell inngripen fortsatt nødvendig i denne fasen av prosesslinjen.

Forskjellen mellom kontinuerlig levering og kontinuerlig distribusjon

Kontinuerlig levering og kontinuerlig distribusjon har samme formål, men gjennomføringen er vesentlig forskjellig.

• Kontinuerlig distribusjon: Hver kodeendring som slås sammen med kodebasen, distribueres automatisk til produksjon. Det finnes ingen godkjenningsmekanisme eller manuell prosess som fungerer som en forebyggende sikkerhetsventil. Dette er en helautomatisert prosess for selve distribusjonen.
• Kontinuerlig levering er en delvis manuell prosess, men den gjør det langt mer sannsynlig at lanseringsstrategien blir sikrere og mer bærekraftig.

Hvorfor er en CI/CD-prosesslinje viktig i DevOps?

Det er nødvendig med et historisk perspektiv for å forstå behovet for og utviklingen av dagens metoder for programvarelevering. I de tidlige stadiene av utviklingen av programvareapplikasjoner var fossefallsmodellen den dominerende tilnærmingen.

Denne enkle modellen håndterte et programvareprosjekt ved å dele det opp i sekvensielle, lineære faser. Den fulgte en rigid metodikk som ikke tillot at fasene overlappet – én fase måtte fullføres før den neste kunne begynne. Dessuten var hvert trinn avhengig av leveransene fra det foregående trinnet.

Den overordnede modellen krevde derfor en viss spesialisering av oppgavene for å fungere. Denne spesialiseringen tvang imidlertid programvareutviklings- og testteamene til å bli separert i egne siloer, der utviklere, testere og driftssikkerhetsingeniører ofte arbeidet isolert.

Fossefallsmodellen

Fossefallsmodellen var ideell i en tid da programvareselskaper leverte produkter til forbrukere på innspilte CD-er, med offentlig annonserte lanseringsdatoer. Denne modellen egner seg imidlertid dårlig for vår tid, som verdsetter produksjon av kode i høyt tempo. Dette gjelder særlig med nettskybasert databehandling og de allestedsnærværende programvare-som-en-tjeneste-modellene (SaaS), som har økt sluttbrukernes forventninger til kontinuerlig forbedring av programvaren og kontinuerlig implementering av funksjoner.

Av en rekke årsaker har fossefallsmodellen vist seg å være utilstrekkelig.

Sammen med beste praksis som smidig metodikk innlemmer moderne DevOps-team CI/CD-prosesser for å levere programvare av høy kvalitet som er grundig testet, med høy hastighet og på en bærekraftig måte.

Gjennom DevOps gir CI/CD en praktisk måte å bygge bro mellom siloene som skiller programmerere, driftsteam og andre deltakere i prosessen for utvikling og levering av programvare.

Prinsippene for CI/CD reduserer risiko og usikkerhet, særlig i komplekse prosjekter som må være smidige nok til å håndtere krav som endres ofte.

Fordelene ved å implementere en CI/CD-prosess

Noen av fordelene med en CI/CD-prosess er åpenbare, for eksempel innebygd automatisering som drastisk reduserer manuelle prosesser som er utsatt for feil. Her er et par andre fordeler med CI/CD-prosesser:

• Å gjøre distribusjonsoperasjoner så friksjonsfrie som mulig. CI/CD-prosesser gir IT-operatører en relativt enkel og brukervennlig prosess som reduserer kompleksiteten ved å bygge og distribuere applikasjoner. Denne forenklede prosessen støttes i stor grad av den innebygde automatiseringsfunksjonaliteten i CI/CD.
• Å forbedre driftshastigheten. Raskere produktiterasjoner er mulig takket være automatisering og raskere tilbakemeldingssløyfer. Automatisering gir DevOps-teknikere umiddelbar informasjon om hvorvidt en bygging er levedyktig.
  
  De mindre CI-integrasjonene og mindre CD-distribusjonene forbedrer DevOps-måltall som gjennomsnittlig tid til løsning (MTTR). MTTR måler den gjennomsnittlige tiden det tar å løse ødelagte funksjoner og feil, inkludert diagnostisering av underliggende problemer. Den samlede CI/CD-prosessen reduserer tiden som kreves for å feilsøke, teste, bygge og distribuere en applikasjon.
• Å øke produktiviteten: Hovedprinsippet for kontinuerlig integrasjon er å oppmuntre utviklere til å slå sammen koden sin med organisasjonens hovedgren ofte. Dette øker sannsynligheten for at alle medlemmer av DevOps-teamet har tilgang til den nyeste fungerende koden.
  
  Dette er avgjørende fordi arbeid med den nyeste iterasjonen av kodebasen beskytter alle mot å basere seg på utdaterte antakelser om prosjektet, dets nåværende funksjoner og kapabiliteter. Dette øker produktiviteten og samarbeidet i programvareprosjekter. Dette forbedrer igjen organisasjonens samlede tid til markedet for produkter.
• Å forkorte lanseringssyklusen, samtidig som man får muligheten til å lansere programvare ved behov. I vår digitale tidsalder trenger selskaper smidighet for å forbli levedyktige ved å reagere raskt på markedsendringer. Teknologikyndige kunder krever i økende grad avanserte funksjoner som personalisering og banebrytende AI-funksjonalitet.
  
  For å holde tritt med endringene hjelper CI/CD-prosesser organisasjoner ikke bare med å øke hastigheten på programvareleveringen for å reagere på markedet, men også med å holde programvareporteføljen i en tilstand der den alltid kan lanseres.
• Å kunne prioritere distribusjon av funksjoner. I tillegg til å legge til rette for raskere drift gjør CI/CD-infrastrukturen det mulig for nettstedsteknikere å fremheve funksjonene som må distribueres umiddelbart eller prioriteres foran andre.
• Å oppdage feil raskere og utbedre problemer hurtigere. Siden kodeendringer integreres oftere, gjør CI det enklere å oppdage og rette feil, mangler og andre inkompatibiliteter langt tidligere i programvareutviklingsprosessen. Dette er spesielt relevant for feilrettinger med høy prioritet for distribusjon, særlig de som løser nulldagssårbarheter.
• Å redusere feil og begrense risiko. CI/CD gir flere lag med sikkerhetstiltak og beskyttelse gjennom hele utviklingslivssyklusen og distribusjonsfasene. Den kumulative effekten av disse feilsikre og feilreduserende mekanismene reduserer risikoeksponeringen programvareutviklingsteam møter når de skal produsere fungerende kode.
  
  Den innebygde automatiseringen og automatiserte testingen i CI/CD-prosessen oppmuntrer til kontinuerlig testing med prosedyrer som enhetstesting, integrasjonstesting, regresjonstesting og så videre. CI/CD-systemer sender også ulike varsler under byggingsfasen som gjør IT-ledere og nettstedsteknikere oppmerksomme på problemer.
• Forbedrer kvalitetskontrollen og minimerer mulighetene for menneskelige feil. Automatisering fjerner behovet for menneskelig inngripen som er utsatt for feil. CI utløser en ny bygging hver gang kodeendringer slås sammen i det sentrale kodearkivet. Dette ledsages vanligvis av enhetstester og integrasjonstester for å sikre at den nye koden er kompatibel med systemet. Denne i stor grad friksjonsfrie prosessen er en beste praksis som tilfører systemet et mål av kvalitetskontroll og kvalitetssikring.
• Å oppmuntre til eksperimentering og innovasjon. DevOps-tankesettets fokus på å introdusere små kodebiter fremmer innovasjon. Hovedsakelig fordi prosessen innebærer langt lavere risikoeksponering, slik at teamene får større frihet til å eksperimentere og innovere. Dette oppmuntrer til oppstartskulturen med å «gå raskt frem og ødelegge ting».
• Å skape pålitelige lanseringer. Som nevnt ovenfor innebærer hyppig distribusjon av små programvarepakker mindre risiko. Det mindre distribusjonsomfanget er også enklere å håndtere, særlig når man skal finne ut om feil har blitt introdusert i systemet. I de fleste tilfeller kan det være så enkelt som å identifisere den nyeste distribusjonen som utløste feilen. 

Avsluttende tanker

CI/CD-pipelines er en viktig funksjon i moderne programvareutvikling og bidrar til å produsere programvareprodukter av høy kvalitet i en programvarebransje i rask utvikling. 

Hvis du vil lære mer om moderne, banebrytende fremskritt i teknologibransjen, abonner på nyhetsbrevet til The QA Lead.