Forstå kontinuerlig integrasjon og kontinuerlig distribusjon

Hørt CI/CD men ikke sikker på hva det er?

Ideelt sett ansettes programvareingeniører for å skrive kode som må sendes til et produksjonsmiljø slik at virksomheten som trenger produktet kan bruke det. For å tilfredsstille virksomheten (ofte kalt brukere/klienter), er det viktig at produktene er feilfrie.

Den typiske tilnærmingen som følges av programvareingeniører er å jobbe i grener og lage en pull-forespørsel som oppdaterer hovedgrenen med den nye oppdateringen som er gjort. Vi har tatt i bruk praksisen med å skrive tester som et middel for å sikre at de nye endringene ikke introduserer feil. Når utviklere jobber med en funksjon i de fleste tilfeller, lager de ofte ikke en pull-forespørsel før de er helt ferdige med funksjonen. Det som skjer når de er klare er at;

• De bruker mye tid på å prøve å bringe kodebasen sin oppdatert med endringene som har skjedd i produksjonsgrenen mens de jobbet.
• Ved å gjøre det, må de fikse en rekke sammenslåingskonflikter.
• Det er også mulighet for at de bryter produksjonsgrenen, noe som fortsetter å påvirke de som trekker fra grenen før problemet er sett og fikset.

Hvis du noen gang har vært i denne situasjonen, er du enig i at det kan være vondt – ingen liker å tilbringe arbeidsdagen på denne måten.

Hva er løsningen?

Kontinuerlig integrering

For å forhindre scenariene jeg sa ovenfor; ingeniørteam kan ta i bruk praksisen som kalles kontinuerlig integrasjon – som navnet antyder, innebærer det kontinuerlig integrasjon av kodeendringer gjort av utviklere i den delte grenen/depotet. Koden som skal integreres må gjennomgå en verifisert test for å sikre at den ikke bryter applikasjonen. Det er først når testen består at den integreres

For å forstå dette, la oss forestille oss et virkelighetsscenario der det er et team på 10 utviklere. Disse utviklerne oppretter en filial lokalt der de skriver kode for implementering av visse funksjoner. I stedet for å sende pull-forespørsler når de er helt ferdige med funksjonen, velger de å sende pull-forespørsler ettersom de gjør små endringer. Et eksempel på en slik endring vil være opprettelsen av en ny modal, forutsatt at utvikleren jobber med en funksjon som lar brukere administrere individuelle oppgaver i applikasjonen. I stedet for å vente til oppgavefunksjonen er fullført, for å følge et kontinuerlig integrasjonsmønster, skyver utvikleren denne lille endringen (i forhold til det hun jobber med) og oppretter en pull-forespørsel om å slå sammen til koden.

Før denne nye endringen integreres, må en serie tester kjøres.

Programvareingeniørteam bruker verktøy som Travis CI å lage disse integrasjonsprosessene og testene. Med verktøy som disse automatiseres testene, slik at de kjøres så snart en pull-forespørsel sendes til målgrenen som er valgt under oppsettet.

Resultatene av testene genereres, og utvikleren som opprettet pull-forespørslene kan se resultatene og gjøre nødvendige endringer. Fordelene ved å holde seg til dette mønsteret med å integrere kode så lite som mulig, og ha en verifisert test å kjøre er;

• Det blir mulig for teamet som er involvert å vite hva som førte til at byggeprosessen eller testen mislyktes. Dette reduserer muligheten for å sende en feil til produksjon.
• Hvis teamet automatiserer prosessen, vil de få tid til å fokusere på å være produktive.

Det som er viktig å merke seg i denne praksisen er at den oppmuntrer teamet til å skyve kode til hovedgrenen ofte. Å gjøre dette vil være ineffektivt hvis andre medlemmer av teamet ikke trekker fra hovedgrenen for å oppdatere deres lokale depot.

Typer tester

I å skrive tester som vil være en del av integrasjonsprosessen, her er noen som kan implementeres i prosessen:

• Integrasjon – den kombinerer individuelle enheter av programvaren og tester dem som en gruppe.
• Enhet – den tester for individuelle enheter eller komponenter i programvaren som metoder eller funksjoner.
• UI – hevder at programvaren fungerer bra fra brukerens perspektiv.
• Aksept – tester at programvaren oppfyller forretningskravene.

Det er viktig å merke seg at du ikke trenger å teste alle disse, siden en håndfull av dem allerede kan være dekket i koden skrevet av utvikleren.

Verktøy for kontinuerlige integrasjoner

Uten å gå i dybden, her er verktøy som du kan begynne å bruke i dine nåværende eller nye prosjekter;

• Travis CI – kjent i åpen kildekode-verden og lover deg å få koden din testet sømløst på få minutter.
• Sirkel CI – gir deg kraft, fleksibilitet og kontroll for å automatisere rørledningen fra kontroll til utplassering.
• Jenkins – gir hundrevis av plugins for å støtte bygging, distribusjon og automatisering av ethvert prosjekt.

Hvis du er ny til Jenkins, vil jeg foreslå å ta dette Udemy kurs å lære CI med Java og .NET.

Kontinuerlig distribusjon

Hva hjelper det hvis funksjonen du bygger sitter i depotet i uker eller måneder før den distribueres til produksjonsmiljøet. Så mye som ingeniørteam kan jobbe for å integrere små endringer i hovedgrenen når det skjer, kan de også presse disse endringene til produksjonsmiljøet så snart som mulig.

Målet når man praktiserer kontinuerlig utrulling er å få endringene gjort ned til brukerne så snart utviklerne integrerer disse endringene i hovedgrenen.

Som ved kontinuerlig integrasjon, ved bruk av kontinuerlig distribusjon, settes det opp automatiserte tester og kontroller for å sikre at de nylig integrerte endringene blir verifisert. Utrullingen skjer bare når disse testene består.

For at et team skal dra nytte av praksisen med kontinuerlig distribusjon, må de ha følgende på plass;

• Automatisert testing er den essensielle ryggraden i all kontinuerlig ingeniørpraksis. Ved kontinuerlig distribusjon, må koden som skal distribueres oppfylle standarden teamet har satt på plass for hva de har til hensikt å sende ut til sluttbrukere. Ideelt sett, hvis en ny endring er under terskelen, bør testen mislykkes og ikke bli integrert. Ellers blir det integrert.
• Til tross for å ha automatiserte tester rygg-til-rygg, er det mulig at noen feil vil skli inn i produksjonsmiljøet. For dette er det nødvendig at teamet er i stand til å angre en endring som er gjort – angre en distribusjon. Dette skal tilbakestille produksjonskoden til det den var før den nye endringen ble gjort.
• Overvåkingssystemer er nødvendig for å holde styr på endringer som har blitt presset til produksjonsmiljøet. Slik kan teamet være i stand til å spore feil som brukere støter på når de bruker de distribuerte endringene.

De nevnte verktøyene for kontinuerlig integrasjon gir deg også funksjonaliteten til å sette opp et kontinuerlig distribusjonssystem. Det er mange av dem du også kan lese deg opp på.

Konklusjon

Produktiviteten til et utviklingsteam er avgjørende for suksessen til virksomheten. For å sikre at de er produktive, må praksis som oppmuntrer til dette vedtas. Kontinuerlig integrasjon og distribusjon er eksempler på slik praksis.

Med kontinuerlig integrasjon kan team presse så mye kode som mulig daglig. Når dette er oppnådd, blir det enkelt å distribuere de nylig lagt til endringene til brukeren så snart som mulig. Implementering av disse endringene gjør det mulig å få tilbakemelding fra brukerne. Til slutt vil virksomheten være i stand til å innovere basert på tilbakemeldingene som er mottatt, noe som er en vinn-vinn for alle.

Du kan også lære hvordan du skalerer opp og optimaliserer CI/CD.

Hvis du er en utvikler og interessert i å lære CI/CD, så sjekk ut denne strålende kurs.

Likte du å lese artikkelen? Hva med å dele med verden?