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

Transkript

1 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

2 ThinBackup 36 Job Configuration History 37 Docker understøttelse 37 Cpplint understøttelse 37 Flere Jenkins nodes 37 Blue Ocean brugerflade 37 Afrunding 39 1/40

3 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 2/40

4 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: 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: 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 jenkinscommunity 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: 3/40

5 Selve brugen er beskrivet på Github her: 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: v $HOME/jenkins_home:/var/jenkins_home jenkins/jenkins:lts 4. Jenkins er nu tilgængelig på port 8080 på maskinen som vist: 4/40

6 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 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.. 5/40

7 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. 6/40

8 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>. 7/40

9 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: 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 8/40

10 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: 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 konsolkommando for at starte en konsolsession inde i docker containeren: sudo docker exec -it -u root <DOCKER ID> bash. Skriv følgende kommando inde i docker containeren: wget 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). Skriv exit for at forlade docker containeren. sloccount sloccount er et værktøj, der kan tælle antallet af sourcekodelinier for et utal af sprog. Programmet har hjemme her: 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. Skriv følgende kommando inde i docker containeren: apt-get install sloccount, sloccount bliver nu installeret. 9/40

11 Skriv exit for at forlade docker containeren. 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: 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. Skriv følgende kommando inde i docker containeren: apt-get install valgrind. Bekræft og valgrind bliver installeret. Skriv exit for at forlade docker containeren. gcovr gcovr er et værktøj, der kan efterbehandle resultatet af gcov profiling og producere coverage rapporter. Værktøjet har hjemme her: 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 konsolkommando for at starte en konsolsession inde i docker containeren: sudo docker exec -it -u root <DOCKER ID> bash. 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. Skriv exit for at forlade docker containeren. Eclipse Vi skal bruge eclipse til at bygge projektet. Eclipse skal derfor også installeres. 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. Skriv følgende kommando inde i docker containeren: wget og bekræft. Eclipse downloades nu. 10/40

12 Skriv følgende kommando for at pakke Eclipse ud og bekræft: tar -xvzf eclipse-cppoxygen-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 11/40

13 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. 12/40

14 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 codecoverage 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 13/40

15 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). 14/40

16 Knap til oprettelse af nyt login. Vælg at branchen develop skal bygges (HUSK) 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. 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. 15/40

17 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. 16/40

18 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. 17/40

19 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: 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 18/40

20 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 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 -ftestcoverage -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 19/40

21 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 20/40

22 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).. 21/40

23 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 ). 22/40

24 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-buildaction 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: 23/40

25 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 24/40

26 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 25/40

27 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å kb) Metriktabeller (f.eks CppCheck results) Trend grafer (f.eks CppCheck trend). 26/40

28 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. 27/40

29 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: 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!). 28/40

30 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 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 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' } 29/40

31 } 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. 30/40

32 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 31/40

33 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. 32/40

34 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 33/40

35 Vi opretter nu en ny feature branch i git og laver nogle ændringer. Aktivering af ny feature i gitflow. 34/40

36 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ø. 35/40

37 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. 36/40

38 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: - 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. 37/40

39 Visualisering af projekterne fra forrige afsnit i Blue Ocean Aktiviteter i vores Multibranch pipeline build i Blue Ocean 38/40

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 superværktøj, man kvit og frit kan installere i dag. Jenkins er derfor som produkt et forbillede på, hvordan produkter skal udvikles og designes. 39/40