Entwickler-Schulung - Maven und Jenkins

Anfang des Jahres hatte ich die Gelegenheit eine neue Schulung zu konzipieren. Im Auftrag eines Schulungsunternehmens, hielt ich eine Grundlagenschulung zum Thema Maven und Jenkins bei einem Kunden in München. Ziel der Schulung war es bestehende und neue Mitarbeiter des Kunden fit für die Erstellung von Software mittels Maven zu machen. In einem zweiten Schritt wurde in Continuous Integration mit Jenkins eingeführt.

Maven

Am ersten Tag der dreitägigen Schulung drehte sich alles um Apache Maven. Nach einer Einführung in die Konzepte und Ideen von Maven ging es an die Erstellung einer ersten, einfach pom.xml.

Im nächsten Schritt wurde ein Build-Scripts für eine typische JavaEE Applikation erstellt. Das Script besteht aus mehrerem Projekten. Jedes Projekt wird mit einer eigenen POM beschrieben. Alle POMs sind von einer Parent POM abgeleitet. In diesem Parent werden die von allen POMs verwendeten Definitionen zentral abgelegt. Das eigentliche Artefakt (EAR-File) wird ebenfalls durch ein eigenes Build-Script erstellt.

Durch die Abhängigkeit des “ear module” von den beiden eigentlichen Projekten “crm” und “report” wird bei jeder Änderung an diesem Projekten ein neues EAR-File erstellt. Da alle Projekte vom “project” abgeleitet sind, nutzen diese die dort festgelegten Plugin-Versionen und sonstigen Einstellungen.

Jenkins

An den restlichen beiden Tagen wurde das am ersten Tag erstellte Skript in einer Continuous Integration Umgebung mit Jenkins eingesetzt.

Zuvor erläuterte ich die Grundlagen von Jenkins. Dabei wurden die verschiedenen Job-Typen ebenso angesprochen wie die grundlegende Konfiguration von Jenkins. Eingegangen wurde auf die Anbindung von Jenkins an Version Control Systeme wie Subversion oder Git. Dabei kann nicht oft genug wiederholt werden, dass hierzu ein eigener (technischer) Benutzer zu verwenden ist.

Als Übung wurde das am ersten Tag erstellte Script verwendet und hierzu ein Job in Jenkins erstellt. Durch Änderungen in der Quellcodeverwaltung wurde der automatische Bau des Projekts nach dem Einchecken einer Änderung in Subversion getestet.

Jetzt war es an der Zeit eine Einführung in Continuous Integration zu geben. Dabei orientierte ich mich an der Struktur des Buches “Continuous Integration” von Paul Duvall. Damit wird die Motivation zum Einsatz einer Continous Integration Pipeline beschrieben. Jeder einzelnen Schritt wird erläutert und der dahinter stehende Nutzen für die Entwicklung der Software erklärt. Im einzelnen handelt es sich um die folgenden Schritte:

• compile source code

• integrate database

• run tests

• run inspections

• deploy software

Am Ende der Pipeline steht ein einsatzfähiges Artefakt, dass bereits grundlegende Tests bestanden hat. Durch das Deployment auf ein Testsystem können nun weitere Tests und Prüfungen durchgeführt werden.

Die einzelnen Stufen der Pipeline wurden durch entsprechende Jobs in Jenkins abgebildet. Die Jobs bauen aufeinander auf und sind wie Glieder einer Kette aneinander gehängt. Durch die Nutzung von Plugins werden die Abläufe der einzelnen Stufen realisiert. Zur Visualisierung der Pipeline kommt das Build Pipeline Plugin zum Einsatz.

Das Feedback der Teilnehmer war nach den drei Tagen Schulung durchwegs positiv. Mir hat es viel Spass gemacht eine Schulung zu den Themen zu halten, mit denen ich mich gerne beschäftige. Wie bei jeder Schulung habe auch ich einiges dazugelernt.