Implementering af et CI/CD-workflow til applikationsudvikling bliver mere og mere populært. Samtidig er det dog en udfordring at skalere og optimere CI/CD.
I dag skal vi diskutere, hvad denne udfordring er og undersøge præcis, hvordan vi kan skalere og optimere CI/CD. Så følg med!
I dag foregår applikationsudvikling normalt i teams bestående af flere udviklere. Hver person eller team har sin rolle i projektet ved at gå videre på deres dedikerede del.
Vi befinder os så i slutningen af projektet med flere stykker kode, der skal kompileres. Afhængigt af alles arbejdsmetoder kan der spildes meget tid på at styre denne integration.
CI/CD, Kontinuerlig Integration og Kontinuerlig Delivery/Deployment er en løsning på dette problem og sikrer, at opdateringer frigives uden unødvendige forsinkelser og konflikter. Lad os forstå denne proces.
Indholdsfortegnelse
Kontinuerlig integration
CI eller Continuous Integration grupperer processer, der sigter mod løbende at udgive kodeændringer og tilføjelser til en delt gren af projektet. Det gør det muligt at teste koden og foretage forbedringer og ændringer i realtid. Målet er at teste hvert element gennem oprettelsen af tests.
Denne permanente foranstaltning gør det muligt ikke at kontrollere alt i én blok til sidst og at undgå at arbejde på for mange elementer samtidigt. Det er derfor meget nyttigt at udføre enhedstests for at sikre dette. Det er således nemmere at opdage fejl ved at sikre, at koden kompilerer godt og ikke skaber regression.
Kontinuerlig levering
Kontinuerlig levering eller CD samler kontinuerlig integration og test, der kan samles i containere og sættes i produktion. Det vil sige, at den samler disse koder og udførte tests og sætter dem i produktion via automatisering.
Selvom det kræver menneskelig handling, bliver det automatiseret ved at sætte alt, hvad der er gjort, “i luften” på en integreret og komplet måde. Helt konkret er vores applikation med den kontinuerlige distribution udviklet, så den kan sættes i produktion, uanset hvornår.
Kontinuerlig implementering
Selvom koncepterne for kontinuerlig levering og kontinuerlig implementering ligner hinanden, er der forskelle. Hvis deres mål er det samme, det vil sige anvendelsen af applikationen i produktionen, er midlerne til at opnå det forskellige. Det, der adskiller kontinuerlig levering fra kontinuerlig implementering, er udgivelsen.
Faktisk gør kontinuerlig implementering det muligt direkte at implementere hver modifikation, der krydser de forskellige stadier af vores pipeline. Under kontinuerlig levering er et menneskeligt valideringstrin nødvendigt, for at implementeringen kan finde sted.
Skalering af CI/CD
Når antallet af mikrotjenester stiger, bliver det næsten uundgåeligt at skalere din CI/CD. Det øgede antal mikrotjenester resulterer i forskellige pipelines forbundet til et enkelt git-lager, hvilket øger belastningen af CI-serveren og sænker ydeevnen.
For at skalere CI/CD er det nødvendigt at skabe en standardiseret og automatiseret udviklingspipeline for alle teams og derfra sikre kvaliteten af individuelle udviklerleverancer og teamleverancer. Det gør også styringen af pipeline let.
Skalering kan opnås ved at definere en CI-proces til udførelse af enhedstest og validering af kvaliteten af den leverede kode.
Efterfulgt af en cd-proces til at opbygge billederne og udrulle dem i miljøerne løbende og til sidst definere en proces til at bygge billederne og udrulle dem i produktionsmiljøet.
Trin til skalering af CI/CD
Det første skridt er at afstemme pipelinen med arkitekterne, hvilket involverer teamledere. Den følger kortlægningen af Git-grenene til miljøerne (develop -> development and master -> [homologation and production]). Det kommer så udløsningen af CI-jobbet ved hver Pull-anmodning og CD-jobbet ved hver ændring i de tilknyttede grene.
Der kan oprettes en jobstream, så både CI og CD kan følges.
CI-jobflowet udvikles i 7 trin:
- Tjek Pull Request-kilden og destinationsgrenen;
- Kontrollerer, om fletningen ikke har konflikter, der kræver manuel løsning;
- Kør enhedstests;
- Byg pakken for at verificere integriteten og at koden er kompilerbar;
- Validering af triggerkodekvalitet;
- Forøg og commit projektversionen til kildegrenen;
- Giv Pull Request Git-lageret besked om succes eller fiasko via Webhook eller Rest API-kald (Git Repository).
CD-jobflowet følger følgende sti:
- Den anmeldte filial er tjekket ud.
- Artefaktet er bygget ved hjælp af det specifikke byggeværktøj for det projekt, der arbejdes på.
- Efter artefakten kommer, sendes biblioteksprojekterne til Nexus til opbevaring af artefakten, og flowet er afsluttet.
Følgende handlinger udføres:
Trin 1: Et Docker-billede oprettes til den genererede artefakt, idet artefaktversionen anvendes på Docker-billedet.
Trin 2: Billedet uploades til Docker-registret.
Trin 3: Implementering via billedudrulning via Kubernetes.
For ansøgningsprojekter, der er i et godkendelses-/produktionsmiljø, skal du følge trin 1 og 2 ovenfor og derefter følgende:
- Implementer gennem billedudrulning via Kubernetes i godkendelsesmiljøet;
- Jobbet tager en pause for at vente på, at udrulningen bliver godkendt til produktion;
- Hvis det er godkendt, promoveres det billede, der godkendes, til produktion;
- Ellers ruller den billedet tilbage i godkendelse.
CI/CD optimering
CI/CD forbedrer applikationsudviklingscyklussen og løser problemet forårsaget af at integrere ny kode og øge leveringsfrekvensen.
Følgende er, hvordan du yderligere kan optimere brugen af CI/CD:
Prioriter reparation af en beskadiget build
Når en build går i stykker, bør det være holdets prioritet at rette den. Hvis bygningen ikke kan rettes på få minutter, skal teamet beslutte, om koden skal fjernes eller funktionsflaget deaktiveres.
Ideen bag at rette en ødelagt build er, at builden altid vil producere fungerende kode, der kan frigives.
Små hyppige udrulninger
Generelt er applikationens stabilitet i fare, når der sker en implementering. Så vi har en tendens til at distancere indsættelser fra hinanden. Denne tilgangs problem er, at vi akkumulerer for mange ændringer. En af disse ændringer kunne gå galt og tvinge os til at rulle de andre tilbage, der virkede.
Anvend kvælermønsteret og bryd komplicerede ændringer til små og enkle. Hvis du installerer hyppigere og arbejder i små partier, er risikoen for implementering lavere.
Automatiser QA-tests til risikoreduktion
Vi har sandsynligvis alle været involveret i scenariet “arbejdet på min lokale maskine”, fordi lokale udviklingsmiljøer ofte er forskellige. Der kan være mange forskellige ting mellem dit lokalmiljø og hvor du går i produktion. Du kan optimere CI/CD ved at automatisere kvalitetssikringsopgaver (QA) såsom browsertest, hvilket mindsker risikoen for, at en fejl når live-applikationen.
Stol på automatiserede tests
For at validere, hvornår en udvikler integrerer ny kode, er CI afhængig af en automatiseret og pålidelig testsuite. Hvis du skal kompilere kode, er den første test, at den kompilerer. Derefter kan du tilføje så mange tests, som du finder kritiske.
Hvor mange tests skal inkluderes? For at fastslå dette skal du huske, at CI’s mål er at give feedback så hurtigt som muligt. Hvis en udvikler skal vente en time på at få feedback, virker det ikke. Du vil altid gå glip af ting, men når du opdager en fejl i produktionen, skal du oprette en testcase og inkludere den i CI-løkken.
Overvej altid sikkerheden
Overvej sikkerheden ved et CI/CD-værktøj, da det integreres i eksisterende konfigurationer eller miljøer. CI/CD kræver, at alle sikkerhedstestværktøjer kaldes programmatisk og deres resultater samles ét sted. Se efter værktøjer, der har API’er til automatiske krypteringsrevisioner.
Fordele ved skalering og optimering af CI/CD
Udover at øge effektiviteten af udviklingsteams har skalering og optimering af CI/CD også andre fordele, hvoraf nogle er:
Reduceret overhead
Udviklingstimer er typisk fakturerbare, men hvad med tid brugt på manuelt at implementere kode eller filer? Automatisering af store dele af dit flow vil spare tid til fakturerbart arbejde, noget alle kan sætte pris på. Automatiseret test giver dig også mulighed for at fejle hurtigere frem for at finde fejl i QA eller produktion eller endnu værre, kunden finder dem. Flere fejl rettet på samme tid er en klar gevinst.
Levering med færre fejl og mindre risiko
Du fanger fejl meget tidligere i udviklingsprocessen ved at frigive mindre ændringer oftere. Når du implementerer automatiserede tests på alle udviklingsstadier, risikerer du ikke at flytte den fejlende kode til næste fase, og det er nemmere at rulle mindre ændringer tilbage, når det er nødvendigt.
Reager hurtigere på markedsforholdene
Markedsforholdene ændrer sig konstant. Antag, at du opdager, at et nyt produkt taber omsætning, eller at flere kunder får adgang til dit websted fra smartphones end bærbare computere. I så fald er det meget nemmere at lave en hurtig ændring, hvis du har optimeret kontinuerlig levering.
Tillid
Hvis du har optimeret CI/CD, hvilket betyder, at du har en robust testsuite, øges din tillid til ikke at indsende en fejl meget. Hvis du er transparent med din proces og uddanner resten af dit team og kunder, øges deres tillid til dig som udviklingsteam også.
Afsluttende ord
CI/CD gør dine integrationer og leveringer hurtigere. Det er dog vigtigt at skalere og optimere den for at undgå, at processen bliver kontraproduktiv på grund af stigende kompleksitet.
Du kan også se på nogle af de bedste CI-værktøjer.