Jenkins er et system for å automatisere deler av deployering, bygging, integrasjonstesting, med mer. Det er stabilt, fri og åpen kildekode, og lett å komme i gang med.

En stor del av våre kunder benytter seg av dette systemet, med stor suksess.

I dette innlegget vil jeg fortelle deg hvorfor du bør bruke Jenkins (eller et annet tilsvarende verktøy), hvordan du kan komme i gang, gi et eksempel på en Jenkins-fil, og til slutt gi deg inspirasjon til å lære mer. Dette er ikke et innlegg om hvordan en gjør en spesifikk ting i Jenkins, men det er et innlegg om hvordan du kommer i gang.

Så hvorfor burde du bruke Jenkins?

For det første gir det deg en stabil plattform å finne problemer fra. Med en byggserver på plass så har du en fasit.

Du slipper å lure på om det er “din maskin” det er noe galt med, eller om det er koden. Hvis Jenkins klager, er det galt.

Du kan også få Jenkins til å gjøre de kjedelige jobbene, som å deployere, kjøre integrasjonstester, bygge og teste på hver eneste innsjekk, og mer til.

Hvordan komme i gang?

Jenkins kan installeres på flere måter. En kan installere via en pakkebehandler, eller en kan laste ned en jar-fil. Jar filen kan kjøres på en app-server eller som den er.

Dersom du bare vil sjekke ut hva dette er på laptopen din, anbefaler jeg deg å laste ned jar-filen og kjøre den som et hvilket som helst java-program. For en server anbefaler jeg å installere via pakkebehandler, fordi da blir oppdatering gjort automatisk sammen med resten av maskinen. Bare kjør den opp, og bruk web-brukergrensesnittet. Jenkins lytter på port 8080 som standard, men dette kan endres via kommandolinjeargumenter.

Nå som du har fått installert Jenkins, er det på tide å opprette den første jobben.

Den første jobben

Du har flere muligheter her. Du kan sette opp en klassisk jobb, eller du kan sette opp en pipeline. En klassisk jobb tar utgangspunkt i et byggeverktøy, som til dømes Maven, mens en pipeline tar utgangspunkt i en groovy-fil. I begge deler kan du legge til kall til eksisterende skript, eller eventuelt kommandoer.

Slik hoster de VG.no

AWS, Heroku, Zetta.IO og Akamai. - Nevn en teknologi, så har vi hatt det i produksjon!

mandag 8. april 2019

Den store prinsipielle forskjellen er at en klassisk jobb hører til byggeverktøyet, mens en pipeline tar utgangspunkt i en fil i prosjektet ditt. Det betyr rent praktisk at dersom du gjør en endring i prosjektet som endrer hvordan du skal bygge prosjektet, så vil du kunne gjøre endringen i byggingen samtidig som du endrer koden. Brancher som ikke har denne endringen vil fortsette å følge gammelt oppsett. Dette gjør det praktisk mulig å endre på byggingen og utføringen av jobber i Jenkins uten at det ødelegger for andre brancher i git.

Som et eksempel på dette, har kan vi ta et hello-world prosjekt, og sette det opp og bygge det lokalt med Jenkins. Da får vi se med en gang hvordan det hele henger sammen, og vi kan se med et praktisk eksempel på hvordan alt henger sammen i praksis.

Dersom du ikke vil sette opp et selv, kan du klone dette, og se på hvordan ting er satt opp der.

En kan alltids sette opp mer ting senere, men jeg har her valgt å ha en enkel fil som heter standard_build.groovy. Den ser slik ut:

//Absolutt enkleste byggejobb...
pipeline {
    agent any
    stages {
        stage('Build') { 
            steps {
                sh 'cd my-app && mvn install'
            }
        }
    }
}

“agent any” er agenten som skal brukes. Dette er nyttig dersom du vil bygge til docker eller lignende. Dersom det er første gang du starter, anbefaler jeg å holde deg til agent any. En pipeline består altså av flere “stages”. En “stage” eller etappe (eller annet norsk ord som funker) består igjen av flere steg.

Her er det bare en stage, nemlig Build. Build har et enkelt steg, og det er å gå inn i mappen med koden, og kjøre en maven-kommando. I dette tilfellet er maven installert på serveren.

Nå bør alle utviklere være fullstack

Du må kunne mer enn bare front- eller backend, forteller de som ansetter.

torsdag 4. oktober 2018

Det er flere måter å gjøre ting på her; en kan be Jenkins provisjonere Maven, en kan installere manuelt, bruke pakkebehandler, kjøre et skript som tar hånd om ting, eller noe helt annet. Det enkleste er som oftest det beste, og her er det bare kjørt en maven-kommando.

Andre steg som kunne vært satt opp kunne vært ting som å deploye lokalt, kjøre integrasjonstester, samle sammen testresultater, eller lignende. Siden du kan kjøre shellkommandoer, er alt som kan skriptes gyldig å gjøre.

Personlig anbefaler jeg ikke shellscript for de fleste oppgaver: De gjør det litt mer knotete å finne ut hva som har skjedd, men dette er en vurdering du selv må ta. Dersom du har nyttige skripts som kjøres er det ingen grunn til å kaste ting som fungerer helt fint. Du kan heller bruke Jenkins til å kjøre dem med.

Men nå som vi har en fil, er det på tide å fortelle Jenkins at vi vil bruke den.

Slik bygger du et prosjekt i Jenkins

Gå inn på Jenkins sin nettside, og velg New Item. Skjermen skal se slik ut:

Dersom du bruker github-prosjektet jeg lenket til i toppen, kan du huke av for github prosjekt. Fyll ellers ut informasjon som beskrivelse. For build trigger kan du polle git-serveren med jevne mellomrom for å sjekke, bygge manuelt, periodisk eller kjøre etter en annen jobb har fullført.

Som du kan se har jeg kjørt hver time delt på 15, eller hvert 15. minutt. Jenkins følger crontab sin syntaks for tid.

.

Når du er fornøyd, kan du trykker på Save, og da kan du kjøre prosjektet.

Klikk deg inn på jobben og velg Build Now.

Så kan du følge med på konsollen etter hvert som bygget kjører.

Gratulerer! Du har nå satt opp en Jenkinsserver, satt opp en enkel jenkinsfil, og bygget et enkelt prosjekt. Du vet hvordan du kan kjøre andre script, og egne kommandoer, og veien er nå åpen for å deploye helt automatisk.

Siden dette er en “hvordan begynne” guide, og ikke en fullstendig opplæring i Jenkinsbruk, er det på tide at jeg takker for meg, men før jeg går, la meg foreslå noen temaer du kan undersøke videre dersom du vil lære mer selv:

• Multibranch pipeline: Dette lar deg bygge alle brancher ved hver eneste push, så du vet alltid hvordan ting står til i alle brancher.
• Bruk av forskjellige miljø, og bruk av brukernavn/passord i Jenkins
• Promotering av builds
• Evt. bare mer Groovy, siden det er språket en programmerer jenkins-jobber i

Nye valgomater, gamle løsninger

Slik kodet VG, NRK, Dagbladet og TV 2 årets valgomater.

mandag 26. august 2019