Inleiding tot Jenkins 2 en de kracht van pijpleidingen

1. Overzicht

In dit artikel laten we het gebruik van pijplijnen zien aan de hand van een voorbeeld van continue levering met Jenkins.

We gaan een eenvoudige, maar vrij nuttige pijplijn bouwen voor ons voorbeeldproject:

  • Compilatie
  • Eenvoudige statische analyse (parallel met compilatie)
  • Eenheidstests
  • Integratietests (parallel met unit-tests)
  • Inzet

2. Jenkins opzetten

Allereerst moeten we de nieuwste stabiele versie van Jenkins downloaden (2.73.3 op het moment dat dit artikel werd geschreven).

Laten we naar de map gaan waar ons bestand zich bevindt en het uitvoeren met behulp van de java -jar jenkins.war opdracht. Houd er rekening mee dat we Jenkins niet kunnen gebruiken zonder een eerste gebruikersconfiguratie.

Na het ontgrendelen van Jenkins met het initieel door de beheerder gegenereerde wachtwoord, moeten we profielinformatie van de eerste admin-gebruiker invullen en ervoor zorgen dat alle aanbevolen plug-ins zijn geïnstalleerd.

Nu hebben we een nieuwe installatie van Jenkins, klaar voor gebruik.

Alle beschikbare versies van Jenkins zijn hier te vinden.

3. Pijpleidingen

Jenkins 2 wordt geleverd met een geweldige functie genaamd Pijpleidingen, wat zeer uitbreidbaar is wanneer we een continue integratieomgeving voor een project moeten definiëren.

Een pijplijn is een andere manier om enkele Jenkins-stappen te definiëren met behulp van code, en automatiseer het proces van het implementeren van software.

Het gebruikt een Domain Specific Language (DSL) met twee verschillende syntaxis:

  • Declaratieve pijplijn
  • Scripted Pipeline

In onze voorbeelden gaan we gebruiken de Scripted Pipeline dat een meer dwingend programmeermodel volgt dat is gebouwd met Groovy.

Laten we enkele kenmerken van het Pijpleiding inpluggen:

  • pijplijnen worden in een tekstbestand geschreven en als code behandeld; dit betekent dat ze kunnen worden toegevoegd aan versiebeheer en later kunnen worden gewijzigd
  • ze blijven behouden na het opnieuw opstarten van de Jenkins-server
  • we kunnen optioneel pijpleidingen pauzeren
  • ze ondersteunen complexe vereisten, zoals het parallel uitvoeren van werkzaamheden
  • de Pipeline-plug-in kan ook worden uitgebreid of geïntegreerd met andere plug-ins

Met andere woorden, het opzetten van een pijplijnproject betekent het schrijven van een script dat achtereenvolgens enkele stappen van het proces toepast dat we willen volbrengen.

Om pipelines te kunnen gebruiken, moeten we de Pipeline-plug-in installeren waarmee eenvoudige en complexe automatisering kan worden samengesteld.

We kunnen optioneel ook de Pipeline Stage View hebben, zodat wanneer we een build uitvoeren, we alle fasen zien die we hebben geconfigureerd.

4. Een snel voorbeeld

Voor ons voorbeeld gebruiken we een kleine Spring Boot-applicatie. We maken dan een pijplijn die het project kloont, bouwt en verschillende tests uitvoert, en vervolgens de applicatie uitvoert.

Laten we het Controlestijl,Statisch Analyse Verzamelaar en JUnit plug-ins, die respectievelijk handig zijn om te verzamelen Controlestijl resultaten, maak een gecombineerde analysegrafiek van de testrapporten en illustreer succesvol uitgevoerde en mislukte tests.

Laten we eerst de reden van Checkstyle hier begrijpen: het is een ontwikkeltool die programmeurs helpt om betere Java-code te schrijven volgens geaccepteerde en bekende standaarden.

Static Analysis Collector is een add-on die verschillende analyse-outputs verzamelt en de resultaten afdrukt in een gecombineerde trendgrafiek. Bovendien biedt de plug-in gezondheidsrapportage en bouwstabiliteit op basis van deze gegroepeerde resultaten.

eindelijk, de JUnit plug-in biedt een uitgever die XML-testrapporten gebruikt die zijn gegenereerd tijdens de builds en gedetailleerde en zinvolle informatie uitvoert met betrekking tot de tests van een project.

We zullen ook configureren Controlestijl in onze applicaties pom.xml:

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

5. Een pijplijnscript maken

Eerst moeten we een nieuwe Jenkins-taak maken. Laten we zeker selecteren Pijpleiding als het type voordat je op de OK-knop drukt, zoals beschreven in deze schermafbeelding:

In het volgende scherm kunnen we meer details invullen van de verschillende stappen van onze Jenkins-taak, zoals de Omschrijving, triggers, sommige geavanceerde projectopties:

Laten we in het belangrijkste en belangrijkste deel van dit soort werk duiken door op de te klikken Pijpleiding tabblad.

Selecteer vervolgens voor de definitie Pipeline-script en check Gebruik Groovy Sandbox.

Hier is het werkende script voor een Unix-omgeving:

knooppunt {stage 'Kloon het project' git '//github.com/eugenp/tutorials.git' dir ('spring-jenkins-pipeline') {stage ("Compilatie en analyse") {parallel 'Compilatie': {sh " ./mvnw schone installatie -DskipTests "}, 'Static Analysis': {stage (" Checkstyle ") {sh" ./mvnw checkstyle: checkstyle "step ([$ class: 'CheckStylePublisher', canRunOnFailed: true, defaultEncoding: '' , gezond: '100', patroon: '** / target / checkstyle-result.xml', unHealthy: '90', useStableBuildAsReference: true])}}} stage ("Tests and Deployment") {parallel '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} step ([$ class:' JUnitResultArchiver ', testResults:' ** / target / surefire-reports / TEST- * UnitTest.xml '])}},' Integratietests ' : {stage ("Runing integratietests") {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 '])}} stage ("Staging") {sh "pid = \ $ (lsof -i: 8989 -t); kill -TERM \ $ pid "+" || kill -KILL \ $ pid "withEnv (['JENKINS_NODE_COOKIE = dontkill']) {sh 'nohup ./mvnw spring-boot: run -Dserver.port = 8989 &'}}}}}

Eerst klonen we de repository vanuit GitHub en veranderen we de directory naar ons project, dat wordt genoemd spring-jenkins-pipeline.

Vervolgens hebben we het project samengesteld en hebben we ons aangemeld Controlestijl analyse op een parallelle manier.

De volgende stap vertegenwoordigt een parallelle uitvoering van unit tests en integratietests, en vervolgens de implementatie van de app.

Parallellisme wordt gebruikt om de pijplijn te optimaliseren en de taak sneller te laten verlopen. Het is een best practice in Jenkins om tegelijkertijd enkele onafhankelijke acties uit te voeren die veel tijd kunnen kosten.

In een real-world project hebben we bijvoorbeeld meestal veel unit- en integratietests die langer kunnen duren.

Merk op dat als een test mislukt, de BUILD ook wordt gemarkeerd als FAILED en dat de implementatie niet zal plaatsvinden.

We gebruiken ook JENKINS_NODE_COOKIE om te voorkomen dat onze applicatie onmiddellijk wordt afgesloten wanneer de pijplijn het einde bereikt.

Bekijk de GitHub-repository om een ​​algemener script te zien dat op andere verschillende systemen werkt.

6. Analyserapport

Nadat we de taak hebben gemaakt, slaan we ons script op en slaan we op Bouw nu op de projectpagina van ons Jenkins-dashboard.

Hier is een overzicht van de builds:

Iets verderop vinden we het podiumaanzicht van de pijplijn, met het resultaat van elke fase:

Elke uitvoer is toegankelijk wanneer u de muisaanwijzer over een stadiumcel beweegt en op de Logboeken om de logboekberichten te zien die in die stap zijn afgedrukt.

We kunnen ook meer details van de code-analyse vinden. Laten we op de gewenste build klikken in het Bouw geschiedenis op in het rechtermenu en druk op Checkstyle-waarschuwingen.

Hier zien we 60 waarschuwingen met hoge prioriteit die kunnen worden doorzocht door te klikken op:

De Details tabblad geeft stukjes informatie weer die waarschuwingen markeren en de ontwikkelaar in staat stellen de oorzaken erachter te begrijpen.

Op dezelfde manier is het volledige testrapport toegankelijk door op te klikken Testresultaat koppeling. Laten we eens kijken naar de resultaten van de com.baeldung pakket:

Hier kunnen we elk testbestand zien met zijn duur en status.

7. Conclusie

In dit artikel hebben we een eenvoudige continue leveringsomgeving opgezet om statische code-analyse en testrapport in Jenkins uit te voeren en weer te geven via een Pijpleiding baan.

Zoals altijd is de broncode voor dit artikel te vinden op GitHub.


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