Jenkins Konfiguration versionieren und sichern

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

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.