Letzte Woche hörte ich im Zusammenhang mit Continuous Delivery (CD) die These, dass es inzwischen kein Projekt mehr gäbe, dass kein Continuous Integration (CI) praktiziert. Ich bin da nicht ganz so optimistisch. Meiner Erfahrung nach sind z.B. mehrwöchige Featurebranches und explizite Integrationsphasen im Projekt durchaus „noch“ zu finden, und das auch ohne Lupe.
Ohne Zweifel ist CI aber ein Mainstream Thema und damit auch die damit zusammenhängenden Tools wie Jenkins. In einem Projekt, das CI oder sogar CD betreibt, wird der Integrationserver bald zu einer kritischen Komponente und die Konfiguration auf dem Server so wichtig wie Quellcode. Aus diesem Grund ist es eine gute Idee, die Konfiguration der Jobs auf den Integrationsserver sorgfältig zu verwalten – d.h. in einer Versionsverwaltung. Während ein einzelner Job, der mir ein „./gradlew build“ ausführt noch „schnell mal eben“ wieder hergestellt ist, sieht das bei einer mehrstufigen Pipeline von Jobs schon anders aus!
Für den Jenkins kann man zum Sichern der Konfiguration z.B. das „SCM Sync configuration plugin“ verwenden. Das Plugin kümmert sich darum, dass jede Konfigurationsänderung in ein Versionsverwaltungssystem (z.B. git oder svn) gesichert wird. Und natürlich kann die Konfiguration auch aus dem Repository ausgelesen und übernommen werden. Das Plugin erzeugt bei jeder Änderung der Konfiguration einen commit, was u.U. nicht für jeden Einsatzzweck die beste Idee ist. Ein alternativer Ansatz zum Sichern der Konfiguration „von Hand“ anstelle des Plugins ist z.B. hier beschrieben. Ich empfehle bei dieser Lösung zusätzlich noch einen cron job, der Änderungen sichert. Denn was manuell passieren muss, wird auch vergessen… Mich persönlich stören die vielen commits im Repository nicht, so dass ich das Plugin verwendet habe. Nicht alternativ sondern zusätzlich, um sich direkt in der Jenkins Weboberfläche Änderungen von Jobs anzusehen, ist das „JobConfigHistory Plugin“ hilfreich. Dieses Plugin pflegt auch eine Versionshistorie und erlaubt das Wiederherstellen vorheriger Konfigurationsstände, externalisiert diese aber nicht.
Die initiale Konfiguration des nütlichen SCM Sync Plugin ist leider nicht vollständig trivial und hat einige Fallstricke, deshalb beschreibe ich die notwendigen Schritte in Kürze hier in einem weiteren Blogpost.
Mittlerweile gibt es ja auch Tools wie z.B. den jenkins-job-builder (https://opendev.org/jjb/jenkins-job-builder). Zusammen mit bash kann man in yaml Dateien die Konfigurationen beschreiben und anschließend wird der jeweilige Job in Jenkins importiert.
Aber auch auf Jenkins Seite hat sich mit Pipelines einiges geändert.
Hallo Kristian,
Die Benachrichtigung über Deinen Kommentar ist leider verloren gegangen, deshalb entschuldige bitte die sehr späte Antwort und trotzdem vielen Dank für den Kommentar.
Wie fast alles ist auch dieser Ansatz ein Kind seiner Zeit. Auf jeden Fall hat sich Welt seit diesem Blogartikel viele Runden weitergedreht. Die Jenkins Jobs würden ich heute sicher eher „ganz normal“ als Jenkins Pipeline Code beschreiben und versionieren oder sie gleich mit der Job DSL und seed Jobs erzeugen. Aber das gab es „damals“ noch nicht so einfach. Danke für den Hinweis, dass dieser alte Text heute etwas verwirrend sein kann. Ich werde eine Aktualisierung in Betracht ziehen.
Viele Grüße
Felix