Implementering av en CI/CD-arbeidsflyt for applikasjonsutvikling blir stadig mer populært. Samtidig er det en utfordring å skalere og optimalisere CI/CD.
I dag skal vi diskutere hva denne utfordringen er og utforske nøyaktig hvordan vi kan skalere og optimalisere CI/CD. Så følg med!
I dag gjøres applikasjonsutvikling vanligvis i team bestående av flere utviklere. Hver person eller team har sin rolle i prosjektet ved å avansere på sin dedikerte del.
Vi befinner oss så på slutten av prosjektet med flere stykker kode å kompilere. Avhengig av alles arbeidsmetoder, kan mye tid kastes bort på å administrere denne integrasjonen.
CI/CD, kontinuerlig integrasjon og kontinuerlig levering/distribusjon er en løsning på dette problemet og sikrer at oppdateringer utgis uten unødvendige forsinkelser og konflikter. La oss forstå denne prosessen.
Innholdsfortegnelse
Kontinuerlig integrering
CI eller Continuous Integration grupperer prosesser rettet mot kontinuerlig publisering av kodeendringer og tillegg til en delt gren av prosjektet. Den lar koden testes og forbedringer og endringer gjøres i sanntid. Målet er å teste hvert element gjennom å lage tester.
Dette permanente tiltaket gjør det mulig å ikke sjekke alt i én blokk på slutten og unngå å jobbe med for mange elementer samtidig. Å utføre enhetstester er derfor svært nyttig for å sikre dette. Dermed er det lettere å oppdage feil ved å sørge for at koden kompileres godt og ikke skaper regresjoner.
Kontinuerlig levering
Kontinuerlig levering eller CD samler kontinuerlig integrasjon og testing som kan pakkes inn i beholdere og settes i produksjon. Det vil si at den samler disse kodene og utførte tester og setter dem i produksjon via automatisering.
Selv om det krever menneskelig handling, blir det automatisert ved å sette alt som er gjort «på lufta» på en integrert og fullstendig måte. Konkret, med den kontinuerlige distribusjonen er vår applikasjon utviklet slik at den kan settes i produksjon, uansett når.
Kontinuerlig distribusjon
Mens konseptene kontinuerlig levering og kontinuerlig distribusjon er like, er det forskjeller. Hvis målet deres er det samme, det vil si distribusjon av applikasjonen i produksjon, er midler for å oppnå det forskjellige. Det som skiller kontinuerlig levering fra kontinuerlig distribusjon er utgivelsen.
Faktisk gjør kontinuerlig distribusjon det mulig å distribuere hver modifikasjon som krysser de forskjellige stadiene av rørledningen vår direkte. Mens det er i kontinuerlig levering, er et menneskelig valideringstrinn nødvendig for at distribusjonen skal finne sted.
Skalering av CI/CD
Når antallet mikrotjenester øker, blir det nesten uunngåelig å skalere CI/CD-en din. Det økte antallet mikrotjenester resulterer i forskjellige rørledninger koblet til et enkelt git-lager som øker belastningen på CI-serveren og senker ytelsen.
For å skalere CI/CD er det nødvendig å lage en standardisert og automatisert utviklingspipeline for alle team og derfra sikre kvaliteten på individuelle utviklerleveranser og teamleveranser. Det gjør også administrasjonen av rørledningen enkel.
Skalering kan oppnås ved å definere en CI-prosess for å utføre enhetstester og validere kvaliteten på den leverte koden.
Etterfulgt av en CD-prosess for å bygge bildene og distribuere dem i miljøene kontinuerlig og til slutt definere en prosess for å bygge bildene og distribuere dem i produksjonsmiljøet.
Trinn for å skalere CI/CD
Det første trinnet er å samkjøre rørledningen med arkitektene, og involvere teamledere. Den følger kartleggingen av Git-grenene til miljøene (develop -> development and master -> [homologation and production]). Det kommer så utløsningen av CI-jobben ved hver Pull-forespørsel og CD-jobben ved hver endring i de kartlagte grenene.
En jobbstrøm kan opprettes for både CI og CD som kan følges.
CI Job Flow utvikler seg i 7 trinn:
- Sjekk ut Pull Request-kilden og destinasjonsgrenen;
- Sjekker om sammenslåingen ikke har konflikter som trenger manuell løsning;
- Kjør enhetstester;
- Bygg pakken for å bekrefte integriteten og at koden er kompilerbar;
- Utløserkodekvalitetsvalidering;
- Øk og overfør prosjektversjonen til kildegrenen;
- Varsle Pull Request Git-lageret om suksess eller fiasko via Webhook eller Rest API-kall (Git Repository).
CD-jobbflyten følger følgende bane:
- Den varslede filialen er sjekket ut.
- Artefakten bygges ved å bruke det spesifikke byggeverktøyet til prosjektet det jobbes med.
- Etter at artefakten kommer, sendes bibliotekprosjektene til Nexus for lagring av artefakten, og flyten er ferdig.
Følgende handlinger utføres:
Trinn 1: Et Docker-bilde opprettes for den genererte artefakten, og bruker artefaktversjonen på Docker-bildet.
Trinn 2: Bildet lastes opp til Docker-registeret.
Trinn 3: Implementering gjennom bildeutrulling via Kubernetes.
For søknadsprosjekter som er i et godkjennings-/produksjonsmiljø, følg trinn 1 og 2 ovenfor og deretter følgende:
- Distribuer gjennom bildeutrulling via Kubernetes i godkjenningsmiljøet;
- Jobben tar en pause for å vente på at utrullingen skal godkjennes for produksjon;
- Hvis det er godkjent, promoteres bildet som godkjennes for produksjon;
- Ellers ruller den tilbake bildet i godkjenning.
CI/CD-optimalisering
CI/CD forbedrer applikasjonsutviklingssyklusen og løser problemet forårsaket av å integrere ny kode og øke leveringsfrekvensen.
Følgende er hvordan du kan optimalisere bruken av CI/CD ytterligere:
Prioriter å fikse en ødelagt versjon
Når en build går i stykker, bør det være lagets prioritet å fikse det. Hvis bygningen ikke kan fikses på minutter, må teamet bestemme om koden skal fjernes eller funksjonsflagget deaktiveres.
Ideen bak å fikse et ødelagt bygg er at bygget alltid vil produsere fungerende kode som kan frigis.
Små hyppige utplasseringer
Generelt sett er applikasjonens stabilitet i fare hver gang en distribusjon skjer. Så vi har en tendens til å distansere utplasseringer fra hverandre. Problemet med denne tilnærmingen er at vi akkumulerer for mange endringer. En av disse endringene kan gå galt, og tvinge oss til å rulle tilbake de andre som fungerte.
Bruk kvelermønsteret og del kompliserte endringer i små og enkle. Hvis du distribuerer oftere og jobber i små grupper, er risikoen for utplassering lavere.
Automatiser QA-tester for risikoreduksjon
Vi har sannsynligvis alle vært involvert i scenariet «jobbet på min lokale maskin» fordi lokale utviklingsmiljøer ofte er forskjellige. Det kan være mange forskjellige ting mellom ditt nærmiljø og hvor du går i produksjon. Du kan optimalisere CI/CD ved å automatisere kvalitetssikringsoppgaver (QA) som nettlesertesting, og redusere risikoen for at en feil når den aktive applikasjonen.
Stol på automatiserte tester
For å validere når en utvikler integrerer ny kode, er CI avhengig av en automatisert og pålitelig testpakke. Hvis du trenger å kompilere kode, er den første testen at den kompilerer. Deretter kan du legge til så mange tester du anser som kritiske.
Hvor mange tester skal inkluderes? For å fastslå dette, husk at CIs mål er å gi tilbakemelding så raskt som mulig. Hvis en utvikler må vente en time for å få tilbakemelding, vil det ikke fungere. Du vil alltid gå glipp av ting, men når du oppdager en feil i produksjonen, lag en testcase og ta den med i CI-løkken.
Vurder alltid sikkerheten
Vurder sikkerheten til et CI/CD-verktøy ettersom det integreres i eksisterende konfigurasjoner eller miljøer. CI/CD krever at alle sikkerhetstestverktøy kalles programmatisk og resultatene deres samles på ett sted. Se etter verktøy som har APIer for automatiserte krypteringsrevisjoner.
Fordeler med skalering og optimalisering av CI/CD
Bortsett fra å øke effektiviteten til utviklingsteam, har skalering og optimalisering av CI/CD også andre fordeler, hvorav noen er:
Redusert overhead
Utviklingstimer er vanligvis fakturerbare, men hva med tid brukt på manuelt distribusjon av kode eller filer? Å automatisere store deler av flyten din vil spare tid for fakturerbart arbeid, noe alle kan sette pris på. Automatisert testing lar deg også mislykkes tidligere i stedet for å finne feil i QA eller produksjon eller enda verre, kunden finner dem. Flere feil fikset på samme tid er en klar seier.
Levering med færre feil og mindre risiko
Du fanger feil mye tidligere i utviklingsprosessen ved å utgi mindre endringer oftere. Når du implementerer automatiserte tester i alle utviklingsstadier, risikerer du ikke å flytte den feilende koden til neste trinn, og det er lettere å rulle tilbake mindre endringer når det er nødvendig.
Reager på markedsforhold raskere
Markedsforholdene endres hele tiden. Anta at du oppdager at et nytt produkt taper inntekter eller at flere kunder får tilgang til nettstedet ditt fra smarttelefoner enn bærbare datamaskiner. I så fall er det mye lettere å gjøre en rask endring hvis du har optimalisert kontinuerlig levering.
Selvtillit
Hvis du har optimalisert CI/CD, som betyr at du har en robust testpakke, øker tilliten din til å ikke sende inn en feil betraktelig. Hvis du er transparent med prosessen din og utdanner resten av teamet ditt og kundene, øker deres tillit til deg som utviklingsteam også.
Siste ord
CI/CD gjør integrasjonene og leveransene dine raskere. Det er imidlertid viktig å skalere og optimalisere den for å unngå at prosessen blir kontraproduktiv på grunn av økende kompleksitet.
Du kan også se på noen av de beste CI-verktøyene.