Kontinuerlig leveringsvejledning - Opbygning af en kontinuerlig leveringsrørledning ved hjælp af Jenkins

Kontinuerlig levering:

Kontinuerlig levering er en proces, hvor kodeændringer automatisk bygges, testes og klargøres til frigivelse til produktion.Jeg håber, du har nydt min Her vil jeg tale om følgende emner:

• Hvad er kontinuerlig levering?
• Typer af softwaretest
• Forskellen mellem kontinuerlig integration, levering og implementering
• Hvad er behovet for kontinuerlig levering?
• Praktisk brug af Jenkins og Tomcat

Lad os hurtigt forstå, hvordan kontinuerlig levering fungerer.

Hvad er kontinuerlig levering?

Det er en proces, hvor du bygger software på en sådan måde, at den til enhver tid kan frigives til produktion.Overvej nedenstående diagram:

Lad mig forklare ovenstående diagram:

• Automatiske build-scripts registrerer ændringer i Source Code Management (SCM) som Git.
• Når ændringen er opdaget, vil kildekoden blive distribueret til en dedikeret build-server for at sikre, at build ikke fejler, og alle testklasser og integrationstests kører fint.
• Derefter implementeres build-applikationen på testserverne (præproduktionsservere) til UAT (User Acceptance Test).
• Endelig distribueres applikationen manuelt på produktionsserverne til frigivelse.

Før jeg fortsætter, vil det kun være rimeligt, at jeg forklarer dig de forskellige typer test.

Typer af softwaretest:

Generelt er der to typer test:

• Blackbox-test: Det er en testteknik, der ignorerer systemets interne mekanisme og fokuserer på output genereret mod enhver input og udførelse af systemet. Det kaldes også funktionstest. Det bruges grundlæggende til validering af softwaren.
• Whitebox-test: er en testteknik, der tager højde for systemets interne mekanisme. Det kaldes også strukturel test og glasbokstest. Det bruges dybest set til verificering af softwaren.

Whitebox test:

Der er to typer test, der falder ind under denne kategori.

• Enhedstest: Det er testning af en individuel enhed eller gruppe af relaterede enheder. Det gøres ofte af programmøren for at teste, at den enhed, han / hun har implementeret, producerer forventet output i forhold til givet input.
• Integrationstest: Det er en type test, hvor en gruppe af komponenter erkombineret for at producere output. Samspillet mellem software og hardware testes også, hvis software og hardwarekomponenter har nogen sammenhæng. Det kan falde ind under både hvid boks test og sort boks test.

Blackbox-test:

Der er flere tests, der falder ind under denne kategori. Jeg vil fokusere pånogle få, som er vigtige for dig at vide for at forstå denne blog:

• Funktionel / accept test: Det sikrer, at den specificerede funktionalitet, der kræves i systemkravene, fungerer. Det gøres for at sikre, at det leverede produkt opfylder kravene og fungerer som kunden forventede
• Systemtest: Det sikrer, at det stadig fungerer ved at placere softwaren i forskellige miljøer (f.eks. Operativsystemer).
• Stresstest: Det evaluerer, hvordan systemet opfører sig under ugunstige forhold.
• Betatestning: Det gøres af slutbrugere, et team uden for udvikling eller offentligt frigive en fuld præversion af det produkt, der er kendt sombetaversion. Målet med betatestning er at dække uventede fejl.

Det er nu det rigtige tidspunkt for mig at forklare forskellen mellem kontinuerlig integration, levering og implementering.

Forskelle mellem kontinuerlig integration, levering og implementering:

Visuelt indhold når en persons hjerne på en hurtigere og mere forståelig måde end tekstinformation. Så jeg skal starte med et diagram, der tydeligt forklarer forskellen:

I kontinuerlig integration bygges og testes alle kodeforpligtelser, men er ikke i en tilstand, der frigives. Jeg mener, at build-applikationen ikke automatisk implementeres på testserverne for at validere den ved hjælp af forskellige typer Blackbox-test som - User Acceptance Testing (UAT).

I kontinuerlig levering distribueres applikationen kontinuerligt på testserverne til UAT. Eller du kan sige, at applikationen er klar til at blive frigivet til produktion når som helst. Så det er åbenbart nødvendigt med kontinuerlig integration til kontinuerlig levering.

Kontinuerlig implementering er det næste trin forbi kontinuerlig levering, hvor du ikke bare opretter en implementerbar pakke, men faktisk implementerer den automatisk.

Lad mig sammenfatte forskellene ved hjælp af en tabel:

Enkelt sagt er kontinuerlig integration en del af både kontinuerlig levering og kontinuerlig implementering. Og kontinuerlig implementering er som kontinuerlig levering, bortset fra at udgivelser sker automatisk.

Lær hvordan du opretter CI / CD-rørledninger ved hjælp af Jenkins On Cloud

Men spørgsmålet er, om det er nok med kontinuerlig integration.

Hvorfor har vi brug for kontinuerlig levering?

Lad os forstå dette med et eksempel.

Forestil dig, at der er 80 udviklere, der arbejder på et stort projekt. De bruger kontinuerlige integrationsrørledninger for at lette automatiserede byggerier. Vi ved, at build også inkluderer enhedstest. En dag besluttede de at implementere den nyeste build, der havde bestået enhedstestene i et testmiljø.

Dette skal være en langvarig, men kontrolleret tilgang til implementering, som deres miljøspecialister udførte. Imidlertid syntes systemet ikke at fungere.

Hvad kan være den åbenlyse årsag til svigtet?

Den første grund til, at de fleste mennesker tror, ​​er, at der er noget problem med konfigurationen. Som de fleste troede de selv det.De brugte meget tid på at forsøge at finde, hvad der var galt med konfigurationen af ​​miljøet, men de kunne ikke finde problemet.

En opfattende udvikler tog en smart tilgang:

Derefter prøvede en af ​​seniorudviklerne applikationen på sin udviklingsmaskine. Det fungerede heller ikke der.

Han trådte tilbage gennem tidligere og tidligere versioner, indtil han fandt ud af, at systemet var stoppet med at arbejde tre uger tidligere. En lille, obskur bug havde forhindret systemet i at starte korrekt. Skønt projektet havde god enhedstestdækning.På trods af dette så 80 udviklere, der normalt kun kørte testene i stedet for selve applikationen, ikke problemet i tre uger.

Problemformulering:

Uden at køre Acceptance Tests i et produktionslignende miljø ved de intet om, hvorvidt applikationen opfylder kundens specifikationer, eller om den kan implementeres og overleve i den virkelige verden. Hvis de ønsker rettidig feedback om disse emner, skal de udvide rækkevidden af ​​deres kontinuerlige integrationsproces.

Lad mig opsummere de erfaringer, der er gjort ved at se på ovenstående problemer:

• Enhedstest tester kun udviklerens perspektiv på løsningen på et problem. De har kun en begrænset evne til at bevise, at applikationen gør, hvad den skal fra et brugerperspektiv. De er ikke nok tilidentificere de virkelige funktionelle problemer.
• Implementering af applikationen i testmiljøet er en kompleks, manuelt intensiv proces, der var ret udsat for fejl.Dette betød, at hvert forsøg på implementering var et nyt eksperiment - en manuel, fejlbehæftet proces.

Løsning - Kontinuerlig leveringsrørledning (automatiseret accepttest):

De tog kontinuerlig integration (kontinuerlig levering) til næste trin og introducerede et par enkle, automatiserede accepttest, der beviste, at applikationen kørte og kunne udføre sin mest grundlæggende funktion.Størstedelen af ​​de tests, der kører i Acceptance Test-fasen, er Functional Acceptance Tests.

Dybest set byggede de en kontinuerlig leveringsrørledning for at sikre, at applikationen er problemfrit implementeret i produktionsmiljøet ved at sikre, at applikationen fungerer fint, når den distribueres på testserveren, som er en replika af produktionsserveren.

Nok af teorien vil jeg nu vise dig, hvordan du opretter en pipeline for kontinuerlig levering ved hjælp af Jenkins.

Kontinuerlig leveringsrørledning ved hjælp af Jenkins:

Her bruger jeg Jenkins til at oprette en kontinuerlig leveringsrørledning, som vil omfatte følgende opgaver:

Trin involveret i demo:

• Henter koden fra GitHub
• Kompilering af kildekoden
• Enhedstest og generering af JUnit testrapporter
• Pakning af applikationen i en WAR-fil og implementering af den på Tomcat-serveren

Forudsætninger:

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

Trin - 1 Kompilering af kildekoden:

Lad os begynde med først at oprette et Freestyle-projekt i Jenkins. Overvej nedenstående skærmbillede:

Giv dit projekt et navn, og vælg Freestyle Project:

Når du ruller ned, finder du en mulighed for at tilføje kildekodelager, vælg git og tilføj lager URL, i det lager er der en pom.xml-bøde, som vi vil bruge til at opbygge vores projekt. Overvej nedenstående skærmbillede:

Nu vil vi tilføje en Build Trigger. Vælg valgmuligheden SCM, grundlæggende konfigurerer vi Jenkins til at afstemme GitHub-arkivet efter hvert 5. minut for ændringer i koden. Overvej nedenstående skærmbillede:

Lad mig give dig en lille introduktion til Maven Build Cycle, før jeg fortsætter.

Hver af bygningens livscyklusser er defineret af en anden liste over byggefaser, hvor en byggefase repræsenterer et trin i livscyklussen.

Følgende er listen over byggefaser:

• validere - validere projektet er korrekt, og alle nødvendige oplysninger er tilgængelige
• kompil - kompilér kildekoden for projektet
• test - test den kompilerede kildekode ved hjælp af en passende enhedstestramme. Disse tests bør ikke kræve, at koden pakkes eller implementeres
• pakke - tag den kompilerede kode og pakke den i dens distribuerbare format, såsom en JAR.
• verificer - kør enhver kontrol af resultaterne af integrationstest for at sikre, at kvalitetskriterierne er opfyldt
• install - installer pakken i det lokale lager til brug som en afhængighed i andre projekter lokalt
• implementering - udført i bygningsmiljøet, kopierer den endelige pakke til fjernlageret til deling med andre udviklere og projekter.

Jeg kan køre kommandoen nedenfor til kompilering af kildekoden, test af enheder og endda emballering af applikationen i en krigsfil:

mvn ren pakke

Du kan også opdele dit byggejob i et antal byggetrin. Dette gør det lettere at organisere byggerier i rene, separate faser.

Så vi begynder med at kompilere kildekoden. I fanen build skal du klikke på påkald maven-mål på øverste niveau og skrive nedenstående kommando:

udarbejde

Overvej nedenstående skærmbillede:

Dette trækker kildekoden fra GitHub-arkivet og kompilerer den også (Maven Compile Phase).

Klik på Gem og kør projektet.

Klik nu på konsoludgangen for at se resultatet.

Trin - 2 enhedstest:

Nu opretter vi endnu et Freestyle-projekt til enhedstest.

Tilføj den samme opbevarings-URL på kildekodeadministrationsfanen, som vi gjorde i det forrige job.

Klik nu på fanen 'Buid Trigger' på 'build efter andre projekter er bygget'. Der skriver du navnet på det forrige projekt, hvor vi kompilerer kildekoden, og du kan vælge en af ​​nedenstående muligheder:

• Trigger kun, hvis build er stabilt
• Udløs, selvom bygningen er ustabil
• Udløs, selvom build mislykkes

Jeg synes, at ovenstående muligheder er ret selvforklarende, så vælg en hvilken som helst. Overvej nedenstående skærmbillede:

På fanen Build skal du klikke på påkald maven-mål på øverste niveau og bruge nedenstående kommando:

prøve

Jenkins gør også et godt stykke arbejde med at hjælpe dig med at vise dine testresultater og testresultattrends.

De facto-standarden til testrapportering i Java-verdenen er et XML-format, der bruges af JUnit. Dette format bruges også af mange andre Java-testværktøjer, såsom TestNG, Spock og Easyb. Jenkins forstår dette format, så hvis din build producerer JUnit XML-testresultater, kan Jenkins generere flotte grafiske testrapporter og statistikker om testresultater over tid og også lade dig se detaljerne i eventuelle testfejl. Jenkins holder også styr på, hvor lang tid dine tests tager at køre, både globalt og pr. Test - dette kan være nyttigt, hvis du har brug for at spore ydeevneproblemer.

Så den næste ting, vi skal gøre, er at få Jenkins til at holde styr på vores enhedstest.

Gå til sektionen Post-build-handlinger, og marker afkrydsningsfeltet 'Udgiv JUnit-testresultatrapport'. Når Maven kører enhedstest i et projekt, genererer den automatisk XML-testrapporterne i en mappe kaldet surefire-reports. Så indtast “** / target / surefire-reports / *. Xml” i feltet “Test report XMLs”. De to stjerner ved starten af ​​stien (“**”) er en bedste praksis for at gøre konfigurationen lidt mere robust: de giver Jenkins mulighed for at finde målkataloget, uanset hvordan vi har konfigureret Jenkins til at tjekke kildekoden.

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

Gem det igen og klik på Build Now.

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

I Jenkins-instrumentbrættetDu kan også bemærke testresultaterne:

Trin - 3 Oprettelse af en WAR-fil og implementering på Tomcat-serveren:

Nu er det næste trin at pakke vores ansøgning i en WAR-fil og distribuere den på Tomcat-serveren til test af brugeraccept.

Opret endnu et freestyle-projekt, og tilføj kildekoden til opbevarings-URL.

Vælg derefter build, når andre projekter bygges, i fanen build-trigger, overvej nedenstående skærmbillede:

Dybest set starter implementeringsfasen efter testjobbet automatisk.

På shell-fanen skal du vælge shell-script. Skriv nedenstående kommando for at pakke applikationen i en WAR-fil:

mvn-pakke

Næste trin er at distribuere denne WAR-fil til Tomcatserver. På fanen 'Handlinger efter opbygning' skal du indsætte krig / øre til en container. Her skal du give stien til krigsfilen og give kontekststien. Overvej nedenstående skærmbillede:

Vælg Tomcat-legitimationsoplysninger, og bemærk ovenstående skærmbillede. Du skal også angive URL-adressen til din Tomcat-server.

For at tilføje legitimationsoplysninger i Jenkins skal du klikke på legitimationsoplysninger på Jenkins-instrumentbrættet.

Klik på System, og vælg globale legitimationsoplysninger.

Derefter finder du en mulighed for at tilføje legitimationsoplysningerne. Klik på det og tilføj legitimationsoplysninger.

Tilføj Tomcat-legitimationsoplysningerne, overvej nedenstående skærmbillede.

Klik på OK.

Nu skal du tilføje de tomcat-legitimationsoplysninger, som du har indsat i det foregående trin, i din projektkonfiguration.

hvordan man erklærer dynamisk array i java

Klik på Gem, og vælg derefter Byg nu.

Gå til din tomcat URL med kontekststien, i mit tilfælde er det http: // localhost: 8081. Tilføj nu kontekststien til sidst, overvej nedenstående skærmbillede:

Link - http: // localhost: 8081 / gof

Jeg håber, du har forstået betydningen af ​​kontekststien.

Opret nu en rørledningsvisning, overvej nedenstående skærmbillede:

Klik på plusikonet for at oprette en ny visning.

Konfigurer rørledningen, som du vil, overvej nedenstående skærmbillede:

Jeg ændrede ikke andet end at vælge det oprindelige job. Så min pipeline starter fra kompilering. Baseret på den måde, jeg har konfigureret andre job på, vil der efter kompileringstest og implementering ske.

Endelig kan du teste rørledningen ved at klikke på KØR. Efter hvert femte minut udføres hele pipelinen, hvis der er en ændring i kildekoden.

Så vi er i stand til løbende at implementere vores applikation på testserveren til brugeracceptatest (UAT).

Jeg håber, du har nydt at læse dette indlæg om kontinuerlig levering. Hvis du er i tvivl, er du velkommen til at sætte dem i kommentarfeltet nedenfor, og jeg vil tidligst komme tilbage med et svar.

For at opbygge CI / CD-rørledninger skal du mestre en bred vifte af færdigheder Lær de krævede DevOps-færdigheder nu