Introduksjon til Jenkins 2 og Power of Pipelines

1. Oversikt

I denne artikkelen skal vi vise bruken av rørledninger gjennom et eksempel på kontinuerlig levering ved bruk av Jenkins.

Vi skal bygge en enkel, men likevel ganske nyttig rørledning, for vårt prøveprosjekt:

  • Samling
  • Enkel statisk analyse (parallelt med kompilering)
  • Enhetstester
  • Integrasjonstester (parallelt med enhetstester)
  • Utplassering

2. Sette opp Jenkins

Først og fremst må vi laste ned den siste stabile versjonen av Jenkins (2.73.3 når du skriver denne artikkelen).

La oss navigere til mappen der filen vår er og kjøre den ved hjelp av java -jar jenkins.war kommando. Husk at vi ikke kan bruke Jenkins uten et første brukeroppsett.

Etter å ha låst opp Jenkins ved å bruke det første administratorgenererte passordet, må vi fylle ut profilinformasjonen til den første administratorbrukeren og sørge for å installere alle anbefalte plugins.

Nå har vi en ny installasjon av Jenkins klar til bruk.

Alle tilgjengelige versjoner av Jenkins finner du her.

3. Rørledninger

Jenkins 2 kommer med en flott funksjon som heter Rørledninger, som er veldig utvidbart når vi trenger å definere et kontinuerlig integrasjonsmiljø for et prosjekt.

En rørledning er en annen måte å definere noen Jenkins-trinn ved hjelp av kode, og automatisere prosessen med distribusjon av programvare.

Den bruker et Domain Specific Language (DSL) med to forskjellige syntakser:

  • Deklarativ rørledning
  • Skriptet rørledning

I eksemplene våre skal vi bruke de Skriptet rørledning som følger en mer tvingende programmeringsmodell bygget med Groovy.

La oss gå gjennom noen kjennetegn ved Rørledning plugg inn:

  • rørledninger skrives inn i en tekstfil og behandles som kode; Dette betyr at de kan legges til versjonskontroll og endres senere
  • de blir værende etter omstart av Jenkins-serveren
  • vi kan valgfritt stoppe rørledninger
  • de støtter komplekse krav som å utføre arbeid parallelt
  • Pipeline plugin kan også utvides eller integreres med andre plugins

Med andre ord, å sette opp et rørledningsprosjekt betyr å skrive et skript som sekvensielt vil bruke noen trinn i prosessen vi ønsker å utføre.

For å begynne å bruke rørledninger må vi installere Pipeline plugin som gjør det mulig å komponere enkel og kompleks automatisering.

Vi kan også ha Pipeline Stage View en slik at når vi kjører en build, ser vi alle trinnene vi har konfigurert.

4. Et raskt eksempel

For vårt eksempel bruker vi en liten Spring Boot-applikasjon. Deretter lager vi en rørledning som kloner prosjektet, bygger det og kjører flere tester, og deretter kjører applikasjonen.

La oss installere Checkstyle,Statisk Analyse Samler og JUnit plugins, som henholdsvis er nyttige å samle på Checkstyle resultater, bygge en kombinert analysegraf av testrapportene og illustrere vellykkede og mislykkede tester.

La oss først forstå årsaken til Checkstyle her: det er et utviklingsverktøy som hjelper programmerere å skrive bedre Java-kode etter aksepterte og kjente standarder.

Static Analysis Collector er et tillegg som samler forskjellige analyseutganger og skriver ut resultatene i en kombinert trendgraf. I tillegg gir plug-in helserapportering og stabilitet basert på disse grupperte resultatene.

Til slutt, JUnit plugin gir en utgiver som bruker XML-testrapporter generert under byggingen og leverer detaljert og meningsfull informasjon i forhold til testene av et prosjekt.

Vi konfigurerer også Checkstyle i søknaden vår pom.xml:

 org.apache.maven.plugins maven-checkstyle-plugin 2.17 

5. Opprette et rørledningsskript

Først må vi opprette en ny Jenkins-jobb. La oss være sikre på å velge Rørledning som typen før du trykker på OK-knappen som beskrevet i dette skjermbildet:

Det neste skjermbildet lar oss fylle ut flere detaljer om de forskjellige trinnene i Jenkins-jobben, for eksempel beskrivelse, utløser, noen avanserte prosjektalternativer:

La oss dykke ned i den viktigste og viktigste delen av denne typen jobber ved å klikke på Rørledning fanen.

Deretter velger du definisjonen Rørledningsskript og sjekk Bruk Groovy Sandbox.

Her er arbeidsskriptet for et Unix-miljø:

node {stage 'Clone the project' git '//github.com/eugenp/tutorials.git' dir ('spring-jenkins-pipeline') {stage ("Compilation and Analysis") {parallel 'Compilation': {sh " ./mvnw clean install -DskipTests "}, 'Static Analysis': {stage (" Checkstyle ") {sh" ./mvnw checkstyle: checkstyle "step ([$ class: 'CheckStylePublisher', canRunOnFailed: true, defaultEncoding: '' ' , sunn: '100', mønster: '** / target / checkstyle-result.xml', unHealthy: '90', useStableBuildAsReference: true])}}} stage ("Tests and Deployment") {parallelle "Unit tests" : {stage ("Runing unit tests") {try {sh "./mvnw test -Punit"} catch (err) {step ([$ class: 'JUnitResultArchiver', testResults: '** / target / surefire-reports / TEST- * UnitTest.xml ']) throw err} trinn ([$ class:' JUnitResultArchiver ', testResults:' ** / target / surefire-reports / TEST- * UnitTest.xml '])}},' Integration tests ' : {stage ("Runing integration tests") {try {sh "./mvnw test -Pintegration"} catch (err) {step ([$ class: 'JUnitResultArchiver', testResults: '** / tar get / surefire-reports / TEST- '+' * IntegrationTest.xml ']) throw err} step ([$ class:' JUnitResultArchiver ', testResults:' ** / target / surefire-reports / TEST- '+' * IntegrationTest .xml '])}} scene ("Staging") {sh "pid = \ $ (lsof -i: 8989 -t); drep -TERM \ $ pid "+" || drep -KILL \ $ pid "withEnv (['JENKINS_NODE_COOKIE = dontkill']) {sh 'nohup ./mvnw spring-boot: run -Dserver.port = 8989 &'}}}}}

Først kloner vi depotet fra GitHub, og endrer deretter katalogen til prosjektet vårt, som heter vår-jenkins-rørledning.

Deretter samlet vi prosjektet og søkte Checkstyle analyse på en parallell måte.

Følgende trinn representerer en parallell kjøring av enhetstester og integrasjonstester, og deretter distribusjon av appen.

Parallelisme brukes til å optimalisere rørledningen, og få jobben til å gå raskere. Det er en god praksis i Jenkins å samtidig kjøre noen uavhengige handlinger som kan ta mye tid.

For eksempel, i et prosjekt fra den virkelige verden, har vi vanligvis mange enhet- og integrasjonstester som kan ta lengre tid.

Vær oppmerksom på at hvis en test mislyktes, vil BUILD også bli merket som FAILED, og ​​distribusjonen vil ikke forekomme.

Vi bruker også JENKINS_NODE_COOKIE for å forhindre øyeblikkelig nedleggelse av applikasjonen vår når rørledningen når slutten.

For å se et mer generelt skript som fungerer på andre forskjellige systemer, sjekk ut GitHub-depotet.

6. Analyserapport

Etter å ha opprettet jobben, lagrer vi skriptet vårt og trykker Bygg nå på prosjekthjemmet til Jenkins-dashbordet vårt.

Her er en oversikt over byggene:

Litt lenger nede finner vi scenevisningen av rørledningen, med resultatet av hvert trinn:

Hver utgang er tilgjengelig når du svever over en scenecelle og klikker på Tømmerstokker -knappen for å se loggmeldingene som ble skrevet ut i det trinnet.

Vi kan også finne flere detaljer om kodeanalysen. La oss klikke på ønsket bygg fra Bygg historie på høyre meny og trykk Checkstyle Advarsler.

Her ser vi 60 advarsler med høy prioritet som kan leses ved å klikke på:

De Detaljer kategorien viser informasjon som fremhever advarsler og gjør det mulig for utvikleren å forstå årsakene bak dem.

På samme måte er hele testrapporten tilgjengelig ved å klikke på Prøve resultater lenke. La oss se resultatene av com.baeldung pakke:

Her kan vi se hver testfil med varighet og status.

7. Konklusjon

I denne artikkelen setter vi opp et enkelt kontinuerlig leveringsmiljø for å kjøre og vise analyse av statisk kode og testrapport i Jenkins via en Rørledning jobb.

Som alltid kan kildekoden for denne artikkelen finnes på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found