Tech up! zu Jenkins Pipeline Scripts

In unserer neuen Blogpost-Serie „Tech up!“ dreht sich alles um technische Themen – unsere System Technicians und Software Engineers zeigen ihre Expertise. Angela (Senior Software Engineer) schreibt in ihrem Beitrag zu Jenkins Pipeline Scripts. 

Im Rahmen eines Jenkins Techlabs, welches bei Puzzle durchgeführt wurde, wurde gezeigt wie Pipeline Scipts funktionieren und wie diese geschrieben werden. 

Jenkins ist für den Build, Release und Deploy Prozess zuständing:

Seit Version 2.0 von Jenkins werden Pipelines unterstützt. Die Jenkins Pipelines unterstützen 2 Syntaxe: Scripted Pipeline und Declarative Pipelines.

Im folgenden Blogpost möchte ich zeigen, wie ein Pipeline Script in der deklarativen Syntax geschrieben wird und wie die wichtigsten Funktionen genutzt werden koennen. Folgende Themen werden abgedeckt:

  • Java
  • Yarn/Gulp
  • Android/Cordova
  • Nightly Sonar
  • Deploy auf JBoss

Jenkinsfile erstellen & Jenkins einrichten

  • Jenkinsfile im Root des Projekts definieren. Der Defaultname ist Jenkinsfile
  • Im Jenkins ein neues Multibranch Pipeline Projekt erstellen, das entsprechende Git-Repository und Pipeline-Script File angeben

Nun wird in jedem Branch des Projektes automatisch nach Jenkinsfiles gescannt und wenn welche gefunden werden, wird der Buildprozess gestartet.

Pipeline Script

Das Grundgerüst für das Pipeline Script sieht wiefolgt aus.

Welche Parameter möglich sind, wird ausführlich in der Jenkins Doku beschrieben: https://jenkins.io/doc/book/pipeline/syntax/

Options

  • 5 ältere Builds werden behalten
  • Das Timeout beträgt 10 Minuten

Triggers

  • Das SCM wird alle 5 Minuten gepollt
  • Um Mitternacht wird der Buildprozess durch einen Cronjob gestartet

Environment

  • Alle benötigten Tools werden importiert. Dazu müssten diese vorgängig installiert worden sein. Bei uns wird dies mit dem CustomTools Plugin gemacht

Backend & Client Build (Java/Maven & Yarn)

Tests

  • Tests für Backend und Client werden parallel ausgeführt
  • Mit dem junit Plugin werden die Testresultate publiziert

Android/Cordova Build

  • Mit dem Android SDK Manager kann die Version der Build-Tools ausgewählt werden.
  • GRADLE wird für den Cordova/Android ebenfalls benötigt und muss in der PATH Variable hinzugefügt werden.

Sonar Analyse

  • Jede Nacht wird mit der Cron Expression der Build getriggert, um die Sonar Analyse durchzuführen
  • Mit der in der Expression angegebenen Validierung wird geschaut, ob der Build durch einen Trigger ausgeloest wurde und nur dann werden auch die entsprechenden steps ausgeführt

Shared Libraries

Was genau Shared Libraries sind und ich welchen Fällen man diese benutzt, kann im Puzzle Techlab nachgelesen werden:

https://github.com/puzzle/jenkins-techlab/blob/master/labs/11_shared_libs.md

In unserem Beispiel haben wir eine Shared Library implementiert, welche die E-Mail des letzten Git Commiters ausliest und im Falle eines broken oder unstable Builds ein E-Mail an diesen versendet.

Code der Shared Library:

Eingebunden wird diese im Jenkinsfile mit dem folgenden Aufruf:

Verwendet wird diese nun in den post Actions:

Deployment

Das Deployment ist in einem zusätzlichen Job und Jenkinsfile erfasst, da dieses manuell ausgelöst wird. Dieser Job ist parametrisiert, sodass die Credentials und auch die Umgebung ausgewählt werden können.

  • Das Plugin muss dann im pom.xml noch entsprechend konfiguriert werden

  • Wenn der Job nun gestartet wird, erscheint folgendes Fenster, in dem die Parameter angegeben werden können

Übersicht des Pipeline Scripts

  • Jenkins View: In der folgenden Grafik sind die einzelnen Schritte des Pipeline Scripts dargestellt. Pro Schritt wird auch die Dauer angegeben.

  • Blue Ocean Plugin View: Mit dem Blue Ocean Plugin sieht man auch welche Schritte parallel ausgeführt werden. Die Nightly Jobs wurden hier nicht ausgeführt, deshalb sind diese mit „?“ markiert.

Fazit

Persönlich finde die Job-Konfiguration via Jenkins-Pipeline Scripts sehr praktisch und übersichtlich. Desweiteren müssen Jobs nicht immer neu erfasst werden, sonden die Konfiguration ist im Projekt und GIT abgelegt. Mit dem Multibranch Job erübrigt sich auch das Erfassen der Jobs pro Branch. Diese werden automatisch erkannt, erstellt und ausgeführt.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *