© Excellent backgrounds/Shutterstock.com
Java Magazin
Continuous Integration

Groove your Jenkins

Beim Thema Continuous Integration gehört Jenkins nach wie vor zu den Besten. Aber den Takt geben immer öfter andere an. Wir geben ihm den Groove zurück. Wir zeigen, wie man mit der Groovy-Job-DSL Builds erstellt und komplexe Abläufe mit der Groovy-Workflow-DSL beschreibt. So let’s get groovy!

Jan Stamer


Die Capitol Versicherung setzt auf Java zur Entwicklung ihrer Backofficeanwendungen. Schon vor Jahren hat sie die erste Anwendung ReBeTol für die Reiseversicherung als Java-Webanwendung realisiert, damals mit Jenkins als Build-Server. Der Fachbereich drängte auf immer kürzere Releasezyklen, der Projektleiter setzte utopischere Zeitpläne, und die Entwickler gingen jeden Tag pünktlich nach 7,5 Stunden nach Hause und alles war gut. Bis der Abteilungsleiter zum Monatsersten den neuen Entwickler Steve W. anschleppte. Der kam frisch von der Uni und kannte jemanden, dessen Mitbewohner mal ein Praktikum bei Google gemacht hatte. Dort, so hatte er aufgeschnappt, liefern sie zehnmal am Tag aus und nennen es „Continuous Delivery“. Dies drang bis zur Führungsriege durch und verlieh ­Steve augenblicklich den Ruf als High Potential aus dem Silicon Valley. Sofort wurde inoffiziell ein Krisenstab aus erfahrenen Entwicklern und Architekten einberufen, die sich nach Dienstschluss trafen, um zu besprechen, wie mit den Flausen des neuen Lieblings vom Chef zu verfahren sei. Man entschloss sich zu einer Flucht nach vorne, bestellte drei Exemplare des Buchs „Continuous Delivery“ [1] und gründete eine Arbeitsgruppe, um dem jungen Hüpfer zu zeigen, dass sie es ebenfalls draufhaben.

Für die Webanwendung ReBeTol wird Jenkins als Build-Server genutzt. Der Kommentar von Steve dazu: „Na immerhin macht ihr schon Continuous-Integra­tion.“ Für ReBeTol gibt es zwei Jenkins-Jobs. Der Job rebetol-build kompiliert die Anwendung und führt die Unit-Tests aus. Der andere rebetol-acceptance-test installiert die Anwendung auf einer Testumgebung und lässt dort die Integrationstests laufen. Die Jenkins-Jobs hat das Team von Hand erstellt und nutzt dabei diverse Plug-ins, die im Jenkins installiert sind.

Builds als Infrastruktur, Infrastruktur als Code

Die Arbeitsgruppe stellt fest, dass die Jenkins-Jobs für das Projekt ReBeTol zur Infrastruktur des Projekts gehören. Infrastruktur, so haben sie sich schlau gemacht, ist auch als Code zu betrachten und wie solcher zu behandeln. Was heißt das konkret? Die Konfiguration der Jobs gehört wie Code in die Versionskontrolle. Änderungen an der Konfiguration werden eingecheckt und dann automatisch in die Infrastruktur übernommen. Oha! Erstes Stirnrunzeln in der Arbeitsgruppe.

In der Zwischenzeit beschloss der Vorstand, auch für die Lebensversicherung eine neue Backofficeanwendung zu entwickeln und startete das Projekt LeBeTol. Hierfür sollte auf bewährte Verfah...

Java Magazin
Continuous Integration

Groove your Jenkins

Beim Thema Continuous Integration gehört Jenkins nach wie vor zu den Besten. Aber den Takt geben immer öfter andere an. Wir geben ihm den Groove zurück. Wir zeigen, wie man mit der Groovy-Job-DSL Builds erstellt und komplexe Abläufe mit der Groovy-Workflow-DSL beschreibt. So let’s get groovy!

Jan Stamer


Die Capitol Versicherung setzt auf Java zur Entwicklung ihrer Backofficeanwendungen. Schon vor Jahren hat sie die erste Anwendung ReBeTol für die Reiseversicherung als Java-Webanwendung realisiert, damals mit Jenkins als Build-Server. Der Fachbereich drängte auf immer kürzere Releasezyklen, der Projektleiter setzte utopischere Zeitpläne, und die Entwickler gingen jeden Tag pünktlich nach 7,5 Stunden nach Hause und alles war gut. Bis der Abteilungsleiter zum Monatsersten den neuen Entwickler Steve W. anschleppte. Der kam frisch von der Uni und kannte jemanden, dessen Mitbewohner mal ein Praktikum bei Google gemacht hatte. Dort, so hatte er aufgeschnappt, liefern sie zehnmal am Tag aus und nennen es „Continuous Delivery“. Dies drang bis zur Führungsriege durch und verlieh ­Steve augenblicklich den Ruf als High Potential aus dem Silicon Valley. Sofort wurde inoffiziell ein Krisenstab aus erfahrenen Entwicklern und Architekten einberufen, die sich nach Dienstschluss trafen, um zu besprechen, wie mit den Flausen des neuen Lieblings vom Chef zu verfahren sei. Man entschloss sich zu einer Flucht nach vorne, bestellte drei Exemplare des Buchs „Continuous Delivery“ [1] und gründete eine Arbeitsgruppe, um dem jungen Hüpfer zu zeigen, dass sie es ebenfalls draufhaben.

Für die Webanwendung ReBeTol wird Jenkins als Build-Server genutzt. Der Kommentar von Steve dazu: „Na immerhin macht ihr schon Continuous-Integra­tion.“ Für ReBeTol gibt es zwei Jenkins-Jobs. Der Job rebetol-build kompiliert die Anwendung und führt die Unit-Tests aus. Der andere rebetol-acceptance-test installiert die Anwendung auf einer Testumgebung und lässt dort die Integrationstests laufen. Die Jenkins-Jobs hat das Team von Hand erstellt und nutzt dabei diverse Plug-ins, die im Jenkins installiert sind.

Builds als Infrastruktur, Infrastruktur als Code

Die Arbeitsgruppe stellt fest, dass die Jenkins-Jobs für das Projekt ReBeTol zur Infrastruktur des Projekts gehören. Infrastruktur, so haben sie sich schlau gemacht, ist auch als Code zu betrachten und wie solcher zu behandeln. Was heißt das konkret? Die Konfiguration der Jobs gehört wie Code in die Versionskontrolle. Änderungen an der Konfiguration werden eingecheckt und dann automatisch in die Infrastruktur übernommen. Oha! Erstes Stirnrunzeln in der Arbeitsgruppe.

In der Zwischenzeit beschloss der Vorstand, auch für die Lebensversicherung eine neue Backofficeanwendung zu entwickeln und startete das Projekt LeBeTol. Hierfür sollte auf bewährte Verfah...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang