Teil 2 der Serie
Nach der Definition eines Kriterienkatalogs im ersten Teil der Serie (https://thecattlecrew.net/2017/11/28/kriterien-fuer-die-bewertung-von-ci-cd-tools/) beginnt nun die Bewertung der CI/CD Tools. Ich fange mit Jenkins an, welches als das Tool mit der größten Verbreitung unter den CI/CD Tools gilt. Bekannt ist es vor allem durch die populäre Erweiterbarkeit mit Plugins. Bei Jenkins handelt es um ein in Java geschriebenes Tool, dass unter der MIT-Lizenz verfügbar ist. Darauf folgen unter anderem Bewertungen der CI/CD Tools GitLab CI und Concourse CI.
Skalierung
Jenkins ermöglicht durch die Unterstützung von Remote-Agents die Skalierung der Ausführung auf mehreren Maschinen. Die Maschinen werden als Slaves bezeichnet. Mit den Slaves wurde die Distributed Architecture eingeführt, die es ermöglicht, mehrere Slaves anzulegen und diese mit dem Master zu verbinden. Dadurch kann die Ausführung von Jobs auf die Slaves verteilt werden, um die Abarbeitung von Jobs zu beschleunigen. Es gibt verschiedene Varianten diese zu starten. Dazu zählen via SSH, on Windows, own Script, via Java Web Start und headlessly. Die Slaves können on-premises betrieben oder über eine SaaS-Lösung wie Cloudbees in Anspruch genommen werden.
Weitere Details sind unter den folgenden Links zu finden:
https://www.cloudbees.com/blog/scaling-jenkins-slaves
Build-Möglichkeiten
Jenkins bietet mit Distributed Builds, Parallel Builds und Triggered Builds eine Vielzahl an Build-Möglichkeiten. Bei Distributed Builds handelt es sich um die Verteilung von Build Jobs auf mehreren Servern. Ein Knoten beinhaltet dabei eine alleinstehende Installation des Masters vom Jenkins, der alle Aufgaben für das Build System steuert. Meistens werden dazu, wie im vorherigen Abschnitt erwähnt, auf anderen Systemen sogenannte Slaves aufgesetzt, auf die man die Aufgaben verteilen kann. So wird vermieden, an die Grenzen der Maschine zu kommen, auf der der Master installiert ist. Damit übernimmt der Master lediglich die Steuerung und baut die Builds nicht selbst. Das Bauen der Builds übernehmen die Slaves. Aber auch Parallel Builds, bei denen parallele Stages ausgeführt werden können, werden durch die Jenkins Pipeline ermöglicht. Ein gutes Beispiel hierfür wäre das Parallelisieren von Tests, um JUnit-Tests parallel mit Integrationstests durchzuführen. Zu guter Letzt gibt es natürlich auch noch die Möglichkeit, Builds über Trigger anzustoßen. Es kann zum Beispiel eingestellt werden, dass ein Build in Abhängigkeit von dem Ergebnis eines anderen Builds ausgeführt werden soll.
Weitere Details sind unter den folgenden Links zu finden:
https://wiki.jenkins.io/display/JENKINS/Distributed+builds
https://wiki.jenkins.io/display/JENKINS/Pipeline+Plugin
Rechteverwaltung von Benutzern und Gruppen
Jenkins bietet per Default keine Unterstützung für die Rechteverwaltung auf Rollen- oder Projektebene an. Doch wie Sie vielleicht bereits erahnen können, gibt es auch hierfür ein Role Strategy Plugin, mit dem man globale Rollen wie Admin oder Job Creater definieren kann. Aber auch die Erstellung von Projektrollen, die nur auf Projektbasis Jobs anlegen und ausführen können, ist mit dem Plugin möglich. Es ist zu empfehlen, diese Form der Rechteverwaltung nur zu nutzen, wenn es der Use Case wirklich erfordert, da diese sehr flach und einfach gehalten ist.
Weitere Details sind unter den folgenden Links zu finden:
https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin
Container Management
Es gibt in Jenkins keine native Container Unterstützung. Konkret gibt es für die Container Engine aber Support durch ein entsprechendes Plugin. Dazu muss das Docker Plugin installiert werden, um dann mit Jenkins einen Docker Host zu kontrollieren, der wiederum Builds in Form von Containern anstoßen kann. Eine Möglichkeit wäre die Nutzung einer externen Registry, wie z.B. der Service EC2 Container Registry von Amazon, in Jenkins zu integrieren.
Aus eigener Erfahrung weiß ich, dass ein erfolgreicher Build über Jenkins nicht unbedingt bedeutet, dass der Docker Container fehlerfrei läuft. Um sicherzugehen, dass der Jenkins-Container wirklich fehlerfrei läuft, wären zusätzliche Überprüfungen notwendig.
Weitere Details sind unter den folgenden Links zu finden:
https://wiki.jenkins.io/display/JENKINS/Docker+Plugin
https://cloud.google.com/container-registry/?hl=de
Notifications und Monitoring
Das Notification-Plugin erlaubt es, Job Status Notifications im JSON und XML Format zu versenden. Dabei können das Format (JSON/XML), das Protokoll (HTTP, TCP, UDP), das Event (Job started, Job completed, all events), die URL, an die versendet werden soll, und ein Timeout angegeben werden. Diese werden dann per E-Mail zugestellt, wozu natürlich vorher ein SMTP-Server konfiguriert werden muss.
Neben der E-Mail sind noch weitere Wege möglich, um über Ereignisse zu informieren. Dazu gehören zum Beispiel Notifications über Slack, Rocket.Chat, Telegram und vieles mehr. Da Jenkins Open-Source ist, sind viele Kanäle bereits durch Plugins abgedeckt oder werden in Zukunft noch abgedeckt.
Wie für die Notifications existiert auch für das Monitoring ein Plugin, bei dem per Default JavaMelody verwendet wird. Java Melody ist ein Monitoring-Framework für Java oder JavaEE Applikationen, mit dem sehr viele Details grafisch in Form von Charts angezeigt werden können. Neben JavaMelody gibt es auch noch andere Möglichkeiten.
Weitere Details sind unter den folgenden Links zu finden:
https://wiki.jenkins.io/display/JENKINS/Notification+Plugin
https://wiki.jenkins.io/display/JENKINS/Monitoring
Anderweitige Evaluierung
Durch die hohe Anzahl an Plugins ist die Flexibilität des Tools sehr hoch und damit auch sein Funktionsumfang. Jedoch ist hier Vorsicht geboten, weil viele Plugins unter Umständen nicht aktuell sind und damit sicherheitstechnische Lücken beinhalten können. Zudem machen es Plugins dem Anwender schwer, zu erkennen, ob ihr Einsatz für ein bestimmtes Szenario sinnvoll ist oder nicht.
Ein Blick in den Issue Tracker vom Jenkins, der einmal für den Jenkins selbst existiert aber auch für jedes einzelne Plugin kann dabei helfen, zu erkennen, ob ein Plugin sehr veraltet ist oder ob es regelmäßig aktualisiert wird.
Wichtig dabei ist eine gute Dokumentation, die von Jenkins leider nicht an allen Stellen gegeben ist. Zum Jenkinsfile zum Beispiel fehlen in der offiziellen Dokumentation Befehlsreferenzen. Wenn man sich auf die Suche nach diesen macht, landet man also schnell im Source Code.
Nichts desto trotz ist Jenkins sehr weit verbreitet. Die zahlreichen Erweiterungen in Form von Plugins und auch der Open-Source-Faktor spielen dabei eine sehr große Rolle. Dazu steht eine starke und hilfsbereite Community hinter Jenkins, weswegen ein gewisser Coolness Faktor gegeben ist. Bei Problemen kann man sich über GitHub an die Community wenden und erhält bereits nach kurzer Zeit Antworten.
Continuous Delivery
Die Einführung der Jenkins Pipeline DSL ermöglicht es den Benutzern, Pipeline as Code zu verwenden. Dabei werden mehrere Stages in einem Jenkinsfile definiert, dass wiederum als Code neben dem eigentlichen Code gesehen wird. In dem Jenkinsfile können dann Stages wie Build, Test oder Upload definiert werden, die alle erfolgreich verlaufen müssen, damit die Pipeline als erfolgreich angesehen wird. Dadurch ist eine hohe Flexibilität gegeben und die Unterstützung für Continuous Delivery gewährleistet.
Weitere Details sind unter den folgenden Links zu finden:
https://github.com/openshift/jenkins
https://wiki.jenkins.io/display/JENKINS/Cloud+Foundry+Plugin
https://jenkins.io/solutions/pipeline/
Kosten
Zu guter Letzt kommen wir zu den Kosten. Dabei wurde als Faktor ein Entwicklerteam von 30 Entwicklern ausgewählt. Da es sich bei Jenkins um ein Open-Source-Tool handelt, entstehen on-premises keinerlei Kosten bei der Nutzung des Tools. Dies gilt auch für die Remote Agents, die man on-premises ausführt.
Um einen Vergleich zu erhalten, wurde der Software as a Service Anbieter CloudBees ausgewählt, der eine Lösung für Jenkins bereitstellt. Leider müssen in dem Fall die Preise individuell angefragt werden, da mehr Faktoren als die Größe des Teams in den Preis einfließen.
Fazit
Jenkins bietet als Open-Source-Tool sowohl für den Continuous Integration als auch für den Continuous Delivery Bereich eine Vielzahl an Unterstützungsmöglichkeiten. Dies wird vor allem durch die hohe Anzahl an Plugins gewährleistet. Diese hohe Flexibilität spricht für das Tool und macht Jenkins auch in Zukunft zu einem einsetzbaren Kandidaten für Projekte. Das Plugin-Ü–kosystem ist aber auch zugleich die Kehrseite der Medaille. Es spricht sehr stark gegen das Prinzip des Single Source of Truth und erschwert die Update Strategie, weil die Kompatibilität zwischen den Plugins und Jenkins sichergestellt werden muss. Dazu kommt der initial sehr verwirrende administrative Aufwand, der zu einem hohen Einarbeitungsaufwand führt. Nichts desto trotz ist Jenkins ein mächtiges Tool, das dem Entwickler immer noch sehr viele Möglichkeiten bietet..