Jenkins tilbyder en enkel måde at oprette et kontinuerligt integrations- eller kontinuerligt leveringsmiljø (CI / CD) til næsten enhver kombination af sprog og kildekodelagre, der bruger rørledninger, samt automatisering af andre rutinemæssige udviklingsopgaver. Mens Jenkins ikke fjerner behovet for at oprette scripts til individuelle trin, giver det dig en hurtigere og mere robust måde at integrere hele din kæde af bygge-, test- og implementeringsværktøjer, end du nemt kan bygge dig selv.
"Bryde ikke den natlige bygning!" er en hovedregel i softwareudviklingsbutikker, der hver morgen udsender en nybygget produktversion til deres testere. Før Jenkins var det bedste, en udvikler kunne gøre for at undgå at bryde den natlige opbygning, at bygge og teste omhyggeligt og med succes på en lokal maskine, inden han begik koden. Men det betød at teste ens ændringer isoleret, uden alle andres daglige forpligtelser. Der var ingen fast garanti for, at den natlige bygning ville overleve ens forpligtelse.
Jenkins - oprindeligt Hudson - var et direkte svar på denne begrænsning.
Hudson og Jenkins
I 2004 var Kohsuke Kawaguchi Java-udvikler hos Sun. Kawaguchi blev træt af at bryde byggeri i sit udviklingsarbejde og ønskede at finde en måde at vide, før koden til arkivet lagrede, om koden skulle fungere. Så Kawaguchi byggede en automatiseringsserver i og for Java for at gøre det muligt, kaldet Hudson. Hudson blev populær hos Sun og spredte sig til andre virksomheder som open source.
Hurtigt frem til 2011, og en tvist mellem Oracle (som havde erhvervet Sun) og det uafhængige Hudson open source-samfund førte til en gaffel med navneændring, Jenkins. I 2014 blev Kawaguchi CTO for CloudBees, der tilbyder Jenkins-baserede kontinuerlige leveringsprodukter.
Begge gafler fortsatte med at eksistere, skønt Jenkins var meget mere aktiv. I dag er Jenkins-projektet stadig aktivt. Hudson-webstedet blev lukket den 31. januar 2020.
I marts 2019 lancerede Linux Foundation sammen med CloudBees, Google og en række andre virksomheder et nyt open source softwarefond kaldet Continuous Delivery Foundation (CDF). Jenkins-bidragsydere besluttede, at deres projekt skulle tilslutte sig dette nye fundament. Kawaguchi skrev på det tidspunkt, at intet af betydning ville ændre sig for brugerne.
I januar 2020 meddelte Kawaguchi, at han flyttede til sin nye opstart, Launchable. Han sagde også, at han officielt ville træde tilbage fra Jenkins, skønt han forbliver i den tekniske overvågningskomité for Continuous Delivery Foundation og skifter sin rolle hos CloudBees til en rådgiver.
Relateret video: Sådan leveres kode hurtigere med CI / CD
Jenkins automatisering
I dag er Jenkins den førende open source-automatiseringsserver med omkring 1.600 plug-ins til at understøtte automatisering af alle former for udviklingsopgaver. Problemet Kawaguchi oprindeligt forsøgte at løse, kontinuerlig integration og kontinuerlig levering af Java-kode (dvs. bygningsprojekter, kørsel af tests, udførelse af statisk kodeanalyse og implementering) er kun en af mange processer, som folk automatiserer med Jenkins. Disse 1.600 plug-ins spænder over fem områder: platforme, brugergrænseflade, administration, kildekodestyring og oftest bygningsadministration.
Hvordan Jenkins fungerer
Jenkins distribueres som et WAR-arkiv og som installationspakker til de største operativsystemer, som en Homebrew-pakke, som et Docker-billede og som kildekode. Kildekoden er for det meste Java med et par Groovy-, Ruby- og Antlr-filer.
Du kan køre den enkeltstående Jenkins WAR eller som en servlet på en Java-applikationsserver som Tomcat. I begge tilfælde producerer den en webbrugergrænseflade og accepterer opkald til sin REST API.
Når du kører Jenkins for første gang, opretter den en administrativ bruger med en lang tilfældig adgangskode, som du kan indsætte på dens oprindelige webside for at låse op for installationen.
Jenkins-plugins
Når Jenkins er installeret, kan du enten acceptere standardpluginlisten eller vælge dine egne plugins.
Når du har valgt dit oprindelige sæt plug-ins, skal du klikke på knappen Installer og Jenkins vil tilføje dem.
Hovedskærmen på Jenkins viser den aktuelle buildkø og eksekutorstatus og tilbyder links til at oprette nye emner (job), administrere brugere, se buildhistorikker, administrere Jenkins, se på dine tilpassede visninger og administrere dine legitimationsoplysninger.
Et nyt Jenkins-emne kan være en hvilken som helst af seks jobtyper plus en mappe til organisering af emner.
Der er 18 ting, du kan gøre fra siden Administrer Jenkins, herunder muligheden for at åbne en kommandolinjegrænseflade. På dette tidspunkt skal vi dog se på rørledninger, som er forbedrede arbejdsgange, der typisk defineres af scripts.
Jenkins rørledninger
Når du har konfigureret Jenkins, er det tid til at oprette nogle projekter, som Jenkins kan bygge for dig. Mens du kan Brug web-UI til at oprette scripts, den nuværende bedste praksis er at oprette et pipeline-script, der hedder Jenkinsfile, og tjek det i dit arkiv. Skærmbilledet nedenfor viser konfigurationswebformularen til en multibranch-pipeline.
Som du kan se, kan grenkilder til denne type rørledning i min grundlæggende Jenkins-installation være Git- eller Subversion-arkiver, inklusive GitHub. Hvis du har brug for andre slags arkiver eller forskellige online repository-tjenester, er det bare et spørgsmål om at tilføje de relevante plug-ins og genstarte Jenkins. Jeg prøvede, men kunne ikke tænke på et kildekodestyringssystem (SCM), der ikke allerede har et Jenkins-plug-in.
Jenkins-rørledninger kan være deklarative eller scriptede. EN erklærende pipeline, den enkleste af de to, bruger Groovy-kompatibel syntaks — og hvis du vil, kan du starte filen med #! groovy for at pege din kodeditor i den rigtige retning. En deklarativ pipeline starter med en rørledning blokerer, definerer en agentog definerer niveauer der inkluderer eksekverbar trinsom i tretrinseksemplet nedenfor.
rørledning { agent enhver
niveauer {
scene ('Byg') {
trin {
ekko 'Bygning ..'
}
}
fase ('Test') {
trin {
ekko 'Testing ..'
}
}
fase ('Implementere') {
trin {
ekko 'Implementering ....'
}
}
}
}
rørledning er den obligatoriske ydre blok til at påkalde Jenkins pipeline plugin. agent definerer, hvor du vil køre rørledningen. nogen siger at bruge enhver tilgængelig agent til at køre rørledningen eller scenen. En mere specifik agent kan erklære en container til brug, for eksempel:
agent { docker {
billede 'maven: 3-alpine'
mærke 'min-definerede-etiket'
args '-v / tmp: / tmp'
}
}
niveauer indeholder en sekvens af et eller flere scenedirektiver. I eksemplet ovenfor er de tre faser Build, Test og Deploy.
trin udføre det egentlige arbejde. I eksemplet ovenfor er trinene bare trykte beskeder. Et mere nyttigt byggetrin kan se ud som følger:
rørledning { agent enhver
niveauer {
scene ('Byg') {
trin {
sh 'make'
archiveArtifacts artefakter: ‘** / target / *. jar’, fingeraftryk: true
}
}
}
}
Her påberåber vi os lave fra en skal og derefter arkivere alle producerede JAR-filer til Jenkins-arkivet.
Det stolpe sektion definerer handlinger, der køres i slutningen af pipeline-kørslen eller scenen. Du kan bruge et antal eftertilstandsblokke inden for indlægssektionen: altid, ændret, fiasko, succes, ustabilog afbrudt.
For eksempel kører nedenstående Jenkins-fil altid JUnit efter testfasen, men sender kun en e-mail, hvis rørledningen mislykkes.
rørledning { agent enhver
niveauer {
fase ('Test') {
trin {
sh 'tjek'
}
}
}
post {
altid {
junit '** / target / *. xml'
}
fiasko {
mail til: [email protected], emne: 'Rørledningen mislykkedes :('
}
}
}
Den deklarative pipeline kan udtrykke det meste af det, du har brug for for at definere rørledninger, og er meget lettere at lære end den scriptede pipeline-syntaks, som er en Groovy-baseret DSL. Den scriptede pipeline er faktisk et fuldt programmeret miljø.
Til sammenligning er de følgende to Jenkinsfiles fuldstændig ækvivalente.
Deklarativ rørledning
rørledning { agent {docker ‘node: 6.3’}
niveauer {
scene ('build') {
trin {
sh ‘npm —version’
}
}
}
}
Skriptet pipeline
node ('docker') { kassen scm
scene ('Byg') {
docker.image (‘node: 6.3’). inde i {
sh 'npm - version'
}
}
}
Blue Ocean, Jenkins GUI
Hvis du gerne vil have den nyeste og bedste Jenkins UI, kan du bruge Blue Ocean plug-in, som giver en grafisk brugeroplevelse. Du kan tilføje Blue Ocean-plug-in til din eksisterende Jenkins-installation eller køre en Jenkins / Blue Ocean Docker-container. Når Blue Ocean er installeret, har din Jenkins hovedmenu et ekstra ikon:
Du kan åbne Blue Ocean direkte, hvis du ønsker det. Det er i mappen / blue på Jenkins-serveren. Oprettelse af rørledning i Blue Ocean er lidt mere grafisk end i almindelig Jenkins:
Jenkins Docker
Som jeg nævnte tidligere distribueres Jenkins også som et Docker-billede. Der er ikke meget mere ved processen: Når du har valgt SCM-typen, skal du angive en URL og legitimationsoplysninger og derefter oprette en pipeline fra et enkelt arkiv eller scanne alle arkiver i organisationen. Hver filial med en Jenkinsfile får en pipeline.
Her kører jeg et Blue Ocean Docker-billede, der fulgte med nogle få Git-serviceplugins installeret end standardlisten over SCM-udbydere:
Når du har kørt nogle rørledninger, viser Blue Ocean plug-in deres status som vist ovenfor. Du kan zoome ind på en individuel pipeline for at se trin og trin:
Du kan også zoome ind på grene (øverst) og aktiviteter (nederst):
—
Hvorfor bruge Jenkins?
Det Jenkins Pipeline-plugin, vi har brugt, understøtter en generel kontinuerlig integration / kontinuerlig levering (CICD) -brugssag, hvilket sandsynligvis er den mest almindelige anvendelse for Jenkins. Der er specielle overvejelser for nogle andre brugssager.
Java-projekter var den oprindelige raison d'être for Jenkins. Vi har allerede set, at Jenkins understøtter bygning med Maven; det fungerer også med Ant, Gradle, JUnit, Nexus og Artifactory.
Android kører en slags Java, men introducerer spørgsmålet om, hvordan man tester på den brede vifte af Android-enheder. Plugin-modulet til Android-emulator giver dig mulighed for at opbygge og teste på så mange emulerede enheder, som du er interesseret i at definere. Google Play Publisher-pluginnet giver dig mulighed for at sende builds til en alfakanal i Google Play til frigivelse eller yderligere test på faktiske enheder.
Jeg har vist eksempler, hvor vi specificerede en Docker-container som agent for en pipeline, og hvor vi kørte Jenkins og Blue Ocean i en Docker-container. Docker-containere er meget nyttige i et Jenkins-miljø til forbedring af hastighed, skalerbarhed og konsistens.
Der er to store brugssager for Jenkins og GitHub. Den ene er buildintegration, som kan omfatte en servicekrog, der udløser Jenkins ved hver forpligtelse til dit GitHub-arkiv. Den anden er brugen af GitHub-godkendelse til at kontrollere adgangen til Jenkins via OAuth.
Jenkins understøtter mange andre sprog udover Java. For C / C ++ er der plugins til at registrere fejl og advarsler fra konsollen, generere build-scripts med CMake, køre enhedstest og udføre statisk kodeanalyse. Jenkins har en række integrationer med PHP-værktøjer.
Mens Python-kode ikke behøver at bygges (medmindre du f.eks. Bruger Cython eller opretter et Python-hjul til installation), er det nyttigt, at Jenkins integreres med Python-test- og rapporteringsværktøjer, såsom Nose2 og Pytest, og kodekvalitet værktøjer som Pylint. Tilsvarende integreres Jenkins med Ruby-værktøjer som Rake, Agurk, Brakeman og CI :: Reporter.
Jenkins til CI / CD
I det store og hele tilbyder Jenkins en enkel måde at oprette et CI / CD-miljø til stort set enhver kombination af sprog og kildekodebaserer ved hjælp af rørledninger samt automatisere en række andre rutineudviklingsopgaver. Mens Jenkins ikke eliminerer behovet for at oprette scripts til individuelle trin, giver det dig en hurtigere og mere robust måde at integrere hele din kæde af build-, test- og implementeringsværktøjer, end du let kunne bygge dig selv.
