whitepaper del 2 - techpeoplejenkins continuous integration server introduktion 2 forudsætninger 3...

Konfiguration af et professionelt open source udviklingsmiljø - Del 2 Jenkins Continuous Integration Server

Introduktion 2

Forudsætninger 3

Installation af Jenkins 3 Introduktion 4 Fremgangsmåde 4

Installation af eksterne programmer 7 Cppcheck 8 cpplint 9 sloccount 9 valgrind 10 gcovr 10 Eclipse 10

Installation af Jenkins plugins 11

Oprettelse af buildjob 12 Build job ‘HelloWorld’ 13

Generering af data grundlag 13 Visualisering af resultat 21

Andet 23

Rundtur i ‘HelloWorld’ og Jenkins brugerfladen 24 Oversigtssiden 24 Live build konsol-output 25 Job oversigt 26 Automatisk start af build 27

Jenkins og branches 28 Branching - Gitflow 28 Branches og Jenkinsfile 28 Multibranch pipeline build og HelloWorld 30

Afsluttende Jenkins-tips 35 Mission Control Plugin 35 Build Monitor Plugin 36

1/40

ThinBackup 36 Job Configuration History 37 Docker understøttelse 37 Cpplint understøttelse 37 Flere Jenkins nodes 37 Blue Ocean brugerflade 37

Afrunding 39

2/40

Introduktion I del 1 blev en lang række funktioner i Jenkins visualiseret. I denne del dykker vi ned bag overfladen og ser på konfigurationen og brugen i et Continuous Integration (CI) scenarie, hvor Jenkins understøtter udviklingen i feature branches. Vi konfigurerer et par build jobs med de støttefunktioner, der blev visualiseret i del 1 (vist nedenfor i reduceret format).

CppCheck, Unit Tests (TAP format) og Code Coverage. SLOCCount (Source lines of code Count), Valgrind analyse

For et Linux system vil vi altså konfigurere Jenkins til at:

● Checke sourckoden med værktøjerne CPPCheck og CPPLint - d.v.s. lave statisk kodeanalyse for at finde basale kodefejl og afvigelser fra kodestandard.

● Afvikle unit-test og visualisere resultatet ● Checke hvor stor en del af koden, der er er dækket af unit test (code coverage) ● Tælle antal kodelinier og visualisere resultatet med gcov. ● Checke de binære med valgrind og visualiserer resultatet. Vi laver kun memory

check (Valgrind indeholder flere værktøjer). Afslutningsvis gives et antal tips til dashboards, distribuerede installationer m.v. Alle disse checks er billige at implementere og de har fanget fejl i alle de projekter, jeg har deltaget i! Som det næsten fremgår af ovenstående beskrivelse består Jenkins understøttelse typisk af to dele:

● brug af et eksternt værktøj som aktiveres af Jenkins

3/40

● visualisering af resultat. Dette sker typisk gennem en Jenkins plug-in, designet til formålet.

Først det praktiske og i den forbindelse en lille disclaimer: Det er et meget stort emne og beskrivelsen i det følgende skal opfattes som en appetizer - selvom den er fuldt funktionel. Jenkins kan meget mere!

Forudsætninger I det følgende beskrives konfigurationen af Jenkins. I den forbindelse hentes kildekode i et git-repository. Det er en forudsætning for eksemplerne at det beskrevne git-repository er tilgængeligt - herunder at der er konfigureret authentication med ssh-keys. Den private nøgle i SSH key-parret skal være tilgængelig i forbindelse med konfigurationen af Jenkins. Hvis man vil etablere en git-server hurtigt kan man bruge er færdigt docker image - f.eks. dette: https://hub.docker.com/r/jkarlos/git-server-docker/, der også tillader authentication med SSH public-private key pairs.

Installation af Jenkins *** BEMÆRK *** Skærmbillederne er lavet i en browser med dansk som hovedsprog. Jenkins brugerflade er derfor overvejende på dansk. Enkelte steder findes den danske oversættelse ikke - derfor falder browseren tilbage til engelsk - derfor lidt sprogforvirring fra tid til anden. Der er 4 måder, hvorpå Jenkins kan blive installeret.

1) Man kan download war-filen på hjemmesiden: https://jenkins.io/download/. Fordele er, at man har fuld kontrol over installationen og kan genetablere den senere og man kan få den nyeste version (i modsætning til så mange andre værktøjer har jenkins-community VIRKELIG styr på afhængigheder og kvalitet, og jeg har faktisk aldrig oplevet problemer med de nyeste versioner)

2) Man kan installere den gennem den package manager, der følger med den Linux distro, der skal benyttes (Jenkins er java baseret og kører også på Windows, men det er ikke i scope for dette dokument). Fordelen er at man får en velintegreret installation. Til gengæld er det ikke den nyeste. I praksis spiller det sjældent en rolle.

3) Man kan installere et færdigt image i en cloud løsning. Fordelen er, at man er hurtigt oppe og køre. Til gengæld slæber man alt muligt med ind i sin installation. Det vil nok oftest heller ikke være nyeste udgave.

4) Man kan benytte det “officielle” docker image vedligeholdt af Jenkins community. Docker er en container teknologi med lidt af de samme karakteristika som en virtuel maskine - bare meget hurtigere og mindre resourcekrævende - se Wipedia. Med Docker er er man lynhurtigt oppe og køre og har en meget ny version. Ulempen er igen at det ikke er gennemskueligt, hvordan den etableres, hvilket kan være et problem i regulerede miljøer (f.eks. medical device udvikling). Jenkins community vedligeholder to docker images som beskrevet her:

4/40

https://hub.docker.com/r/jenkins/jenkins/. Selve brugen er beskrivet på Github her:https://github.com/jenkinsci/docker/blob/master/README.md

Her vil vi benytte den sidstnævnte version og benytte et af de autoriserede docker images - nemlig jenkins lts (long term support).

Introduktion I det følgende beskrives fremgangsmåden på en Linux maskine med ‘Opensuse Tumbleweed’ installeret. Fremgangsmåden er givetvis den samme på andre Linux distributioner og under alle omstændigheder forudsættes det at docker er funktionel på på en Linux maskine (skriv evt. kommandoen ‘docker version’ i en konsol for at afklare det). Nedenstående er et sammenkog af brugen.

Fremgangsmåde 1. Start en konsol og skriv ‘docker pull jenkins/jenkins:lts’. Dette vil downloade docker

billedet til maskinen.

Screen dump et lille stykke inde i download processen af docker image ‘jenkins:lts’

2. Skift til linux brugerens ‘HOME’ folder ved at skrive ‘cd +<Enter>. Lav folderen ‘jenkins_home’ ved at køre kommandoen ‘mkdir jenkins_home +<Enter>’

3. Start det nyligt downloadede image med kommandoen: ‘docker run -p 8080:8080 -p 50000:50000 -v $HOME/jenkins_home:/var/jenkins_home jenkins/jenkins:lts’

4. Jenkins er nu tilgængelig på port 8080 på maskinen som vist:

5/40

Start siden for Jenkins i en browser.

Når man starter en docker container med et image er alt i docker containeren som udgangspunkt ‘read-only’. Ved genstart af container er alt altså nulstillet. Der laves der som regel en forbindelse ud af docker containeren til host maskinen. I ovenstående kommando angiver ‘-v $HOME/jenkins_home:/var/jenkins_home’ at folderen ‘/var/jenkins_home’ INDE I docker containeren skal mappes over til ‘$HOME/jenkins_home’ UDENFOR docker containeren. Ting placeret i ‘$HOME/jenkins_home’ vil altså overleve genstarter og heldigvis vil det omfatte konfiguration af build jobs og plug-ins. Konfigurationen af selve Jenkins vil derfor ikke blive slettet ved en genstart. Efter start af Jenkins docker containeren der Jenkins nu tilgængelig i en browser på port 8080. Den viste sti ‘/var/jenkins_home/secrets/initialAdminPassword’ refererer til en sti inde i docker containeren men da ‘/var/jenkins_home’ inde i containeren er mappet til ‘$HOME/jenkins_home’ udenfor kan vi simpelt køre kommandoen ‘cat ~/jenkins_home/secrets/initialAdminPassword’ for at få adgang til det initielle administrator password..

6/40

Listning af jenkins secret ved første start Administrator password er simpelt pastet ind i password feltet.

Ved klik på ‘Continue’ vises billedet til installation af plug-ins. Klik bare ‘Install suggested plug-ins’. Som med alt andet i Jenkins er det virkelig gennemtænkt. Herefter går Jenkins i gang med at installere plug-ins.

Installation af plugins. Vælg ‘Install suggested plugins’

Jenkins installation af plug-ins.

Indtast den første bruger og jenkins er klar til brug.

7/40

Oprettelse af første bruger Klar til brug

Nu til installation af de nødvendige eksterne værktøjer.

Installation af eksterne programmer Nu har vi jo valgt at køre Jenkins i et docker image, der jo er read-only. Det betyder at alle programmer vi installerer vil forsvinde næste gang vi genstarter docker containeren. Normalt vil man lave en custom docker container v.h.a. en dockerfile til formålet, men det ligger uden for scopet af dette dokument (hvis man googler på custom jenkins docker image er der masser er relevante hits). I det følgende vil vi installere programmerne midlertidigt, men de samme kommandoer kan sagtens føjes ind i en Dockerfile, og så er man kommet et godt skridt af vejen. For at installere programmerne inde i docker containeren skal vi kende dens ID. Dette findes ved at skrive kommandoen ‘sudo docker ps’ i en terminal og aflæse ID’et som vist nedenfor.

Identifikation af ID’et for en docker container.

ID’et vil blive brugt i de følgende afsnit med referencen <DOCKER ID>.

8/40

I de følgende afsnit starter vi hver installation med at gå ind i docker containeren og afslutter ved at gå ud igen. Det behøves naturligvis ikke, hvis man foretager installationerne samlet.

Cppcheck Cppcheck er et værktøj, der kan udføre statisk kodeanalyse på sourcekoden. Projektet hostes på Sourceforge her: http://cppcheck.sourceforge.net/ Der er tale om et værktøj, der lave en MEGET grundig analyse af koden, og derfor er det godt at få det ind fra starten, så udviklerne får rettet op på findings løbende. Projektet er meget aktivt og der kommer en ny release ca. hver tredie måned. Man kan enten downloade og bygge værktøjet selv, hvis man vil have ‘latest and greatest’. Alternativt kan man installere den version, der normalt er i den linux distro, man benytter. Vi vælger den sidste og installere den version vores Jenkins docker image understøtter - altså den version, der er understøttet af den linux distro, der er benyttet til at lave vores Jenkins docker image. Gør som følger:

● Skriv følgende konsolkommando for at starte en konsolsession inde i docker containeren: sudo docker exec -it -u root <DOCKER ID> bash.

Start af en konsolsession inde i docker containeren. Bemærk at prompten ændres til ‘root@<DOCKER ID>

● Skriv nu kommandoen ‘apt-get update’. Hermed opdateres listen af tilgængelige pakker.

Opdatering af pakkelisten. Det ses at docker billedet er baseret på Debian stretch.

● Skriv nu ‘apt-get install cppcheck’ og bekræft installationen (tryk <Enter>). Cppcheck bliver nu installeret. Skriv ‘cppcheck --version’ for at bekræfte installationen.

Det ses at vi får version 1.76 af cppcheck installeret. I skrivende stund er den

9/40

nyeste version 1.82 og er 1½ år nyere.

● Skriv ‘exit’ for at forlade docker containeren.

Ved at skrive ‘exit’ forlades docker containeren.

cpplint Cpplint er et python script oprindeligt udviklet af Google for at checke for compliance med deres kodestandard. Projektet hostes her: https://github.com/cpplint/cpplint Man behøver kun at downloade filen ‘cpplint.py’ og man kan evt tilrette scriptet til egne behov. En hurtig søgning på ‘cpplint.py’ giver masser af eksempler. Gør som følger:


● Skriv følgende kommando inde i docker containeren: ‘wget https://github.com/cpplint/cpplint/blob/master/cpplint.py’. Herefter downloades ‘cpplint.py’ som vist.

Download af ‘cpplint.py’ (konsollen er forvrænget idet det første ‘.py’ skulle stå til sidst på linie 1 - copy/paste fænomen).


sloccount sloccount er et værktøj, der kan tælle antallet af sourcekodelinier for et utal af sprog. Programmet har hjemme her: https://sourceforge.net/projects/sloccount/ Gør som følger:


● Skriv følgende kommando inde i docker containeren: ‘apt-get install sloccount’, sloccount bliver nu installeret.

10/40


valgrind Valgrind er et værktøj, der kan analysere en applikations dynamiske opførsel - bl.a. memory management og threading. Projektet holder til her: http://valgrind.org/ Gør som følger:


● Skriv følgende kommando inde i docker containeren: ‘apt-get install valgrind’. Bekræft og valgrind bliver installeret.


gcovr ‘gcovr’ er et værktøj, der kan efterbehandle resultatet af gcov profiling og producere coverage rapporter. Værktøjet har hjemme her: https://gcovr.com/ Vi vælger den nemme løsning og installere vis python pip-værktøjet, der dog først skal installeres. Gør som følger:


● Skriv følgende kommando inde i docker containeren: ‘apt-get install python-pip’ og bekræft. Herefter installeres pip fra python verdenen.

● Skriv nu ‘pip install gcovr’. pip installerer nu gcovr.

Installation af gcovr via pip.


Eclipse Vi skal bruge eclipse til at bygge projektet. Eclipse skal derfor også installeres. Gør som følger:


● Skriv følgende kommando inde i docker containeren: ‘wget http://mirror.dkm.cz/eclipse/technology/epp/downloads/release/oxygen/3a/eclipse-cpp-oxygen-3a-linux-gtk-x86_64.tar.gz’ og bekræft. Eclipse downloades nu.

11/40

● Skriv følgende kommando for at pakke Eclipse ud og bekræft: ‘tar -xvzf eclipse-cpp-oxygen-3a-linux-gtk-x86_64.tar.gz’’

● Skriv ‘exit’ for at forlade docker containeren. Eclipse er nu installeret i ‘/eclipse’ inde i docker containeren.

Installation af Jenkins plugins Med de eksterne værktøjer installerede i forrige kapitel kan vi nu fortsætte med konfigurationen af Jenkins.

Først skal vi have installeret et antal plug-ins. Gør som følger:

● Skift til en browser og skriv ‘localhost:8080’. Log evt. ind med den bruger, der blev oprettet under konfiguration af Jenkins ovenfor.

● Klik på linket ‘Bestyr Jenkins’ og derefter ‘Pluginhåndtering’

Indgangen til Jenkins konfigurationen. Indgang til pluginhåndteringen

● Vælg fanen ‘Tilgængelige’ og marker tilføjelserne ‘cppcheck’, ‘valgrind’, ‘cobertura’, ‘sloccount’, ‘xunit’ og ‘warnings’. Klik på knappen ‘Installer uden genstart’

12/40

Plugin bestyrer - tilgængelige plugins. Selve installationen aktiveres med knappen ‘Installer uden genstart’

● Jenkins installerer nu de valgte plugins. Efter endt installation vend tilbage til forsiden via linket øverst til venstre.

Installationen af plugins er aktiv Link til forsiden.

Vi er nu klar til at konfigurere det første job.

Oprettelse af buildjob Med Jenkins installationen på plads kan vi nu oprette det første buildjob. Vi startet med de grundlæggende konfigurationer og til sidst gennemgår vi slutresultatet.

13/40

Build job ‘HelloWorld’ Vi vil gerne bygge projektet HelloWorld hver gang ny source-kode bliver checket ind i git. Derudover vil vi gerne have udført statisk kodeanalyse, unit tests og memory check med værktøjerne beskrevet ovenfor. Sidst men ikke mindst vil vi have et sloc-count samt code-coverage score for vores unit tests. Først skal vi generere data-grundlaget og derefter skal vi visualisere resultatet.

Generering af data grundlag Gør følgende i Jenkins:

● Klik på linket ‘Opret nyt job’ fra oversigtssiden i Jenkins.

Oprettelse af nyt job.

● Indtast navnet ‘HelloWorld’ og vælg typen ‘Byg et Freestyle projekt’. Klik på knappen ‘Ok’ for at konfigurere.

Oprettelsen af frestyle jobbet ‘HelloWorld’

14/40

● Skriv en beskrivelse af build’et som vist og vælg ‘git’ som kildekodestyring (SCM). Skriv adressen på git-repositoriet i ‘Repository URL’. Jenkins viser en fejl med rødt - den vender vi tilbage til om et øjeblik.

Første trin i oprettelsen af build-job. Beskrivelse og valg af scm system.

● Klik på knappen ‘Add’ for at oprette et login. Vælg typen ‘SSH Username with a private key’. Indtast det brugernavn der skal associeres med nøglen (f.eks. developer). Kopier den private nøgle ind i ‘Key’-feltet som vist. Klik dernæst ‘Add’ i bunden af vinduet (ikke synligt i figuren nedenfor).

15/40

Knap til oprettelse af nyt login. Oprettelse af et SSH login baseret på et public private key-pair. Public key delen er registreret hos git-serveren. Private key’en registreres i Jenkins - f.eks. som vist her.

● Vælg at branchen ‘develop’ skal bygges (HUSK)

Valg af branchen ‘develop’.

● Et nyt build kan trigges af forskellige omstændigheder. Vi vil have Jenkins til at polle git regelmæssigt, og såfremt, der er ændringer, skal et byg startes. Marker derfor check-boksen ‘Poll kildekodestyringen’ og indtast masken ‘* * * * *’ for ‘check én gang i minuttet’.

16/40

Konfiguration af polling af git-repository én gang i minuttet og såfremt der er sket ændringer, skal et nyt byg startes.

● Klik ‘Gem’ og gå til oversigtssiden. Her ses nu build-jobbet ‘HelloWorld’.

Oversigtssiden i Jenkins efter oprettelse af jobbet ‘HelloWorld’.

● Tryk på knappen til højre for at starte et build. Efter endt build ses i søjlen ‘Seneste succes’ build #1. Den blå cirkel indikerer pudsigt nok ‘Succes’ .

17/40

Manuelt start af build Status efter første succesfulde build. Blåt er tegn på succes.

● Vi skal nu fylde substans i byggejobbet (indtil videre hentes kun sourcekode ud). Klik på linket ‘HelloWorld’ i oversigten og vælg ‘Konfigurer’. Vi er nu tilbage i konfigurationsvinduet.

Link til build job konfiguration Konfigurationslink

● Klik på fanen ‘Byg’, klik på knappen ‘Tilføj byggetrin’ og vælg ‘kør skalkommando’.

18/40

Oprettelse af byggetrin - kørsel af skal kommando (shell script)

● Skriv følgende i kommandofeltet: /eclipse/eclipse --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -importAll $WORKSPACE -data $WORKSPACE -cleanBuild HelloWorld/Debug Med denne kommando starter vi Eclipse i et ‘headless mode’ (uden brugerflade), importerer alle projekter i folderen $WORKSPACE og bygger projektet HelloWorld i debug konfiguration. Se flere kommandolinieargumenter her: https://gnu-mcu-eclipse.github.io/advanced/headless-builds/. Har man brugt cmake eller make kan man naturligvis bare erstatte kaldet til Eclipse med de tilsvarende kommandoer.

● Tilføj endnu et byggetrin af typen ‘skalkommando’ som ovenfor. Sæt kommandoen til: sloccount --duplicates --wide --details $WORKSPACE > sloccount.sc Vi aktiverer altså sloccount og gemmer resultatet i filen ‘sloccount.sc’

19/40

2 byggetrin - det første kompilerer med eclipse, det andet kører sloccount værktøjet.

● Tilføj endnu et byggetrin af typen ‘skalkommando’ som ovenfor. Sæt kommandoen til: cppcheck --xml --std=c++11 --enable=all $WORKSPACE 2> cppcheck.xml Vi aktiverer her cppcheck og gemmer resultatet i filen ‘cppcheck.txt’

● Tilføj endnu et byggetrin af typen ‘skalkommando’ som ovenfor. Sæt kommandofeltet til: /eclipse/eclipse --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data $WORKSPACE -cleanBuild HelloWorldUnitTest/Debug ./HelloWorldUnitTest/Debug/HelloWorldUnitTest -r junit 1> unitTestResult.xml Med disse kommandoer aktiverer vi først Eclipse i ‘headless’ mode og bygger debug konfigurationen af unittest programmet ‘HelloWorldUnitTest’. Dernæst køres ‘HelloWorldUnitTest’ og resultatet af unit-testen gemmes i junit-formatet i filen ‘unitTestResult.xml’

● Da vi naturligvis har bygget ‘HelloWorldUnitTest’ med gcov profiling (flag -ftest-coverage -fprofile-arcs) har kørslen af ‘HelloWorldUnitTest’ i forrige step genereret gcov profiling filer (gcda og gcno - filer). Disse skal behandles med ‘gcovr’ for at kunne visualisere codecoverage. Tilføj derfor endnu et byggetrin af typen ‘skalkommando’ som ovenfor. Sæt kommandofeltet til: gcovr --root=$WORKSPACE/HelloWorldUnitTest --xml 1>codeCoverage.xml Med denne kommando processerer vi gcov filerne og gemmer resulatet i ‘codeCoverage.xml’

20/40

Byggetrin til cppcheck, unit test og code coverage.

● Det sidste vi mangler der memory check med Valgrind. Det er normalt, at outputtet skal filtreres (suppressions). Disse filtre kan man få Valgrind til at generere i et separat mode. Vi laver derfor to kørsler med Valgrind. I den første genererer vi mulige nye suppressions - i den anden laver vi selve checket. Såfremt der er behov for at lægge nye filtre ind, har vi dermed allerede input. Lav derfor et nyt byggetrin af typen ‘skalkommando’ som ovenfor. Sæt kommandofeltet til: valgrind --leak-check=full --gen-suppressions=all HelloWorldUnitTest/Debug/HelloWorldUnitTest > VALGRIND_new_suppressions_HelloWorldUnitTest.txt 2>&1 valgrind --xml=yes --xml-file=VALGRIND_HelloWorldUnitTest.xml HelloWorldUnitTest/Debug/HelloWorldUnitTest Vi gemmer altså mulige suppressions i filen ‘VALGRIND_new_suppressions_HelloWorldUnitTest.txt’ og resultatet af selve memory profilingen i filen ‘VALGRIND_HelloWorldUnitTest.xml’

21/40

Visualisering af resultat Når byggetrinnene i forrige afsnit er blevet gennemført er der produceret et antal filer med resultater, der skal visualiseres. Gør som følger:

● Først SLOCCount: Klik ‘Add post-build-action’ og vælg ‘Publish SLOCCount analysis result’. Sæt ‘SLOCCOUNT reports’ til ‘sloccount.sc’ og klik ‘Apply’.

Tilføjelse af ‘Post build action’

Valg af sloccount resultater Identifikation af fil med resultater.

● Dernæst CPPCheck. Klik igen ‘Add post-build-action’ og vælg ‘Publish CPPCheck results’. Sæt ‘Cppcheck report XMLs‘ til ‘cppcheck.txt’. Klik på og klik ‘Apply’ (figuren nedenfor viser konfigurationen i ‘Advanced’ mode)..

22/40

Cppcheck konfiguration efter klike på knappen ‘Advanced’. Bemærk at man kan sætte grænseværdier op for, hvornår buildet skal fejle (røde kugler) og advare (gule kugler).

● Så kommer unit test. Klik igen ‘Add post-build-action’ og vælg ‘Publicer JUnit Test Report’. Sæt ‘Test Rapport XML filer’ til ‘unitTestResult.xml’. Klik ‘Apply’.

● Code coverage ligner de øvrige. Klik igen ‘Add post-build-action’ og vælg ‘Publish Cobertura Coverage Report’. Sæt ‘Cobertura xml report pattern’ til ‘codeCoverage.xml’ og klik ‘Apply (figuren nedenfor viser opsætning i ‘Advanced mode’).

23/40

Cobertura coverage rapport efter tryk på ‘Advanced’. Bemærk at der kan opsættes grænseværdier op, der påvirker ‘vejret’ for build-jobbet (se afsnittet nedenfor om oversigtsvinduet)

● Sidst men ikke mindst skal vi have Valgrind rapporten ind. Klik igen ‘Add post-build-action’ og vælg ‘Publish Valgrind Results’. Sæt ‘Report pattern’ til ‘VALGRIND_HelloWorldUnitTest.xml’ og klik ‘Apply.

Andet Vi vil også gerne gemme den binære ‘HelloWorld’ applikation. Derfor tilføjes endnu et step:

24/40

● Klik igen ‘Add post-build-action’ og vælg ‘Arkiver Artifakterne’. Sæt ‘Filer der skal arkiveres til ‘**/HelloWorld, **/*.xml’ og klik ‘Apply’

Vi har nu afsluttet den grundlæggende konfiguration. Tryk på ‘Gem’ og Jenkins returnerer til oversigtssiden.

Oversigtsbilledet i Jenkins efter konfiguration af HelloWorld build-job.

Rundtur i ‘HelloWorld’ og Jenkins brugerfladen I denne sektion går vi hurtigt igennem brugerfladen i Jenkins og beskriver, hvordan HelloWorld - jobbet bliver håndteret.

Oversigtssiden I højre side ses listen over alle konfigurerede build-jobs. Man ser for hvert build-job seneste status, trend over de seneste builds, build nummer for seneste succesfulde- og fejlede builds, længden af et build samt en knap til at starte build’et.

Build status (blå = succes)

Trend (vejrudsigt) Build 44 lykkedes for 27 minutter siden.

Ingen builds har fejlet

Længden af et build

Start nyt build

25/40

Tryk på knappen ‘Start nyt build’ for at starte et nyt build. I venstre side ses status for ‘jobafviklere’, hvor det nye build starter. Trykkes der igen på knappen ‘Start nyt build’ mens et build af det pågældende job er i gang, bliver det nye build sat i kø.

Efter klik på ‘Start nyt build’ dukker build 45 op i status med en progress bar. Holdes musen hen over progress ses forventede tider. Rødt kryds afbryder build’et.

Et job kan kun være i gang én gang. Yderligere aktivering bliver sat i kø.

Klik på ‘progress baren’ for et igangværende build fører til et live-feed af konsol-output.

Live build konsol-output

26/40

Live konsol-output for et igangværende build.

Tryk på ordet ‘Jenkins’ i øverste venstre hjørne for at komme tilbage til oversigten. Klik på et job-navn for at komme ind i oversigten for det pågældende job.

Job oversigt Vi ser de checks, vi konfigurerede i de foregående afsnit og de samme elementer som i kapitel 1.

Oversigten over jobbet ‘HelloWorld’. Følgende områder ses fra venstre mod højre, oppefra og ned:

● Navigations/kommandolinks (f.eks. ‘Byg Nu’) ● Byggehistorik med status, build-nummer og tidsstempel (f.eks blå, build 48) ● Download Links til byggeartifakter (f.eks. codeCoverage.xml på 402.20 kb) ● Metriktabeller (f.eks CppCheck results) ● Trend grafer (f.eks CppCheck trend).

27/40

Automatisk start af build Ifm konfigurationen af ‘HelloWorld’ konfigurerede vi, at Jenkins skulle check git hvert minut efter ændringer. Det vil vi nu afprøve. Vi laver derfor en ændring i HelloWorld og committer den til git.

Ændring i HelloWorld foretaget af ‘tar’ med commit message.

Vi venter nu i Jenkins…og indenfor et minut bliver et nyt byggejob lagt i kø og starter kort efter.

Nyt byg er lagt i kø.. .. og startes

Klik på buildnummeret i oversigten (#49 i figuren) for at se detaljer. Vi kan se at det nye build er udløst af en SCM ændring (=Source Control Management ændring = git) og vi kan se commit kommentaren.

28/40

Klik på buildnummer for at se detaljer Detaljerne for buildet.

Klik på ‘detail’ ud for commit kommentaren. Vi kan nu se at det er filen ‘main.cpp’ der har ændret sig og at det er ‘tar’, der har gjort det.

Jenkins og branches

Branching - Gitflow Det er normalt udvikle nye funktioner i separate grene af kildekoden (feature branches) og merge ind i en fælles kodebase, når featuren er afsluttet. Et meget udbredt paradigme er ‘Gitflow’ - se her: http://nvie.com/posts/a-successful-git-branching-model/ I gitflow hedder den fælles kodebase ‘develop’. Hver gang en ny feature påbegyndes laves en ny gren af sourcekoden, hvor alt arbejdet foregår. Efter endt udvikling merges feature branchen tilbage i ‘develop’ og arbejdet konsolideres. Da vi konfigurerede ‘HelloWorld’ valgte vi, at branchen ‘develop’ skulle bygges. Vores buildjob vedrører altså kun denne branch. Det ville jo være rart, hvis unittest, cppcheck, valgrind-check m.v. også blev foretaget på de enkelte feature branche, så man fik kvalitetssikret koden INDEN merge med develop. Det kan man heldigvis med Jenkins og løsningen hedder ‘Multibranch Pipeline Builds’

Branches og Jenkinsfile I et multibranch pipeline build kloner Jenkins automatisk job-konfigurationen for hver branch i SCM. Når det først er konfigureret er der ingen omkostninger ved feature branches og man får alle kvalitetsaktiviteter hele tiden (YES!).

29/40

Jobkonfigurationen skal ligge beskrevet i en tekst-fil med navnet ‘Jenkinsfile’ i roden af repositoriet.

Jenkinsfile placeret i roden af Eclipse workspace som er sammenfaldende med roden af git-repo.

Jenkins filen skal overholde en pipeline syntax som beskrevet her https://jenkins.io/doc/book/pipeline/syntax/. Man kan lave stort set alt i en Jenkinsfile - herunder alt det vi så i den grafiske konfiguration af ‘HelloWorld’. Nedenfor vises indholdet af en reduceret Jenkinsfile, der:

● Kører cppcheck på koden og laver rapporten ● Bygger ‘HelloWorld’ ● Arkiverer Helloworld + all xml-filer. ● Laver sloccount og publicerer resultatet ● Bygger HelloWorldUnitTest, kører programmet og publicerer resultatet.

pipeline { agent any options { disableConcurrentBuilds() } stages { stage('Static Code Analysis') { steps { sh 'cppcheck --template="{file},{line},{severity},{id},{message}" --std=c++11 --enable=all $WORKSPACE 2> cppcheck.txt' step([$class: 'WarningsPublisher', canComputeNew: false, canresolverelativepaths: false, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', messagesPattern: '', parserConfigurations: [[parserName: 'cppcheck', pattern: 'cppcheck.txt']], unHealthy: '']) } } stage ('Building'){ steps { sh "/eclipse/eclipse --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -importAll $WORKSPACE -data $WORKSPACE -cleanBuild HelloWorld/Debug > build.log 2>&1" archiveArtifacts artifacts: '**/HelloWorld, **/*.xml', fingerprint: true sh 'sloccount --wide --details $WORKSPACE/HelloWorldUnitTest/HelloWorld > sloccount.sc' sloccountPublish encoding: '', pattern: 'sloccount.sc' }

30/40

} stage('Testing') { steps { sh "/eclipse/eclipse --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data $WORKSPACE -cleanBuild HelloWorldUnitTest/Debug" sh "./HelloWorldUnitTest/Debug/HelloWorldUnitTest -r junit 1> unitTestResult.xml" step([$class: 'XUnitBuilder',thresholds: [[$class: 'SkippedThreshold', failureThreshold: '0'],[$class: 'FailedThreshold', failureThreshold: '0']], tools: [[$class: 'JUnitType', pattern: 'unitTestResult.xml']]]) } } } post { failure { sh "echo Noget gik galt. Jenkins kan sende en mail eller slack besked" } } }

Jenkinsfile, der bygger HelloWorld m.m.

Efter at have committet en Jenkinsfile til demo_workspace.git som beskrevet ovenfor konfigurerer vi nu et nyt Multibranch pipeline job

Multibranch pipeline build og HelloWorld Gør som følger:

● Klik på linket ‘Nyt Item’. Inddtast et navn og vælg typen Multibranch Pipeline. Klik Ok.

31/40

Link ‘Nyt Item’ Oprettelse af ‘Multibranch Pipeline’ for ‘HelloWorld’.

● Indtast de samme git-credentials som for ‘HelloWorld’ i sektionen ‘Branch Sources’.

Sæt hak i ‘Periodically if not otherwise run’ og sæt perioden til 1 minut. Klik ‘Save’

32/40

Konfigurationen af et Multibranch pipeline job for ‘HelloWorld’. Øverst ses git-konfigurationen, der er mage til den simple ‘HelloWorld konfiguration Dernæst ses det at branches bliver ‘opdaget’. Det er en Jenkinsfile, der styrer build’et Jenkins scanner git en gang i minuttet for at opdage ændringer.

I oversigten er der nu dukket et nyt job op. Klikker man på navnet se at det faktisk er en mappe med jobs inden i. Vi ser den eneste branch der p.t. findes - nemlig ‘develop’.

33/40

Nyt multibranch pipeline job. Indholdet af HelloWorldMultibranchPipeline

Trigger man et nyt byg med linket til højre startes et nyt build af branchen ‘develop’.

By af branchen ‘develop’ i pipeline buildet

Efter endt by skinner solen nu over ‘develop’.

Klikkes på branchen ‘develop’ ses en status for branchen som vist nedenfor (der er kørt et par builds).

Oversigt over branchen ‘develop’. Vi ser det, der var konfigureret i vores Jenkinsfile: Build og arkivering af ‘HelloWorld’,Cppcheck resultat, Sloccount, Unit test resultater (ingen fejlede - derfor vises ingen resultater) og artifakter. Vi ser også en oversigt over pipeline’ns faser med tidsforbrug

34/40

Vi opretter nu en ny feature branch i git og laver nogle ændringer.

Aktivering af ny feature i gitflow.

35/40

Navn ‘ny_feature Ændring i feature branch med commit message.

Efter commit åbner vi multibranch pipeline jobbet i Jenkins og venter - og minsandten om der ikke dukker en ny branch op indenfor et minut. Buildet starter og åbnes branch status ses en tro kopi af det, vi så for branchen ‘develop’.

Ny branch detekteret multibranch pipeline

Oversigt for den nye feature branch.

Alle QA aktiviteter kan altså ske i feature branchen, hvilket reducerer støjen, når der merges tilbage (især, hvis man forinden har merget ‘develop’ ind i featurebranchen - så er der nærmest ingen undskyldning for at breake build’et).

Afsluttende Jenkins-tips Der er hundredvis af plug-ins til Jenkins. Her nævnes nogle enkelte, der kan være meget nyttige.

Mission Control Plugin Denne plugin giver en visuel oversigt, der egner sig til et dashboard i et kontormilø.

36/40

Eksembel på mission control dashboard på en labtop

Build Monitor Plugin Denne plugin giver også en fin oversigt over kritiske jobs. Den kan bruges tom ‘build-light’.

Build-monitor status på en labtop-skærm.

ThinBackup Denne plugin kan lave backup/restore af Jenkins opsætningen.

37/40

Job Configuration History Denne plug-in holder øje med ændringer i opsætningen af de enkelte jobs. Man kan se, hvad der er ændret og hvem, der har gjort det. Man kan også rulle frem og tilbage mellem versioner - en virkelig store hjælp i et miljø, hvor man vil have styr på konfigurationerne!

Docker understøttelse Jenkins understøtter docker images i mange sammenhænge. Eksempelvis kan hvert enkelt step i Jenkinsfilen udføres i sin egen docker container. Det betyder igen at et byggemiljø i en docker container lynhurtigt kan spredes til et antal Jenkins servere. Der findes et hav a plug-ins, der bidrager - f.eks CloudBees Docker Build and Publish, docker-build-step

Cpplint understøttelse Der er lavet et hav a hacks for at benytte eksisterende plug-ins til nye formål. Et eksempel kan ses ved at følge dette link: https://stackoverflow.com/questions/14172232/how-to-make-cpplint-work-with-jenkins-warnings-plugin

- hvor et Python script bliver brugt til at konvertere output fra cpplint til et format, der kan forståes af cppcheck-plugin’en.

Flere Jenkins nodes Man kan nemt fordele sine jobs på flere maskiner. Man installerer ikke Jenkins på hver enkelt slave maskine, men starteren simpel java-klient, der forbinder sig til Jenkins master maskinen. Jenkins kan så ‘commande’ java klienten til at udføre build-jobs. Det er en forudsætning at build-værktøjerne er installerede på slave maskinerne (docker kunne være en hjælp her). Der kan være mange grunde til at ville have flere Jenkins nodes:

● Forskellige byggejobs skal afvikles på forskellige operativsystemer (Jenkins er java baseret).

● Parallelisering af builds ● Forskellige Jenkins-instanser til forskellige opgaver - f.eks. en cloud-hostet ‘master’-

Jenkins og flere lokale Jenkins servere til at afvikle system-, komponent- og integration-tests mod target devices.

Blue Ocean brugerflade I de forrige afsnit så vi den traditionelle Jenkins brugerflade. Der er gang i et større projekt med at lave en ny brugerflade ‘Blue Ocean’ fra bunden. Der er et antal Blue Ocean plug-ins tilgængelige.

38/40

Visualisering af projekterne fra forrige afsnit i Blue Ocean

Aktiviteter i vores Multibranch pipeline build i Blue Ocean

39/40

Visualisering af et enkelt pipeline build visualiseret i Blue Ocean.

Afrunding Jenkins og CI-pipelines generelt er et meget stort emne, og vi har kun berørt en lille del. Jenkins som værktøj er utroligt fleksibelt på grund af det store antal plug-ins og brugssituationerne er utallige. Jeg har brugt Jenkins:

● som ren build-server, hvor configuration management dimensionen blev brugt til at skabe fuld sporbarhed fra kode til binær - på alle niveauer.

● afvikling af unit tests på selve build-serveren. ● afvikling af komponent tests i taget. ● afvikling af psudo - system tests på build serveren (binære bygget til x86 men med

samme kodebase som til et arm-target. Det eneste ærgelige ved Jenkins er, at den (som alle andre open source projekter) ikke har en stor marketingsafdeling til at fremhæve dens fortræffeligheder og at alle de funktioner, der er tilgængelige i dag, samt fremtidige forbedringer har krævet/kræver, at en med forståelse for problemet og evnerne og tiden til at løse det (evt. sponsoreret) laver en udvidelse, der gør tilværelsen bedre for alle. Det er de mekanismer, der har skabt det super-værktøj, man kvit og frit kan installere i dag. Jenkins er derfor som produkt et forbillede på, hvordan produkter skal udvikles og designes.

whitepaper del 2 - techpeoplejenkins continuous integration server introduktion 2 forudsætninger 3...

Documents