Het generaliseren van Jenkins Pipelines binnen een complexe omgeving/organisatie.

In een complexe en dynamische omgeving wilt men waar mogelijk, altijd iets generaliseren om de complexiteit te verminderen. In een omgeving waar alle teams CD (Continuous Delivery) enabled moeten zijn, is het dus handig dat nieuw gevormde teams gelijk aan de slag kunnen met Continuous Delivery. In plaats van dat de teams alles opnieuw moeten uitvinden, terwijl dat binnen de organisatie al meerdere keren gedaan is, kan het team gelijk aan de slag met de kennis die vergaard is door de jaren heen binnen de organisatie.

Jenkins Pipelines.png

Een voorbeeld: hoe je nieuwe teams CD enabled inricht.

Door een standaard pipeline te bieden voor de teams, waarmee ze gelijk aan de slag kunnen, richt je CD enabled in. Als het ware creëer je dan een pipeline als product voor deze teams. Door verschillende standaard pipelines aan te bieden is het mogelijk om de complexiteit voor de omgeving te minimaliseren. In deze blog laat ik je zien hoe je hiermee begint en de manier waarop je pipelines implementeert door middel van Jenkinsfiles (Pipeline als code/script).  Met dit blogaritkel geeft Ewan inzicht in één van de oplossingen voor een gegeneraliseerde Jenkins pipeline, maar natuurlijk zijn er nog velen manieren.

 

Stap 1: inventariseer de huidige oplossingen binnen de organisatie

Allereerst, is het van belang om de huidige oplossingen binnen de organisatie te inventariseren, bijvoorbeeld: wat voor tools gebruiken de teams? Hierdoor maak je de variatie tussen de teams en de complexiteit van de organisatie zichtbaar. Vervolgens ga je op basis van deze variatie beslissen, welke tools je in de pipeline gebruikt, en welke teams een andere werkwijze volgen om de standaarden van de organisatie te volgen. De oplossingen die gemaakt zijn binnen de organisaties kun je ook inventariseren. Wie weet komen daar weer hele andere oplossingen uit, die je als gegeneraliseerde/standaard Jenkins pipeline zou kunnen toepassen.  

 

Stap 2: bouwen/verzamelen scripts

Binnen deze stap is het belangrijk om als basis vanuit de volgende denkwijze een gegeneraliseerde Jenkins pipeline te realiseren: zorg er allereest voor dat alles ´Configuration as Code’ is. Iedere Jenkins server, pipeline of job moet als code uitgeschreven staan. Hierdoor voorkom je dat er handmatig beheer nodig is via een UI, wat foutgevoelig kan zijn als de verkeerde mensen het gebruiken. Omdat alles in code is geschreven, komt het regelmatig voor dat je zelf handmatig een script moet schrijven in plaats van een plugin in Jenkins gebruikt, die je via de UI werkend krijgt. Mogelijk moet je voor elke tool die je in de pipeline toepast een script schrijven. Binnen complexe organisaties zijn er vaak al scripts bruikbaar die ergens in een repository staan. Wanneer je deze scripts allemaal gebouwd of verzameld hebt, kan je deze scripts runnen vanuit een job om het overzichtelijk te houden.

 

Stap 3: creëer downstream jobs

In deze stap zorg je ervoor dat je downstream jobs maakt, die een enkele script uitvoeren voor een specifieke tool. Op deze manier is het mogelijk om Jenkinsfiles flexibel te creëren. Het uitvoeren van meerdere downstream jobs achter elkaar vanuit de upstream job, zorgen ervoor dat je gemakkelijk een pipeline maakt door blokjes (downstream jobs) aan elkaar te koppelen. Hierdoor is het heel makkelijk om standaard Jenkinsfiles te maken, omdat dit alleen een kwestie is van aangeven welke blokjes je kiest. Verder zit de implementatie ver weg gestopt voor de teams, waardoor zij met beperkte kennis gemakkelijk aan de slag kunnen. Daarnaast is het voor de teams belangrijk dat zij de juiste parameters meegeven aan de downstream jobs om er voor te zorgen dat de pipeline succesvol wordt afgerond.

Jenkins logo.png

 Stap 4: maak standaard Jenkinsfiles

Zoals eerder beschreven, hoeft de Jenkinsfile alleen maar downstream jobs aan te roepen. Hierdoor zijn de Jenkinsfiles redelijke basaal en komt er niet veel bij kijken. Om het allemaal nog eenvoudiger te maken, is het mogelijk om ervoor te kiezen om in de Jenkinsfile nog een stukje code toe te voegen. Hierdoor laden de parameters zich automatisch in uit de repo van een team, waardoor het team alleen een bestand nodig heeft waar de variabele in staan. Op deze manier is de instapdrempel voor de teams nog lager en is het mogelijk om direct aan de slag te gaan. Uiteindelijk zit in de repo van het team alleen een file waar de variabele in staan, en een Jenkinsfile die de juiste Jenkinsfile inlaadt die nodig is voor die specifieke applicatie. Deze Jenkinsfile staat dan in een repository samen met alle configuraties voor de downstream jobs (CI/CD Library).

Stap 5: Laat de teams het gebruiken

Nu de standaard Jenkinsfiles klaar zijn, kun je de gegeneraliseerde Jenkins pipelines implementeren bij de teams. Met de vergaarde gegevens en feedback zijn aanpassingen in de pipeline zo gedaan. Wanneer een team er een nieuwe tool bij wil? Beslis met je team of het daadwerkelijk nodig is en werk het indien nodig uit als een nieuwe block. Verder is het mogelijk om de teams zelf functionaliteiten en tools toe te laten voegen door middel van pull requests op je CI/CD Library. Omdat het allemaal als code staat in een repo kun je alles community-driven laten draaien. Hierdoor heb je er zelf ook minder werk aan!

Ga je binnenkort met Jenkins aan de slag en heb je nog vragen? Laat het mij dan vooral weten.