Jenkins ist der älteste verbreitete Server für Build-Pipelines, selbst betrieben und über Plugins erweitert. Er nimmt Ereignisse aus dem Repository entgegen und führt daraufhin Abläufe aus, die in einer Datei oder in der Oberfläche beschrieben sind.
- Jenkins
Der älteste verbreitete Server für Build-Pipelines, selbst betrieben und über Plugins erweitert.
Beispiel: „Jenkins lief auf einer eigenen Maschine im Haus und baute jede Nacht die ganze Anwendung.“Entstanden 2011 als Abspaltung von Hudson, das bei Sun begann und über Oracle zu einem Streit um den Namen führte. Das Projekt ist offen und lebt von über tausend Erweiterungen.
Abgrenzung zu GitHub Actions: Dieses ist in die Plattform eingebaut und braucht keinen eigenen Server. Jenkins läuft dort, wo man ihn hinstellt.
Wofür Jenkins heute noch steht
Für Abläufe, die im eigenen Netz bleiben müssen. Wo eine Pipeline auf Systeme zugreift, die nicht ins Internet dürfen, ist ein selbst betriebener Server die einfachere Antwort als ein Dienst von außen.
Dazu kommen gewachsene Aufbauten. Viele Unternehmen haben Jahre an Pipelines in Jenkins, und ein Umzug zu einem anderen Dienst heißt, jede davon neu zu schreiben.
Was der eigene Betrieb bedeutet
Eine Maschine mehr. Jenkins braucht Speicher, Aktualisierungen, Sicherungen und eine Anmeldung, die niemand von außen erreicht; die Plugins kommen hinzu, denn jedes ist Code mit Rechten auf dem Server.
Gerade dort liegt die Schwäche: Ein veraltetes Plugin ist eine offene Tür, und die Pipeline hat Zugriff auf Quellcode und Zugangsdaten, siehe Secrets-Verwaltung.
Wann Jenkins die falsche Wahl ist
Für kleine Teams mit Projekten auf GitHub oder GitLab. Dort ist die Pipeline schon eingebaut, kostet keinen Server und keine Pflege, und die Beschreibung liegt im selben Repository wie der Code.
Umgekehrt bleibt Jenkins eine ehrliche Wahl, wo eigene Hardware, eigene Netze und lange gewachsene Abläufe zusammenkommen. Das Werkzeug ist alt, aber es tut, was es soll.