Wat is Jenkins? De CI-server uitgelegd

Jenkins biedt een eenvoudige manier om een ​​continue integratie of continue levering (CI / CD) -omgeving op te zetten voor bijna elke combinatie van talen en broncode-opslagplaatsen met behulp van pijplijnen, en om andere routinematige ontwikkelingstaken te automatiseren. Hoewel Jenkins de noodzaak om scripts voor afzonderlijke stappen te maken niet overbodig maakt, biedt het u wel een snellere en robuustere manier om uw hele keten van build-, test- en implementatietools te integreren dan u gemakkelijk zelf kunt bouwen.

"Breek de nachtelijke build niet!" is een hoofdregel in softwareontwikkelingswinkels die elke ochtend een vers gebouwde dagelijkse productversie voor hun testers publiceren. Vóór Jenkins was het beste dat een ontwikkelaar kon doen om te voorkomen dat de nachtelijke build zou breken, door zorgvuldig en succesvol te bouwen en te testen op een lokale machine voordat de code werd vastgelegd. Maar dat betekende het afzonderlijk testen van iemands veranderingen, zonder de dagelijkse verplichtingen van iedereen. Er was geen vaste garantie dat de nachtelijke build iemands verplichting zou overleven.

Jenkins - oorspronkelijk Hudson - was een direct antwoord op deze beperking.

Hudson en Jenkins

In 2004 was Kohsuke Kawaguchi Java-ontwikkelaar bij Sun. Kawaguchi werd moe van het breken van builds in zijn ontwikkelingswerk en wilde een manier vinden om te weten, voordat hij code naar de repository ging, of de code zou werken. Dus bouwde Kawaguchi een automatiseringsserver in en voor Java om dat mogelijk te maken, genaamd Hudson. Hudson werd populair bij Sun en verspreidde zich als open source naar andere bedrijven.

Fast-forward naar 2011, en een geschil tussen Oracle (dat Sun had overgenomen) en de onafhankelijke open-sourcecommunity Hudson leidde tot een splitsing met een naamswijziging, Jenkins. In 2014 werd Kawaguchi CTO van CloudBees, dat op Jenkins gebaseerde producten voor continue levering aanbiedt.

Beide vorken bleven bestaan, hoewel Jenkins veel actiever was. Tegenwoordig is het Jenkins-project nog steeds actief. De Hudson-website is op 31 januari 2020 gesloten.

In maart 2019 lanceerde de Linux Foundation, samen met CloudBees, Google en een aantal andere bedrijven, een nieuwe open source softwarestichting, de Continuous Delivery Foundation (CDF). Bijdragers van Jenkins besloten dat hun project zich bij deze nieuwe stichting moest aansluiten. Kawaguchi schreef destijds dat er voor gebruikers niets van betekenis zou veranderen.

In januari 2020 kondigde Kawaguchi aan dat hij zou verhuizen naar zijn nieuwe startup, Launchable. Hij zei ook dat hij officieel afstand zou nemen van Jenkins, hoewel hij in de Technical Oversight Committee van de Continuous Delivery Foundation zou blijven en zijn rol bij CloudBees zou veranderen in een adviseur.

Gerelateerde video: Hoe code sneller te leveren met CI / CD

Jenkins-automatisering

Tegenwoordig is Jenkins de toonaangevende open-source automatiseringsserver met zo'n 1.600 plug-ins om de automatisering van allerlei ontwikkelingstaken te ondersteunen. Het probleem dat Kawaguchi oorspronkelijk probeerde op te lossen, is de voortdurende integratie en continue levering van Java-code (dwz projecten bouwen, tests uitvoeren, statische code analyseren en implementeren), is slechts een van de vele processen die mensen automatiseren met Jenkins. Die 1600 plug-ins beslaan vijf gebieden: platforms, gebruikersinterface, administratie, broncodebeheer en, meestal, buildbeheer.

Hoe Jenkins werkt

Jenkins wordt gedistribueerd als een WAR-archief en als installatiepakketten voor de belangrijkste besturingssystemen, als een Homebrew-pakket, als een Docker-image en als broncode. De broncode is voornamelijk Java, met een paar Groovy-, Ruby- en Antlr-bestanden.

U kunt de Jenkins WAR standalone of als een servlet in een Java-applicatieserver zoals Tomcat uitvoeren. In beide gevallen produceert het een webgebruikersinterface en accepteert het oproepen naar zijn REST API.

Wanneer u Jenkins voor de eerste keer start, maakt het een administratieve gebruiker aan met een lang willekeurig wachtwoord, dat u in de oorspronkelijke webpagina kunt plakken om de installatie te ontgrendelen.

Jenkins-plug-ins

Na installatie kunt u met Jenkins de standaard plug-inslijst accepteren of uw eigen plug-ins kiezen.

Nadat u uw eerste set plug-ins heeft gekozen, klikt u op de knop Installeren en Jenkins zal ze toevoegen.

Het hoofdscherm van Jenkins geeft de huidige build-wachtrij en de status Executor weer, en biedt links om nieuwe items (jobs) te maken, gebruikers te beheren, build-geschiedenissen te bekijken, Jenkins te beheren, je aangepaste weergaven te bekijken en je inloggegevens te beheren.

Een nieuw Jenkins-item kan elk van de zes soorten taken zijn, plus een map voor het organiseren van items.

Er zijn 18 dingen die u kunt doen vanaf de pagina Jenkins beheren, inclusief de optie om een ​​opdrachtregelinterface te openen. Op dit punt moeten we echter kijken naar pijplijnen, dit zijn verbeterde workflows die doorgaans worden gedefinieerd door scripts.

Jenkins-pijpleidingen

Zodra u Jenkins heeft geconfigureerd, is het tijd om een ​​aantal projecten te maken die Jenkins voor u kan bouwen. Terwijl u kunt de webinterface gebruiken om scripts te creëren, de huidige beste praktijk is om een pijpleiding script, genaamd Jenkinsfile maken , en laat het in uw repository. De onderstaande schermafbeelding toont het configuratie-webformulier voor een pijplijn met meerdere takken.

Zoals je kunt zien, kunnen branch-bronnen voor dit soort pijplijnen in mijn standaard Jenkins-installatie Git- of Subversion-repositories zijn, inclusief GitHub. Als je andere soorten repositories of verschillende online repository-services nodig hebt, is het gewoon een kwestie van de juiste plug-ins toevoegen en Jenkins opnieuw opstarten. Ik heb het geprobeerd, maar kon geen broncodebeheersysteem (SCM) bedenken dat nog geen Jenkins-plug-in heeft.

Jenkins-pijplijnen kunnen declaratief of scripted zijn. Een declaratieve pijplijn, de eenvoudigste van de twee, gebruikt Groovy-compatibele syntaxis - en als je wilt, kun je het bestand starten #!groovyom je code-editor in de goede richting te wijzen. Een declaratieve pijplijn begint met een pipelineblok, definieert een agenten definieert het stagesuitvoerbare bestand steps, zoals in het voorbeeld met drie fasen hieronder.

pijplijn {

    agent een

    stadia {

        stage ('Build') {

            stappen {

                echo 'Building ..'

            }

        }

        stage ('Test') {

            stappen {

                echo 'Testen ..'

            }

        }

        stage ('Implementeren') {

            stappen {

                echo 'Implementeren ...'

            }

        }

    }

}

pipelineis het verplichte buitenste blok om de Jenkins-pijplijnplug-in aan te roepen. agentdefinieert waar u de pijplijn wilt uitvoeren. anyzegt om elke beschikbare agent te gebruiken om de pijplijn of het podium te runnen. Een meer specifieke agent kan een container voor gebruik declareren, bijvoorbeeld:

agent {

    havenarbeider {

        afbeelding 'maven: 3-alpine'

        label 'mijn-gedefinieerd-label'

        args '-v / tmp: / tmp'

    }

}

stagesbevatten een opeenvolging van een of meer fase-instructies. In het bovenstaande voorbeeld zijn de drie fasen Build, Test en Deploy.

stepsdoe het eigenlijke werk. In het bovenstaande voorbeeld zijn de stappen alleen afgedrukte berichten. Een meer bruikbare buildstap kan er als volgt uitzien:

pijplijn {

    agent een

    stadia {

        stage ('Build') {

            stappen {

                sh 'maken'

                archiveArtifacts artefacten: '** / target / *. jar', vingerafdruk: waar

            }

        }

    }

}

Hier roepen we aan makevanuit een shell en archiveren we vervolgens alle geproduceerde JAR-bestanden naar het Jenkins-archief.

De postsectie definieert acties die worden uitgevoerd aan het einde van de pijplijnuitvoering of -fase. U kunt een aantal post-conditie blokken te gebruiken binnen de post sectie: always, changed, failure, success, unstable, en aborted.

Het Jenkinsfile hieronder voert bijvoorbeeld altijd JUnit uit na de testfase, maar verzendt alleen een e-mail als de pijplijn mislukt.

pijplijn {

    agent een

    stadia {

        stage ('Test') {

            stappen {

                sh 'controleer'

            }

        }

    }

    post {

        altijd {

            junit '** / target / *. xml'

        }

        mislukking {

            mail naar: [email protected], onderwerp: 'De pijplijn is mislukt :('

        }

    }

}

De declaratieve pijplijn kan het meeste uitdrukken van wat u nodig hebt om pijplijnen te definiëren, en is veel gemakkelijker te leren dan de gescripte pijplijnsyntaxis, een op Groovy gebaseerde DSL. De gescripte pijplijn is in feite een complete programmeeromgeving.

Ter vergelijking: de volgende twee Jenkins-bestanden zijn volledig equivalent.

Declaratieve pijplijn

pijplijn {

    agent {docker 'node: 6.3'}

    stadia {

        stage ('build') {

            stappen {

                sh 'npm —versie'

            }

        }

    }

Script-pijplijn

knooppunt ('docker') {

    kassa scm

    stage ('Build') {

        docker.image ('node: 6.3'). inside {

            sh 'npm —versie'

        }

    }

}

Blue Ocean, de GUI van Jenkins

Als je de nieuwste en beste Jenkins-gebruikersinterface wilt, kun je de Blue Ocean-plug-in gebruiken, die een grafische gebruikerservaring biedt. U kunt de Blue Ocean-plug-in toevoegen aan uw bestaande Jenkins-installatie of een Jenkins / Blue Ocean Docker-container uitvoeren. Als Blue Ocean is geïnstalleerd, heeft uw Jenkins-hoofdmenu een extra pictogram:

U kunt Blue Ocean direct openen als u dat wilt. Het staat in de map / blue op de Jenkins-server. Het maken van pijpleidingen in Blue Ocean is iets grafischer dan in gewone Jenkins:

Jenkins Docker

Zoals ik eerder al zei, wordt Jenkins ook gedistribueerd als een Docker-image. Er is niet veel meer aan het proces: als je eenmaal het SCM-type hebt gekozen, geef je een URL en referenties op, en maak je een pijplijn vanuit een enkele repository of scan je alle repositories in de organisatie. Elke branch met een Jenkinsfile krijgt een pijplijn.

Hier voer ik een Blue Ocean Docker-image uit, die werd geleverd met een paar meer geïnstalleerde Git-serviceplug-ins dan de standaardlijst met SCM-providers:

Zodra u enkele pijpleidingen heeft uitgevoerd, geeft de Blue Ocean-plug-in hun status weer, zoals hierboven weergegeven. U kunt inzoomen op een individuele pijplijn om de fasen en stappen te zien:

U kunt ook inzoomen op takken (boven) en activiteiten (onder):  

-

Waarom Jenkins gebruiken?

De Jenkins Pipeline-plug-in die we hebben gebruikt, ondersteunt een algemene use-case voor continue integratie / continue levering (CICD), die waarschijnlijk het meest wordt gebruikt voor Jenkins. Er zijn gespecialiseerde overwegingen voor sommige andere gebruikssituaties.

Javaprojecten waren de oorspronkelijke bestaansreden van Jenkins. We hebben al gezien dat Jenkins het bouwen met Maven ondersteunt; het werkt ook met Ant, Gradle, JUnit, Nexus en Artifactory.

Android draait een soort Java, maar introduceert de kwestie van testen op het brede scala aan Android-apparaten. Met de Android-emulator-plug-in kunt u bouwen en testen op zoveel geëmuleerde apparaten als u wilt definiëren. Met de plug-in voor Google Play-uitgevers kunt u builds naar een alfakanaal in Google Play verzenden voor release of verder testen op daadwerkelijke apparaten.

Ik heb voorbeelden laten zien waarin we een Docker-container specificeerden als de agent voor een pijplijn en waar we Jenkins en Blue Ocean in een Docker-container uitvoerden. Docker-containers zijn erg handig in een Jenkins-omgeving voor het verbeteren van snelheid, schaalbaarheid en consistentie.

Er zijn twee belangrijke use-cases voor Jenkins en GitHub. Een daarvan is build-integratie, die een service-hook kan bevatten om Jenkins te activeren bij elke commit naar uw GitHub-repository. De tweede is het gebruik van GitHub-authenticatie om de toegang tot Jenkins via OAuth te regelen.

Jenkins ondersteunt naast Java nog vele andere talen. Voor C / C ++ zijn er plug-ins om fouten en waarschuwingen van de console vast te leggen, build-scripts te genereren met CMake, unit-tests uit te voeren en statische code-analyse uit te voeren. Jenkins heeft een aantal integraties met PHP-tools.

Hoewel Python-code niet hoeft te worden gebouwd (tenzij je bijvoorbeeld Cython gebruikt of een Python-wiel maakt voor installatie), is het handig dat Jenkins kan worden geïntegreerd met Python-test- en rapportagetools, zoals Nose2 en Pytest, en codekwaliteit tools zoals Pylint. Evenzo kan Jenkins worden geïntegreerd met Ruby-tools zoals Rake, Cucumber, Brakeman en CI :: Reporter.

Jenkins voor CI / CD

Over het geheel genomen biedt Jenkins een eenvoudige manier om een ​​CI / CD-omgeving op te zetten voor vrijwel elke combinatie van talen en broncode-opslagplaatsen met behulp van pijplijnen, evenals het automatiseren van een aantal andere routinematige ontwikkelingstaken. Hoewel Jenkins niet de noodzaak wegneemt om scripts voor afzonderlijke stappen te maken, biedt het u wel een snellere en robuustere manier om uw hele keten van build-, test- en implementatietools te integreren dan u zelf gemakkelijk zou kunnen bouwen.