Kontinuerlig leveringsveiledning - Bygg en kontinuerlig leveringsrørledning ved hjelp av Jenkins

Kontinuerlig levering:

Kontinuerlig levering er en prosess der kodeendringer blir automatisk bygget, testet og klargjort for utgivelse til produksjon.Jeg håper du har hatt glede av det Her vil jeg snakke om følgende emner:

• Hva er kontinuerlig levering?
• Typer programvaretesting
• Forskjellen mellom kontinuerlig integrasjon, levering og distribusjon
• Hva er behovet for kontinuerlig levering?
• Praktisk bruk av Jenkins og Tomcat

La oss raskt forstå hvordan kontinuerlig levering fungerer.

Hva er kontinuerlig levering?

Det er en prosess hvor du bygger programvare på en slik måte at den når som helst kan slippes ut til produksjon.Tenk på diagrammet nedenfor:

La meg forklare diagrammet ovenfor:

• Automatiserte byggeskripter vil oppdage endringer i Source Code Management (SCM) som Git.
• Når endringen er oppdaget, vil kildekoden distribueres til en dedikert build-server for å sikre at build ikke mislykkes, og at alle testklasser og integrasjonstester går bra.
• Deretter distribueres build-applikasjonen på testserverne (pre-production servers) for User Acceptance Test (UAT).
• Til slutt distribueres applikasjonen manuelt på produksjonsserverne for utgivelse.

Før jeg fortsetter, vil det bare være rettferdig. Jeg forklarer deg de forskjellige typene testing.

Typer programvaretesting:

Generelt sett er det to typer testing:

• Blackbox-testing: Det er en testteknikk som ignorerer systemets interne mekanisme og fokuserer på produksjonen som genereres mot alle innganger og utførelser av systemet. Det kalles også funksjonstesting. Den brukes i utgangspunktet for å validere programvaren.
• Whitebox Testing: er en testteknikk som tar hensyn til den interne mekanismen i et system. Det kalles også strukturell testing og glassbokstesting. Den brukes i utgangspunktet for å verifisere programvaren.

Whitebox testing:

Det er to typer testing som faller inn under denne kategorien.

• Enhetstesting: Det er testing av en individuell enhet eller gruppe av relaterte enheter. Det gjøres ofte av programmereren for å teste at enheten han / hun har implementert produserer forventet produksjon mot gitt input.
• Integrasjonstesting: Det er en type testing der en gruppe komponenter erkombinert for å produsere produksjonen. Samspillet mellom programvare og maskinvare blir også testet hvis programvare og maskinvarekomponenter har noen sammenheng. Det kan falle inn både under testing av hvit boks og svart boks.

Blackbox-testing:

Det er flere tester som faller inn under denne kategorien. Jeg vil fokusere påNoen, som er viktig for deg å vite, for å forstå denne bloggen:

• Funksjonell / aksepttesting: Det sikrer at den spesifiserte funksjonaliteten som kreves i systemkravene fungerer. Det gjøres for å sikre at det leverte produktet oppfyller kravene og fungerer som kunden forventet
• Systemtesting: Det sørger for at det fortsatt fungerer ved å plassere programvaren i forskjellige miljøer (f.eks. Operativsystemer).
• Stress Testing: Den evaluerer hvordan systemet oppfører seg under ugunstige forhold.
• Betatesting: Det gjøres av sluttbrukere, et team utenfor utviklingen, eller offentliggir full forhåndsversjon av produktet som er kjent sombetaversjon. Målet med betatesting er å dekke uventede feil.

Nå er det riktig tidspunkt for meg å forklare forskjellen mellom kontinuerlig integrasjon, levering og distribusjon.

Forskjeller mellom kontinuerlig integrasjon, levering og implementering:

Visuelt innhold når en persons hjerne på en raskere og mer forståelig måte enn tekstinformasjon. Så jeg skal begynne med et diagram som tydelig forklarer forskjellen:

I kontinuerlig integrasjon bygges og testes alle kodeforpliktelser, men er ikke i en tilstand som skal frigjøres. Jeg mener byggeapplikasjonen ikke distribueres automatisk på testserverne for å validere den ved hjelp av forskjellige typer Blackbox-tester som UAT (User Acceptance Testing).

I kontinuerlig levering distribueres applikasjonen kontinuerlig på testserverne for UAT. Eller du kan si at applikasjonen er klar til å bli utgitt til produksjon når som helst. Så det er åpenbart kontinuerlig integrering nødvendig for kontinuerlig levering.

Kontinuerlig distribusjon er neste trinn etter kontinuerlig levering, hvor du ikke bare lager en distribuerbar pakke, men du faktisk distribuerer den på en automatisert måte.

La meg oppsummere forskjellene ved hjelp av en tabell:

Enkelt sagt er kontinuerlig integrasjon en del av både kontinuerlig levering og kontinuerlig implementering. Og kontinuerlig distribusjon er som kontinuerlig levering, bortsett fra at utgivelser skjer automatisk.

Lær hvordan du lager CI / CD-rørledninger ved hjelp av Jenkins On Cloud

Men spørsmålet er om kontinuerlig integrering er nok.

Hvorfor trenger vi kontinuerlig levering?

La oss forstå dette med et eksempel.

Tenk deg at det er 80 utviklere som jobber med et stort prosjekt. De bruker kontinuerlige integrasjonsrørledninger for å lette automatiserte bygg. Vi vet at build også inkluderer enhetstesting. En dag bestemte de seg for å distribuere den nyeste versjonen som hadde bestått enhetstestene i et testmiljø.

Dette må være en langvarig, men kontrollert tilnærming til distribusjon som deres miljøspesialister utførte. Imidlertid virket det ikke som om systemet fungerte.

Hva kan være den åpenbare årsaken til feilen?

Vel, den første grunnen til at folk flest vil tro er at det er noe problem med konfigurasjonen. Som de fleste trodde de selv det.De brukte mye tid på å prøve å finne ut hva som var galt med konfigurasjonen av miljøet, men de fant ikke problemet.

En oppmerksom utvikler tok en smart tilnærming:

Da prøvde en av seniorutviklerne applikasjonen på utviklingsmaskinen sin. Det fungerte ikke der heller.

Han gikk tilbake gjennom tidligere og tidligere versjoner til han fant ut at systemet hadde sluttet å fungere tre uker tidligere. En liten, obskur feil hadde forhindret systemet i å starte riktig. Selv om prosjektet hadde god enhetstestdekning.Til tross for dette så ikke 80 utviklere, som vanligvis bare kjørte testene i stedet for selve applikasjonen, problemet på tre uker.

Problemstilling:

Uten å kjøre Acceptance Tests i et produksjonslignende miljø, vet de ingenting om applikasjonen oppfyller kundens spesifikasjoner, og heller ikke om den kan distribueres og overleve i den virkelige verden. Hvis de ønsker tilbakemelding på disse emnene i tide, må de utvide omfanget av deres kontinuerlige integrasjonsprosess.

La meg oppsummere leksjonene ved å se på problemene ovenfor:

• Enhetstester tester bare utviklerens perspektiv på løsningen på et problem. De har bare en begrenset evne til å bevise at applikasjonen gjør det den skal fra et brukerperspektiv. De er ikke nok tilidentifisere de virkelige funksjonelle problemene.
• Å distribuere applikasjonen på testmiljøet er en kompleks, manuelt intensiv prosess som var ganske utsatt for feil.Dette betydde at hvert forsøk på distribusjon var et nytt eksperiment - en manuell, feilutsatt prosess.

Løsning - Kontinuerlig leveringsrørledning (Automated Acceptance Test):

De tok kontinuerlig integrasjon (kontinuerlig levering) til neste trinn og introduserte et par enkle, automatiserte godkjenningstester som beviste at applikasjonen kjørte og kunne utføre sin mest grunnleggende funksjon.Flertallet av testene som kjøres i løpet av Acceptance Test-fasen, er Functional Acceptance Tests.

I utgangspunktet bygde de en kontinuerlig leveringsrørledning for å sikre at applikasjonen sømløst distribueres på produksjonsmiljøet, ved å sørge for at applikasjonen fungerer bra når den distribueres på testserveren, som er en kopi av produksjonsserveren.

Nok av teorien, jeg vil nå vise deg hvordan du lager en rørledning for kontinuerlig levering ved hjelp av Jenkins.

Kontinuerlig leveringsrørledning ved bruk av Jenkins:

Her skal jeg bruke Jenkins til å lage en kontinuerlig leveringsrørledning, som vil omfatte følgende oppgaver:

Fremgangsmåten involvert i demonstrasjonen:

• Henter koden fra GitHub
• Kompilering av kildekoden
• Enhetstesting og generering av JUnit-testrapportene
• Pakke applikasjonen i en WAR-fil og distribuere den på Tomcat-serveren

Forutsetninger:

• CentOS 7-maskin
• Jenkins 2.121.1
• Docker
• Tomcat 7

Trinn - 1 Sammensetning av kildekoden:

La oss begynne med å først lage et Freestyle-prosjekt i Jenkins. Tenk på skjermbildet nedenfor:

Gi et navn til prosjektet ditt og velg Freestyle Project:

Når du ruller ned, vil du finne et alternativ for å legge til kildekodedepoter, velg git og legg til depot-URL, i det depotet er det en pom.xml-bot som vi vil bruke til å bygge prosjektet vårt. Tenk på skjermbildet nedenfor:

Nå skal vi legge til en Build Trigger. Velg SCM-alternativet, i utgangspunktet vil vi konfigurere Jenkins til å avstemme GitHub-depotet etter hvert 5. minutt for endringer i koden. Tenk på skjermbildet nedenfor:

Før jeg fortsetter, la meg gi deg en liten introduksjon til Maven Build Cycle.

Hver av byggesyklusene er definert av en annen liste over byggefaser, hvor en byggefase representerer et trinn i livssyklusen.

Følgende er listen over byggefaser:

• validere - validere prosjektet er riktig og all nødvendig informasjon er tilgjengelig
• kompilere - kompiler kildekoden til prosjektet
• test - test den kompilerte kildekoden ved hjelp av et passende rammeverk for enhetstesting. Disse testene skal ikke kreve at koden pakkes eller distribueres
• pakke - ta den kompilerte koden og pakke den i distribuerbart format, for eksempel en JAR.
• verifisere - kjør alle kontroller av resultatene av integrasjonstester for å sikre at kvalitetskriteriene blir oppfylt
• install - installer pakken i det lokale depotet, for bruk som en avhengighet i andre prosjekter lokalt
• distribuere - gjort i bygningsmiljøet, kopierer den endelige pakken til det eksterne depotet for deling med andre utviklere og prosjekter.

Jeg kan kjøre kommandoen nedenfor for å kompilere kildekoden, teste enheten og til og med pakke applikasjonen i en krigsfil:

mvn ren pakke

Du kan også dele opp byggejobben din i en rekke byggetrinn. Dette gjør det lettere å organisere bygg i rene, separate stadier.

Så vi begynner med å kompilere kildekoden. I build-fanen klikker du på påkalle toppnivå maven mål og skriver kommandoen nedenfor:

kompilere

Tenk på skjermbildet nedenfor:

Dette vil trekke kildekoden fra GitHub-depotet og vil også kompilere den (Maven Compile Phase).

Klikk på Lagre og kjør prosjektet.

lese og skrive excel-fil i java

Klikk nå på konsollutgangen for å se resultatet.

Trinn - 2 Enhetstesting:

Nå skal vi lage et Freestyle-prosjekt til for enhetstesting.

Legg til samme lagrings-URL i kildekodeadministrasjonsfanen, som vi gjorde i forrige jobb.

Nå, i kategorien 'Buid Trigger', klikk på 'build etter at andre prosjekter er bygget'. Der skriver du inn navnet på forrige prosjekt der vi kompilerer kildekoden, og du kan velge et av alternativene nedenfor:

• Utløs bare hvis bygningen er stabil
• Utløs selv om bygningen er ustabil
• Utløs selv om bygningen mislykkes

Jeg synes alternativene ovenfor er ganske selvforklarende, så velg hvilken som helst. Tenk på skjermbildet nedenfor:

I kategorien Bygg klikker du på påkalle toppnivå maven mål og bruker kommandoen nedenfor:

test

Jenkins gjør også en god jobb med å hjelpe deg med å vise testresultater og testresultattrender.

De facto-standarden for testrapportering i Java-verdenen er et XML-format som brukes av JUnit. Dette formatet brukes også av mange andre Java-testverktøy, som TestNG, Spock og Easyb. Jenkins forstår dette formatet, så hvis din build gir JUnit XML-testresultater, kan Jenkins generere fine grafiske testrapporter og statistikk over testresultater over tid, og også la deg se detaljene i eventuelle testfeil. Jenkins holder også oversikt over hvor lang tid det tar å teste, både globalt og per test - dette kan være nyttig hvis du trenger å spore ytelsesproblemer.

Så det neste vi må gjøre er å få Jenkins til å holde oversikt over enhetstestene våre.

Gå til delen etter bygghandlinger og merk av for 'Publiser JUnit-testresultatrapport'. Når Maven kjører enhetstester i et prosjekt, genererer den automatisk XML-testrapportene i en katalog kalt surefire-rapporten. Så skriv inn “** / target / surefire-reports / *. Xml” i feltet “Test report XMLs”. De to stjernene ved starten av stien (“**”) er en god praksis for å gjøre konfigurasjonen litt mer robust: de lar Jenkins finne målkatalogen uansett hvordan vi har konfigurert Jenkins til å sjekke kildekoden.

** / mål / surefire-rapporter / *. xml

Lagre den igjen og klikk på Bygg nå.

Nå er JUnit-rapporten skrevet til / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

I Jenkins-dashbordetdu kan også legge merke til testresultatene:

Trinn 3 Opprette en WAR-fil og distribuere på Tomcat-serveren:

Nå er det neste trinnet å pakke applikasjonen vår i en WAR-fil og distribuere den på Tomcat-serveren for brukertest.

hvordan du implementerer koblet liste i c

Lag et annet freestyle-prosjekt og legg til kildekoden til lagringsadressen.

Velg deretter bygge når andre prosjekter er bygget i kategorien byggeutløsere, vurder skjermbildet nedenfor:

I utgangspunktet, etter testjobben, vil distribusjonsfasen starte automatisk.

I skallfanen velger du skallskript. Skriv inn kommandoen nedenfor for å pakke applikasjonen i en WAR-fil:

mvn-pakke

Neste trinn er å distribuere denne WAR-filen til Tomcatserver. I 'Post-Build Actions' -fanen velger du distribuere krig / øre til en container. Her, gi stien til krigsfilen og gi kontekststien. Tenk på skjermbildet nedenfor:

Velg Tomcat-legitimasjonen, og legg merke til skjermbildet ovenfor. Du må også oppgi URL-adressen til Tomcat-serveren din.

For å legge til legitimasjon i Jenkins, klikk på påloggingsalternativet på Jenkins-dashbordet.

Klikk på System og velg global legitimasjon.

Da finner du et alternativ for å legge til legitimasjonen. Klikk på den og legg til legitimasjon.

Legg til Tomcat-legitimasjonen, vurder skjermbildet nedenfor.

Klikk på OK.

Nå, i prosjektkonfigurasjonen, legger du til tomcat-legitimasjonen du har satt inn i forrige trinn.

Klikk på Lagre og velg deretter Bygg nå.

Gå til tomcat-URL-en din, med kontekststien, i mitt tilfelle er det http: // localhost: 8081. Legg til kontekststien til slutt, vurder skjermbildet nedenfor:

Link - http: // localhost: 8081 / gof

Jeg håper du har forstått betydningen av kontekstveien.

Lag nå en rørledningsvisning, vurder skjermbildet nedenfor:

Klikk på pluss-ikonet for å opprette en ny visning.

Konfigurer rørledningen slik du vil, vurder skjermbildet nedenfor:

Jeg endret ikke noe annet enn å velge den første jobben. Så rørledningen min starter fra kompilering. Basert på måten jeg har konfigurert andre jobber på, etter at kompileringstesting og distribusjon vil skje.

Til slutt kan du teste rørledningen ved å klikke RUN. Etter hvert femte minutt, hvis det er en endring i kildekoden, vil hele rørledningen bli utført.

Så vi er i stand til kontinuerlig å distribuere applikasjonen vår på testserveren for brukertest (UAT).

Jeg håper du har likt å lese dette innlegget om kontinuerlig levering. Hvis du er i tvil, kan du gjerne sette dem i kommentarfeltet nedenfor, så kommer jeg tilbake med et svar tidligst.

For å bygge CI / CD-rørledninger må du beherske mange forskjellige ferdigheter Mestre de nødvendige DevOps-ferdighetene nå