Was ist Jenkins? CI/CD und eigener Betrieb
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: Jenkins ist ein Open-Source-Automatisierungsserver, der Entwicklungsteams beim Bauen, Testen und Bereitstellen von Anwendungen unterstützt. Meist übernimmt er CI/CD-Prozesse, also die regelmäßige Prüfung von Codeänderungen und die Vorbereitung neuer Versionen für die Veröffentlichung. Jenkins lässt sich auf einem eigenen Server mit Linux betreiben. Dann muss man sich allerdings selbst um Wartung, Updates und Sicherheit kümmern.
Wozu Jenkins dient – und wozu nicht
Jenkins führt Aufgaben nach einem festgelegten Ablauf aus: Er lädt Code herunter, führt Befehle aus, speichert Ergebnisse und meldet Erfolg oder Fehler. Eine Aufgabe kann nach einer Änderung im Repository, nach einem Zeitplan oder auf Anforderung eines Nutzers starten. Ein Repository speichert den Code zusammen mit seiner Änderungshistorie.
Jenkins ist jedoch kein System zur Führung von Entwicklern und kein Ersatz für ein Werkzeug zur Arbeitsplanung. Er automatisiert technische Abläufe, statt Aufgaben zu verteilen oder das Team zu bewerten. Auch ein Versionskontrollsystem wie Git ersetzt er nicht, kann aber mit ihm zusammenarbeiten.
Typische Einsatzbereiche sind:
- das Bauen von Anwendungen, also das Umwandeln von Code in eine ausführbare oder verteilbare Form;
- das Ausführen von Tests und Prüfungen der Codequalität;
- das Erstellen von Paketen oder Container-Images;
- das Veröffentlichen von Ergebnissen und das Bereitstellen von Anwendungen in einer ausgewählten Umgebung.
Jenkins koordiniert diese Abläufe, nutzt für ihre Ausführung aber meist andere Werkzeuge. Er kann nicht selbst jede Sprache kompilieren und enthält auch keine Tests für die jeweilige Anwendung – er führt die vom Team vorbereiteten Befehle aus.
Wie Jenkins CI/CD unterstützt
CI, also kontinuierliche Integration, bedeutet, Codeänderungen häufig zusammenzuführen und automatisch zu prüfen, ob sich die Anwendung weiterhin korrekt bauen lässt und die Tests besteht. So kann das Team früher erkennen, wenn eine neue Änderung eine bestehende Funktion beschädigt hat. Ein erfolgreiches Prüfergebnis garantiert allerdings keine Fehlerfreiheit: Seine Aussagekraft hängt vom Umfang und von der Qualität der Tests ab.
CD kann kontinuierliche Bereitstellung oder kontinuierliches Deployment bedeuten. Bei der kontinuierlichen Bereitstellung steht eine geprüfte Version zur Veröffentlichung bereit. Bevor sie für Nutzer freigeschaltet wird, kann jedoch eine Freigabe erforderlich sein. Beim kontinuierlichen Deployment gelangt eine Änderung automatisch in die Produktionsumgebung, wenn sie die festgelegten Bedingungen erfüllt. Die Produktionsumgebung ist die Umgebung, die von tatsächlichen Nutzern verwendet wird.
Jenkins schreibt keines dieser Modelle vor. Man kann ausschließlich Tests, ein vollständiges Deployment oder einen Ablauf mit manueller Freigabe vor der Veröffentlichung konfigurieren. Die Installation des Werkzeugs allein schafft noch keinen CI/CD-Prozess – zusätzlich müssen die Schritte, die Erfolgskriterien und der Umgang mit Fehlern festgelegt werden.
Pipeline: ein Ablaufplan für die Arbeit
Eine Pipeline beschreibt die aufeinanderfolgenden Schritte der Automatisierung. In Jenkins wird sie häufig in der Datei Jenkinsfile gespeichert, die zusammen mit dem Anwendungscode verwaltet wird. Dadurch lassen sich Änderungen am Build-Prozess ebenso überprüfen und versionieren wie Änderungen am Programm selbst.
Stell dir ein Team vor, das einen Onlineshop entwickelt. Nachdem eine Änderung an das Repository übermittelt wurde, kann Jenkins folgenden Ablauf ausführen:
- Die angegebene Version des Codes herunterladen.
- Abhängigkeiten installieren und die Anwendung bauen.
- Tests ausführen, die beispielsweise die Berechnung des Warenkorbwerts prüfen.
- Ein Artefakt speichern, also ein Ergebnis des Builds, etwa ein Anwendungspaket.
- Dieses Paket in einer Testumgebung bereitstellen.
- Vor dem Deployment in die Produktionsumgebung auf die Freigabe einer berechtigten Person warten.
Schlägt der Warenkorbtest fehl, stoppt eine korrekt konfigurierte Pipeline die weiteren Schritte. Das Team erhält das Ausführungsergebnis und die Logs. Diese Protokolle dokumentieren den Ablauf der Befehle und helfen, die Ursache des Problems zu ermitteln.
Eine bewährte Regel ist, dasselbe Artefakt bereitzustellen, das zuvor die Tests bestanden hat. Wird die Anwendung vor der Veröffentlichung erneut gebaut, kann das Ergebnis anders ausfallen – etwa wenn sich die heruntergeladenen Abhängigkeiten geändert haben.
Jenkins selbst auf Linux betreiben: Was gewartet werden muss
Jenkins lässt sich selbst auf Linux hosten, unter anderem als Dienst oder in einem Container. Dafür ist eine kompatible Java-Umgebung erforderlich. Vor der Installation sollte man in der offiziellen Dokumentation die Anforderungen der gewählten Jenkins-Version, die unterstützten Java-Versionen und den empfohlenen Installationsweg prüfen.
Bei größeren Konfigurationen trennt Jenkins die Koordination der Arbeit von ihrer Ausführung. Der Controller verwaltet Aufgaben und Konfiguration, während Agenten die Build- und Testvorgänge ausführen. Diese Aufteilung ermöglicht es, passende Ausführungsumgebungen für die Projekte auszuwählen und die Belastung des Controllers zu begrenzen.
Eigenes Hosting bedeutet Kontrolle über die Umgebung, bringt aber auch konkrete Pflichten mit sich:
- Jenkins, das Betriebssystem und die Plugins, die seine Funktionen erweitern, aktualisieren;
- Zugriffsrechte und Zugangsdaten wie Tokens verwalten;
- Backups erstellen und prüfen, ob sich die Konfiguration wiederherstellen lässt;
- Speicherplatz, Logs und Ressourcenverbrauch überwachen.
Besondere Vorsicht ist beim Ausführen von Code nicht vertrauenswürdiger Personen geboten. Eine Automatisierungsaufgabe führt Befehle aus und sollte deshalb keinen unnötigen Zugriff auf Geheimnisse wie Zugangsdaten oder auf die Produktionsinfrastruktur erhalten.
Wann Jenkins eine gute Wahl ist
Jenkins kann eine gute Wahl sein, wenn ein Team flexible Abläufe, die Integration verschiedener Werkzeuge oder die Ausführung von Aufgaben in der eigenen Infrastruktur benötigt. Er ist auch dann hilfreich, wenn der Veröffentlichungsprozess einer Anwendung ungewöhnliche Schritte umfasst, die sich nicht leicht in ein einfaches Schema einfügen lassen.
Diese Flexibilität hat ihren Preis: Jemand muss die Konfiguration pflegen und Probleme mit dem Server und den Plugins lösen. Braucht ein kleines Team nach jeder Änderung lediglich einige Tests, kann ein beim Repository verfügbarer CI/CD-Dienst weniger Betreuungsaufwand erfordern.
Beginne vor der Entscheidung mit einem einzigen Ablauf: Code herunterladen, die Anwendung bauen und Tests ausführen. Prüfe, ob du diesen Ablauf zuverlässig wiederholen kannst und wer für seine Wartung verantwortlich sein wird. Ergänze automatische Deployments erst, wenn die Berechtigungen und das Vorgehen zum Zurücknehmen einer fehlerhaften Version feststehen.
Siehe auch: Was ist API?
Lesen Sie auch
