Jenkins multibranch-pipeline och pretested integration

Med multibranch pipelines har Jenkins gett sig in i kampen om nästa generations CI/CD-servrar. Men med utmanare som Concourse och CircleCI finns det ingen tydlig vinnare.

Praqma har arbetat med Jenkins (tidigare Hudson) som de facto-server för Continuous Integration i nästan ett decennium. Under lång tid var Jenkins ledande position ohotad. Men på senare tid har en mängd konkurrenter dykt upp och gett gamla hederliga Jenkins en rejäl utmaning. För att möta detta har Jenkins introducerat pipelines: ett Groovy DSL för att styra ditt CI-flöde med kod. CloudBees investerar stort i pipelines, och de har blivit Jenkins framtid. Om du inte har tittat på dem ännu, besök Jenkins pipelinesida

Bör du då bara konvertera alla dina jobb till pipeline och sedan leva lycklig i alla dina dagar? Svaret är, precis som i nästan alla andra delar av livet: det beror på.

Det här inlägget visar exempel med Phlow och Praqmas Pretested Integration Plugin. Om du inte känner till det är det dags att läsa på.

Bakgrunden

Hos en av våra kunder ville vi skapa en pipeline som byggde parallellt på flera operativsystem. Lösningen skulle blockera integrationsjobbet tills all kompilering och alla enhetstester var klara. Den ursprungliga pipelinen skapades i Jenkins UI, så vi behövde göra den som kod på något sätt. Inget mer peka och klicka!

Vi kunde antingen konvertera den befintliga lösningen till JobDSL eller försöka skapa en Jenkins pipeline-version av samma byggflöde. Vi valde Jenkins pipelines för att få några av fördelarna som listas i vårt bildspel om framtidens pipelines.

Att köra multibranch eller inte, det är frågan!

Pipeline-jobb finns i två varianter: vanliga och multibranch. Gemensamt för båda är språket: ett Groovy-baserat DSL.

Vi valde multibranch pipeline eftersom den gör det möjligt att ha pipelinen inbäddad som kod i samma repository (användningsfall 1 i bildspelet ovan). I en vanlig pipeline går det dessutom inte att se vilken branch som aktiverade bygget, eftersom Jenkins checkar ut en SHA, inte en branch.

Ett förenklat exempel på pipelinen i produktion finns här.

Så implementerar du Phlow i Pipeline

Eftersom Praqmas nuvarande version av Pretested Integration Plugin inte är kompatibel med Pipeline behövde vi skripta fram motsvarande funktionalitet. Jag går inte igenom pipelineskriptet, utan fokuserar på problemen vi stötte på när vi utvecklade det.

Git publisher, någon?

Eftersom pipelines är ett nytt sätt att interagera med Jenkins kan du inte använda alla plugins och funktioner som ett vanligt freestyle-jobb erbjuder.

Till exempel kan Git-rutinen för checkout användas för kloningsdelen av pretested integration, men när vi behöver pusha koden tillbaka till en branch finns ingen hjälp att få.

Ett ärende har skapats för detta, men tills det är löst behöver du använda vanliga Git-kommandon inbäddade i pluginet sshagent.

Översikten är död, länge leve översikten

Som illustreras nedan kan de gamla freestyle-jobben enkelt göras om till en översikt när de är konfigurerade att trigga varandra.

Översikten ger en bra bild av vilken branch som byggs just nu, och genom att skrolla ned i listan med körningar kan du identifiera återkommande fel i en pipeline.

Med Jenkins Pipeline går den vy per master som vi kan ha med PIP och freestyle-jobb förlorad. Översikten är repository-centrerad, vilket innebär att alla brancher behandlas lika och visas i samma vy. Till exempel visas både master och /version_2.x/master nu i samma vy.

När vi går in i det enskilda bygget får vi en betydligt bättre överblick över parallella byggen och enklare navigering till relevant output än i den gamla översikten. Varje ikon är klickbar och visar en lista över kommandon och tillhörande loggar.

Om detta är en måste-ha-funktion behöver du alltså skapa någon form av dashboard som kan ge samma typ av information som det gamla sättet (se dashing.io eller Pipeline Aggregator View).

Ett annat sätt är att dela upp pipelinen i två delar:

• En del som avgör om pretested integration lyckades eller misslyckades

• En som bygger master-pipelinen (allt efter tullgrinden som beskrivs i vår CoDe Storyline)

På så sätt får du den uppdelning per master som du vill ha, men offrar all spårbarhet till utvecklarens commit.

En deleteDir() om dagen håller doktorn borta

Om du inte har flera steg som körs på samma nod samtidigt får du ingen ny workspace. Den gamla återanvänds automatiskt.

Det här leder till många deleteDir() i din pipeline. Annars får du märkliga fel när du stashar och unstashar.

Du kan omsluta din nod med en funktion för att säkerställa att du alltid har en ren workspace.

Låt oss börja från början

Att trigga om en pipeline från ett visst jobb är återigen enkelt i freestyle-jobb.

När vi delar upp allt i enskilda jobb får vi möjlighet att trigga om en pipeline från en specifik punkt.

När du använder Jenkins Pipeline är det allt eller inget, vilket gör det omöjligt att trigga om med PIP, eftersom du inte vill trigga om integrationssteget.

CloudBees har skapat ett proprietärt plugin som heter checkpoints. Det låter dig starta om från den checkpointen. Tyvärr har de inte gjort det open source eller stängt några ärenden som lyfter detta.

Det är också ett argument för att dela upp pipelinen i två: en för integration till master och den andra för själva build-pipelinen.

Manuella små steg, med fallgropar

Om du behöver utföra någon manuell validering innan du går vidare till nästa steg i din pipeline använder du taggen input i din Jenkinsfile. Om det bara är en signal placerar du den på en flyweight-executor, så att den inte tar upp en executor-plats på en nod.

stage 'Promotion' { input 'Deploy to Production?' }

Det finns vissa nackdelar med detta arbetsflöde. I Jenkins UI ser det ut som om pipelinen fortfarande körs trots att den väntar på manuell input. Jag hade gärna sett att den parkerades i stället för att fortfarande vara aktivt igång. Men det är vad vi har just nu.

Slutsats

Jenkins Pipelines är definitivt ett steg i rätt riktning, och jag måste vara helt ärlig mot dig: jag gillar det, men jag ser också problem!

Det var bara en månad sedan Jenkins tog bort taggen ”BETA” från Blue Ocean, det nya UI som är anpassat för Pipelines.

Vissa av problemen som beskrivs här kan vara lösta om ett år, och vissa saker lär vi oss helt enkelt att hantera på mer eleganta sätt.

För att sammanfatta erfarenheten kommer här en TL;DR med för- och nackdelarna som diskuterats ovan:

Fördelar:

• Möjligheten att specificera pipelinen i ditt SCM-repository; pipeline as code!

• En ny pipeline är bara en ny branch, sedan är du redo

• Din pipeline behandlas inte bara som kod, den är kod!

• Stashing garanterar att parallella builds kör samma kod.

• Pipeline är framtiden för Jenkins. Anpassa dig som de bästa – eller gå under som resten.

Nackdelar:

• Ingen Pretested Integration Plugin tillgänglig

• Git SCM-funktionaliteten är begränsad till grundläggande Git-kommandon

• Ingen överblick för en chef när pipelinen är full

• Ingen överblick för en utvecklare när pipelinen är uppdelad i två delar.

• Det går inte att köra om delar av pipelinen

• /ready-grenar tas bort från översikten efter att de har körts (och mergats)