Programmering

Hva er Jenkins? CI-serveren forklarte

Jenkins tilbyr en enkel måte å sette opp et kontinuerlig integrasjons- eller kontinuerlig leveringsmiljø (CI / CD) for nesten hvilken som helst kombinasjon av språk og kildekodelager ved hjelp av rørledninger, samt automatisere andre rutinemessige utviklingsoppgaver. Selv om Jenkins ikke eliminerer behovet for å lage skript for individuelle trinn, gir det deg en raskere og mer robust måte å integrere hele kjeden av bygge-, test- og distribusjonsverktøy enn du enkelt kan bygge selv.

"Ikke bryt den nattlige bygningen!" er en hovedregel i programvareutviklingsbutikker som legger ut en nybygd daglig produktversjon hver morgen for testerne sine. Før Jenkins var det beste en utvikler kunne gjøre for å unngå å bryte den nattlige bygningen, å bygge og teste nøye og vellykket på en lokal maskin før han begikk koden. Men det betydde å teste ens endringer isolert, uten alle andres daglige forpliktelser. Det var ingen fast garanti for at den nattlige bygningen ville overleve ens forpliktelse.

Jenkins - opprinnelig Hudson - var et direkte svar på denne begrensningen.

Hudson og Jenkins

I 2004 var Kohsuke Kawaguchi Java-utvikler hos Sun. Kawaguchi ble lei av å bryte bygninger i sitt utviklingsarbeid og ønsket å finne en måte å vite før koden til depotet, om koden skulle fungere. Så Kawaguchi bygde en automatiseringsserver i og for Java for å gjøre det mulig, kalt Hudson. Hudson ble populær hos Sun, og spredte seg til andre selskaper som åpen kildekode.

Spol frem til 2011, og en tvist mellom Oracle (som hadde kjøpt Sun) og det uavhengige Hudson open source-samfunnet førte til en gaffel med navneendring, Jenkins. I 2014 ble Kawaguchi CTO for CloudBees, som tilbyr Jenkins-baserte kontinuerlige leveringsprodukter.

Begge gaflene fortsatte å eksistere, selv om Jenkins var mye mer aktiv. I dag er Jenkins-prosjektet fortsatt aktivt. Hudson-nettstedet ble lagt ned 31. januar 2020.

I mars 2019 lanserte Linux Foundation, sammen med CloudBees, Google og en rekke andre selskaper, en ny open source programvarestiftelse kalt Continuous Delivery Foundation (CDF). Jenkins-bidragsytere bestemte at prosjektet deres skulle bli med i denne nye stiftelsen. Kawaguchi skrev den gangen at ingenting av betydning ville endre seg for brukerne.

I januar 2020 kunngjorde Kawaguchi at han flyttet til sin nye oppstart, Launchable. Han sa også at han offisielt vil trekke seg tilbake fra Jenkins, selv om han blir i Technical Oversight Committee of the Continuous Delivery Foundation, og bytter sin rolle i CloudBees til en rådgiver.

Relatert video: Hvordan levere kode raskere med CI / CD

Jenkins automatisering

I dag er Jenkins den ledende automatiserte serveren med åpen kildekode med rundt 1600 plugin-moduler for å støtte automatisering av alle slags utviklingsoppgaver. Problemet Kawaguchi opprinnelig prøvde å løse, kontinuerlig integrering og kontinuerlig levering av Java-kode (dvs. bygge prosjekter, kjøre tester, gjøre statiske kodeanalyser og distribuere) er bare en av mange prosesser som folk automatiserer med Jenkins. Disse 1600 plugin-modulene spenner over fem områder: plattformer, brukergrensesnitt, administrasjon, kildekodeadministrasjon og, ofte, bygningsadministrasjon.

Hvordan Jenkins fungerer

Jenkins distribueres som et WAR-arkiv og som installasjonspakker for de viktigste operativsystemene, som en Homebrew-pakke, som et Docker-bilde og som kildekode. Kildekoden er for det meste Java, med noen få Groovy-, Ruby- og Antlr-filer.

Du kan kjøre den frittstående Jenkins WAR eller som en servlet i en Java-applikasjonsserver som Tomcat. I begge tilfeller produserer den et nettbrukergrensesnitt og godtar anrop til REST API.

Når du kjører Jenkins for første gang, oppretter den en administrativ bruker med et langt tilfeldig passord, som du kan lime inn på den opprinnelige nettsiden for å låse opp installasjonen.

Jenkins-plugin-moduler

Når Jenkins er installert, kan du enten godta standard plugin-listen eller velge dine egne plugins.

Når du har valgt det første settet med plugin-moduler, klikker du på Installer-knappen og Jenkins vil legge dem til.

Hovedskjermbildet til Jenkins viser den nåværende byggekøen og utførelsesstatusen, og tilbyr lenker for å opprette nye elementer (jobber), administrere brukere, se bygghistorikk, administrere Jenkins, se på dine tilpassede visninger og administrere legitimasjonen din.

Et nytt Jenkins-element kan være en av seks typer jobber pluss en mappe for å organisere ting.

Det er 18 ting du kan gjøre fra Manage Jenkins-siden, inkludert muligheten til å åpne et kommandolinjegrensesnitt. På dette punktet bør vi imidlertid se på rørledninger, som er forbedrede arbeidsflyter som vanligvis er definert av skript.

Jenkins rørledninger

Når du har konfigurert Jenkins, er det på tide å lage noen prosjekter som Jenkins kan bygge for deg. Mens du kan bruker nettgrensesnittet til å lage skript, er dagens beste praksis å lage et pipeline-skript, kalt Jenkinsfile, og sjekk det inn i depotet ditt. Skjermbildet nedenfor viser konfigurasjonsnettskjemaet for en multibranch-rørledning.

Som du kan se, kan grenkilder for denne typen rørledning i min grunnleggende Jenkins-installasjon være Git- eller Subversion-arkiver, inkludert GitHub. Hvis du trenger andre typer arkiver eller andre online depotjenester, er det bare å legge til de riktige plugin-modulene og starte Jenkins på nytt. Jeg prøvde, men kunne ikke tenke på et kildekodestyringssystem (SCM) som ikke allerede har en Jenkins-plugin.

Jenkins-rørledninger kan være deklarative eller skriptede. EN erklærende pipeline, den enkleste av de to, bruker Groovy-kompatibel syntaks — og hvis du vil, kan du starte filen med #! groovy for å peke kodeditoren i riktig retning. En deklarativ rørledning starter med en rørledning blokkerer, definerer en middel, og definerer trinn som inkluderer kjørbar trinn, som i tretrinnseksemplet nedenfor.

rørledning {

agent noen

etapper {

scene (‘Bygg’) {

trinn {

ekko ‘Building ..’

            }

        }

scene (‘Test’) {

trinn {

ekko ‘Testing ..’

            }

        }

scene (‘Deploy’) {

trinn {

ekko ‘Deploying ....’

            }

        }

    }

}

rørledning er den obligatoriske ytre blokken for å påkalle Jenkins pipeline plugin. middel definerer hvor du vil kjøre rørledningen. noen sier å bruke en hvilken som helst tilgjengelig agent for å kjøre rørledningen eller scenen. En mer spesifikk agent kan erklære at en container skal brukes, for eksempel:

middel {

docker {

image ‘maven: 3-alpine’

etikett ‘min-definert-etikett’

args ‘-v / tmp: / tmp’

    }

}

trinn inneholder en sekvens av ett eller flere scenedirektiver. I eksemplet ovenfor er de tre trinnene Build, Test og Deploy.

trinn gjøre selve arbeidet. I eksemplet over trinnene bare trykte meldinger. Et mer nyttig byggetrinn kan se ut som følger:

rørledning {

agent noen

etapper {

scene (‘Bygg’) {

trinn {

sh 'make'

arkivGjenstander gjenstander: ‘** / target / *. jar’, fingeravtrykk: sant

            }

        }

    }

}

Her påkaller vi oss gjøre fra et skall, og deretter arkivere produserte JAR-filer til Jenkins-arkivet.

De post seksjon definerer handlinger som skal kjøres på slutten av rørledningen eller trinnet. Du kan bruke et antall ettertilstandsblokker i innleggsseksjonen: alltid, endret, feil, suksess, ustabil, og abortert.

For eksempel kjører Jenkinsfilen nedenfor alltid JUnit etter testfasen, men sender bare en e-post hvis rørledningen mislykkes.

rørledning {

agent noen

etapper {

scene (‘Test’) {

trinn {

sh ‘make check’

            }

        }

    }

post {

alltid {

junit ‘** / target / *. xml’

        }

feil {

mail til: [email protected], emne: ‘Rørledningen mislyktes :(‘

        }

    }

}

Den deklarative rørledningen kan uttrykke det meste av det du trenger for å definere rørledninger, og er mye lettere å lære enn den skriptede pipeline-syntaksen, som er en Groovy-basert DSL. Den skriptede rørledningen er faktisk et fullverdig programmeringsmiljø.

Til sammenligning er de følgende to Jenkinsfiles helt likeverdige.

Deklarativ rørledning

rørledning {

agent {docker ‘node: 6.3’}

etapper {

scene (‘build’) {

trinn {

sh ‘npm —versjon’

            }

        }

    }

Skriptet rørledning

node (‘docker’) {

kassen scm

scene (‘Bygg’) {

docker.image (‘node: 6.3’). inne i {

sh ‘npm —versjon’

        }

    }

}

Blue Ocean, Jenkins GUI

Hvis du vil ha den nyeste og beste Jenkins UI, kan du bruke Blue Ocean-plugin-modulen, som gir en grafisk brukeropplevelse. Du kan legge til Blue Ocean-plugin-modulen til din eksisterende Jenkins-installasjon eller kjøre en Jenkins / Blue Ocean Docker-container. Med Blue Ocean installert vil Jenkins-hovedmenyen ha et ekstra ikon:

Du kan åpne Blue Ocean direkte hvis du ønsker det. Den er i / blå-mappen på Jenkins-serveren. Rørledningsskaping i Blue Ocean er litt mer grafisk enn i vanlig Jenkins:

Jenkins Docker

Som jeg nevnte tidligere, distribueres Jenkins også som et Docker-bilde. Det er ikke mye mer i prosessen: Når du har valgt SCM-typen, oppgir du en URL og legitimasjon, og deretter lager du en rørledning fra et enkelt arkiv eller skanner alle lagringsplassene i organisasjonen. Hver gren med en Jenkinsfile vil få en rørledning.

Her kjører jeg et Blue Ocean Docker-bilde, som fulgte med noen flere Git-tjenesteplugg-moduler installert enn standardlisten over SCM-leverandører:

Når du har kjørt noen rørledninger, vil Blue Ocean-plugin-modulen vise statusen, som vist ovenfor. Du kan zoome inn på en enkelt rørledning for å se trinn og trinn:

Du kan også zoome inn på grener (øverst) og aktiviteter (nederst):

Hvorfor bruke Jenkins?

Pluggen-modulen Jenkins Pipeline vi har brukt, støtter en generell tilfelle for kontinuerlig integrering / kontinuerlig levering (CICD), som sannsynligvis er den vanligste bruken av Jenkins. Det er spesielle hensyn for noen andre brukssaker.

Java-prosjekter var den opprinnelige raison d'être for Jenkins. Vi har allerede sett at Jenkins støtter bygging med Maven; det fungerer også med Ant, Gradle, JUnit, Nexus og Artifactory.

Android kjører en slags Java, men introduserer spørsmålet om hvordan man tester på det brede spekteret av Android-enheter. Plugin-modulen til Android-emulatoren lar deg bygge og teste på så mange emulerte enheter som du bryr deg om å definere. Med plugin-modulen Google Play Publisher kan du sende builds til en alfakanal i Google Play for utgivelse eller videre testing på faktiske enheter.

Jeg har vist eksempler der vi spesifiserte en Docker-container som agent for en rørledning, og hvor vi kjørte Jenkins og Blue Ocean i en Docker-container. Docker-containere er veldig nyttige i et Jenkins-miljø for å forbedre hastighet, skalerbarhet og konsistens.

Det er to store brukssaker for Jenkins og GitHub. Den ene er byggeintegrasjon, som kan inkludere en servicekrok for å utløse Jenkins ved hver forpliktelse til GitHub-depotet ditt. Det andre er bruken av GitHub-autentisering for å kontrollere tilgang til Jenkins via OAuth.

Jenkins støtter mange andre språk i tillegg til Java. For C / C ++ er det plugin-moduler for å fange feil og advarsler fra konsollen, generere build-skript med CMake, kjøre enhetstester og utføre statisk kodeanalyse. Jenkins har en rekke integrasjoner med PHP-verktøy.

Selv om Python-kode ikke trenger å bygges (med mindre du for eksempel bruker Cython eller lager et Python-hjul for installasjon), er det nyttig at Jenkins integrerer med Python-test- og rapporteringsverktøy, som Nose2 og Pytest, og kodekvalitet. verktøy som Pylint. På samme måte integreres Jenkins med Ruby-verktøy som Rake, Cucumber, Brakeman og CI :: Reporter.

Jenkins for CI / CD

I det store og hele tilbyr Jenkins en enkel måte å sette opp et CI / CD-miljø for stort sett alle kombinasjoner av språk og kildekodelagre som bruker rørledninger, samt automatisere en rekke andre rutinemessige utviklingsoppgaver. Selv om Jenkins ikke eliminerer behovet for å lage skript for individuelle trinn, gir det deg en raskere og mer robust måte å integrere hele kjeden av bygge-, test- og distribusjonsverktøy enn du enkelt kunne bygge deg selv.

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