Bernhard Cygan 23. August 2016

Von Continuous Integration zu Continuous Delivery mit Jenkins Pipeline – Teil 3

Der zweite Artikel dieser Reihe (Von Continuous Integration zu Continuous Delivery mit Jenkins Pipeline) endete mit der Nutzung von Jenkins Pipeline und der Global Pipeline Library, so daß gemeinsam genutzte Teile des Pipeline-Codes an einer zentralen Stelle gehalten werden können. Shared Code ist nett, aber da gibt es doch bestimmt noch mehr, oder? Die einfache Antwort ist: Ja, natürlich gibt der Werkzeugkasten noch mehr her.

Ein verbreitetes Problem bei Continuous Delivery/ Continuous Deployment in Unternehmen, sind die unterschiedlichen Verantwortungsbereiche für die einzelnen Teile der Build Pipeline. Üblich ist es z. B., dass die Entwickler die Hoheit über den Build-Teil haben, Tester die Inhalte der Tests pflegen, Operatoren die Kriterien für das automatische Deployment festlegen und die Compliance-Abteilung sagt, welche Tests auf alle Fälle ausgeführt werden müssen. Natürlich wäre es ideal, in solchen Fällen komplett mit crossfunktionalen Teams zu arbeiten; leider stößt das im echten Leben auf viele Hindernisse.

Um die unterschiedlichen Verantwortlichkeiten abbilden zu können, muss sichergestellt sein, dass der jeweilige Teil der Build Pipeline nur von Personen geändert werden kann, die das auch dürfen. Mit Jenkins-Mitteln gibt es mehrere Möglichkeiten, diese Anforderungen umzusetzen:

Generierung von Jobs durch Job-DSL [1] mit Hilfe eines oder mehrerer Seed-Jobs: Die Definition aller Jobs liegt an zentraler Stelle als Beschreibung vor und die Jobs werden z. B. nachts automatisch neu generiert. Damit können Entwickler tagsüber Jobs modifizieren oder erstellen – am nächsten Morgen ist auf jeden Fall wieder alles auf einem definierten Stand. Und auch nur von diesem Stand sollten automatische Deployments möglich sein.
Nutzung von Pipeline Templates [2]: Die Konfiguration und Parameter einzelner Jobs werden in einem Template erfasst, der konkrete Build-Job definiert nur noch die Parameter für das Template. Änderungen am Template sind beim nächsten Build Run wirksam. Die Templates können in einem beliebigen Source Code Repository liegen.
Nachladen von Groovy Remote Code [3]: Der Remote Code wird aus einem beliebigen Source Code Repository geladen. Die Zugriffsrechte auf dieses Repository können komplett anders vergeben sein, als innerhalb von Jenkins oder für den Source Code der Applikation. Details der Implementierung einzelner Tests sind für die Build Pipeline nicht relevant.
Pipeline-as-Code [4]: Hierbei wird die Definition der Build Pipeline in der Regel zusammen mit dem Source Code der Applikation im selben Repository gespeichert, kann also z. B. auch gebranched und gemerged werden.
Eine Kombination der vorgestellten Möglichkeiten ist natürlich auch möglich und in vielen Fällen auch sinnvoll.

Ich möchte hier Pipeline-as-Code vorstellen, das im Fokus von Jenkins 2.x steht. Zur Beschreibung von Build Pipelines in Jenkins, dient die bereits aus den ersten beiden Teilen bekannte Groovy-basierte DSL (Domain-specific Language). Dort habe ich sie im Rahmen eines Build Jobs verwendet. Dieselbe Beschreibung kann aber auch im Source Code Repository der Applikation stehen und unterliegt somit denselben Regeln wie der Source Code selbst. Mit Hilfe einiger Jenkins-Plugins (womit sonst?) entsteht so ein System, das weitestgehend wartungsfrei arbeitet. Das Ganze funktioniert wie folgt:

Die in der Pipeline DSL beschriebene Build Pipeline wird in das Root-Verzeichnis im SCM unter dem Namen Jenkinsfile abgelegt. Im Jenkins müssen die folgenden Plugins installiert sein: Folders und je nach SCM der Support für Multi-Branch, Organisation Folders und Pull Requests. Sind diese Voraussetzungen geschaffen, braucht es nur noch einige Definitionen und wir bekommen einen Jenkins, der für neue Branches automatisch einen passenden neuen Build Job erzeugt und bei Branch Merge oder Branch Delete automatisch den passenden Build Job löscht.

Abb.1: Organization Folder anlegen . © Bernhard Cygan

Sind diese Voraussetzungen geschaffen, braucht es nur noch einige Definitionen, und wir bekommen einen Jenkins, der für neue Branches automatisch einen passenden neuen Build Job erzeugt und bei Branch Merge oder Branch Delete automatisch den passend Build Job löscht.

Wie funktioniert’s ?

In Jenkins einen Organization Folder anlegen (z.B . New Item -> GitHub Organization). Das Feature ist auch verfügbar für andere SCMs wie BitBucket oder Team Foundation Server, dann heißt das zu erstellende Objekt entsprechend; die Funktionalität bleibt gleich (s. Abb.1).

Abb.2: In der Konfiguration des Folders die URL eintragen. © Bernhard Cygan

In der Konfiguration des Folders die URL der GitHub Organization eintragen und passende Credentials für das Scannen des Repositories (s. Abb.2).
In den Optionen können bestimmte Repositories eingeschlossen bzw. ausgeschlossen werden. Bei self-hosted GitHub-Instanzen kann ein alternativer API Endpoint angegeben werden und zum Schluss können auch noch spezielle Credentials für Checkout definiert werden.

Abb.3: Abspeichern der Definition. © Bernhard Cygan

Abb.4: Abspeichern der Definition. © Bernhard Cygan

Festlegen, wann das Repository regelmäßig nach Änderungen durchsucht werden soll.
Das Abspeichern der Definition löst den ersten Scan-Vorgang aus. Danach stehen Jobs für alle Projekte und deren Branches innerhalb der Organisation zur Verfügung (s. Abb.3 und 4).

Arbeitet man nicht mit GitHub Organization (oder äquivalent für andere SCMs), kann man auch mit (New Item -> Multibranch Pipeline) einen äquivalenten Effekt nur für Branches erreichen.

Insgesamt lösen Pipeline DSL und Pipeline-as-Code viele Probleme im Continuous Delivery-Umfeld wie z. B.

unüberschaubare Anzahl von Build Jobs,
Wartbarkeit von Build Pipelines, die aus mehreren verketteten Build Jobs bestehen,
Wartbarkeit von Jobs, die einzelne Branches bauen und
Aufsetzen neuer Jobs für neue Projekte.

Fazit

Erfahrungsgemäß sinkt die Anzahl der Build Jobs in einer CD-Umgebung durch den Einsatz von Pipeline DSL ungefähr um Faktor 10, was wiederum insgesamt sowohl der Wartbarkeit als auch den Startzeiten des Jenkins Masters zugute kommt.

Für viele Entwickler löst Pipeline-as-Code die meisten ihrer Anforderungen. Arbeitet man (noch) nicht nach DevOps, schafft es aber aus Sicht von Ops, QA und Compliance einige neue Probleme, da die Kontrolle über die Pipeline – insbesondere bei Continuous Deployment – plötzlich zu weit nach "links" gewandert ist. Auch dafür lassen sich aber im Repertoire von Jenkins Lösungen finden.

Quellen