Har du hørt om CI/CD, men er usikker på hva det innebærer?
Programvareutviklere ansettes ideelt sett for å skrive kode som skal implementeres i et produksjonsmiljø, slik at virksomheten som trenger produktet kan ta det i bruk. For å tilfredsstille virksomheten (ofte kalt brukere eller klienter), er det avgjørende at produktene er feilfrie.
Den typiske fremgangsmåten som følges av programvareutviklere er å arbeide i separate grener og deretter opprette en pull-forespørsel for å oppdatere hovedgrenen med de nye endringene. Det er vanlig praksis å skrive tester for å forsikre seg om at de nye endringene ikke introduserer feil. Når utviklere jobber med en funksjon, venter de i mange tilfeller med å lage en pull-forespørsel til de er helt ferdige med funksjonen. Når de er klare, skjer det ofte følgende:
- De bruker mye tid på å oppdatere sin egen kodebase med endringene som har skjedd i produksjonsgrenen mens de jobbet.
- Som et resultat av dette, må de løse en rekke sammenslåingskonflikter.
- Det er også risiko for at de ødelegger produksjonsgrenen, noe som kan påvirke andre utviklere som laster ned fra grenen før problemet oppdages og rettes.
Hvis du har opplevd dette, er du sikkert enig i at det kan være frustrerende – ingen liker å bruke arbeidsdagen på denne måten.
Hva er løsningen på dette?
Kontinuerlig Integrasjon
For å unngå de scenarioene jeg nevnte ovenfor, kan utviklingsteam innføre praksisen med kontinuerlig integrasjon. Som navnet antyder, innebærer det å kontinuerlig integrere kodeendringer fra utviklere i den delte grenen/repoet. Koden som skal integreres, må gjennomgå en verifisert test for å sikre at den ikke ødelegger applikasjonen. Først når testen er bestått, integreres koden.
For å illustrere dette, la oss se for oss et team på 10 utviklere. Disse utviklerne oppretter lokale grener der de skriver kode for å implementere spesifikke funksjoner. I stedet for å sende pull-forespørsler når de er helt ferdige med en funksjon, velger de å sende pull-forespørsler etter hvert som de gjør små endringer. Et eksempel på en slik endring kan være opprettelsen av en ny modal, forutsatt at utvikleren arbeider med en funksjon som lar brukere administrere individuelle oppgaver i applikasjonen. I stedet for å vente til oppgavefunksjonen er fullført, sender utvikleren denne mindre endringen (i forhold til det hun jobber med) og oppretter en pull-forespørsel for å slå den sammen med koden.
Før denne nye endringen integreres, må en rekke tester utføres.
Programvareutviklingsteam benytter verktøy som Travis CI for å automatisere disse integrasjonsprosessene og testene. Med slike verktøy automatiseres testene, slik at de kjøres så snart en pull-forespørsel sendes til den valgte målgrenen.
Resultatene av testene genereres, og utvikleren som opprettet pull-forespørselen kan se resultatene og gjøre nødvendige endringer. Fordelene ved å holde seg til denne fremgangsmåten med å integrere kode ofte og ha en verifisert test å kjøre er:
- Teamet kan lettere identifisere hva som forårsaket at byggingen eller testen mislyktes. Dette reduserer risikoen for å sende en feil til produksjon.
- Hvis teamet automatiserer prosessen, får de mer tid til å fokusere på produktivitet.
Det er viktig å merke seg at denne praksisen oppfordrer teamet til å pushe kode til hovedgrenen ofte. For at dette skal være effektivt, må de andre medlemmene av teamet også laste ned fra hovedgrenen for å oppdatere sine lokale repoer.
Typer Tester
Når du skriver tester som skal være en del av integrasjonsprosessen, er det flere typer du kan implementere:
- Integrasjonstester – kombinerer individuelle enheter av programvaren og tester dem som en gruppe.
- Enhetstester – tester individuelle enheter eller komponenter i programvaren, for eksempel metoder eller funksjoner.
- UI-tester – verifiserer at programvaren fungerer bra fra brukerens perspektiv.
- Aksepttester – kontrollerer at programvaren oppfyller forretningskravene.
Det er viktig å huske at du ikke trenger å teste alle disse, siden noen av dem kan være dekket av koden utvikleren allerede har skrevet.
Verktøy for Kontinuerlig Integrasjon
Her er noen verktøy du kan bruke i dine nåværende eller nye prosjekter, uten å gå for mye i detalj:
- Travis CI – er populært i åpen kildekode-verden og lar deg teste koden din raskt og enkelt på få minutter.
- Circle CI – gir deg kraft, fleksibilitet og kontroll for å automatisere rørledningen fra kildekode til produksjon.
- Jenkins – tilbyr hundrevis av plugins for å støtte bygging, distribusjon og automatisering av alle typer prosjekter.
Hvis du er ny til Jenkins, vil jeg anbefale dette Udemy-kurset for å lære CI med Java og .NET.
Kontinuerlig Distribusjon
Hvilken nytte har det hvis funksjonen du utvikler blir liggende i repoet i uker eller måneder før den blir distribuert til produksjonsmiljøet? Like viktig som det er for utviklingsteam å integrere små endringer i hovedgrenen fortløpende, er det også viktig å pushe disse endringene til produksjonsmiljøet så raskt som mulig.
Målet med kontinuerlig distribusjon er å få endringene ut til brukerne så snart utviklerne har integrert dem i hovedgrenen.
På samme måte som med kontinuerlig integrasjon, etableres det automatiserte tester og kontroller ved bruk av kontinuerlig distribusjon for å sikre at de nylig integrerte endringene er verifisert. Utrullingen skjer først når testene er bestått.
For at et team skal kunne dra nytte av kontinuerlig distribusjon, må de ha følgende på plass:
- Automatisert testing er selve kjernen i all kontinuerlig ingeniørpraksis. Ved kontinuerlig distribusjon må koden som skal distribueres, oppfylle den standarden teamet har satt for hva de ønsker å sende ut til sluttbrukerne. Hvis en ny endring faller under terskelen, bør testen mislykkes og endringen ikke integreres. Hvis endringen er innenfor kravene, integreres den.
- Selv om man har automatiserte tester, er det en mulighet for at enkelte feil sniker seg inn i produksjonsmiljøet. Derfor er det nødvendig at teamet har muligheten til å angre en endring som er gjort – å angre en distribusjon. Dette skal tilbakestille produksjonskoden til slik den var før den nye endringen ble gjort.
- Overvåkingssystemer er nødvendige for å holde oversikt over endringer som har blitt pushet til produksjonsmiljøet. På denne måten kan teamet spore feil som brukere opplever når de bruker de distribuerte endringene.
De verktøyene som er nevnt for kontinuerlig integrasjon, gir deg også funksjonalitet for å sette opp et kontinuerlig distribusjonssystem. Det finnes mange flere verktøy som du også kan utforske.
Konklusjon
Produktiviteten til et utviklingsteam er avgjørende for virksomhetens suksess. For å sikre at de er produktive, må praksiser som oppmuntrer til dette tas i bruk. Kontinuerlig integrasjon og distribusjon er eksempler på slike praksiser.
Med kontinuerlig integrasjon kan teamet pushe mye kode daglig. Når dette er oppnådd, blir det enklere å distribuere de nylig tilføyde endringene til brukeren så raskt som mulig. Implementering av disse endringene gir mulighet for å få tilbakemelding fra brukerne. Til syvende og sist vil virksomheten kunne innovere basert på tilbakemeldingene som mottas, noe som er en vinn-vinn situasjon for alle.
Du kan også lære hvordan du kan skalere opp og optimalisere CI/CD.
Hvis du er en utvikler og er interessert i å lære CI/CD, bør du sjekke ut dette flotte kurset.
Likte du å lese artikkelen? Hva med å dele den med andre?