Automatisches Build-System für Eclipse-RCP-Anwendungen mit CruiseControl und PDE/Build

Bubbles green, Build is clean

Daniel Meisen

Unabhängig von der Größe einer Anwendung sind die Schritte zur Erstellung eines vollständigen Builds nicht immer trivial. Erfolgt dieser Vorgang nicht automatisiert, sind Aufwand und Fehlerwahrscheinlichkeit mitunter sehr hoch. Ein automatisiertes Build-System minimiert den Aufwand zur Erstellung vollständiger Builds erheblich, führt zu wiederholbaren Ergebnissen und ermöglicht zudem ein frühzeitiges Aufdecken von (Integrations-)Fehlern.

Gerade bei der Entwicklung von Eclipse-RCP-Anwendungen oder Eclipse-Plug-ins verlassen sich Entwickler häufig auf die von der IDE bereitgestellte Funktionalität zur Erzeugung von Builds. Mit den Export-Wizards der PDE (Plug-in Development Environment) lassen sich jedoch nur dann wiederholbare und portable Builds erzeugen, wenn alle Entwickler dieselbe IDE-Konfiguration aufweisen. Weichen die Konfigurationen nur minimal voneinander ab oder wird unter verschiedenen Betriebssystemen entwickelt, ist die Portabilität und Wiederholbarkeit eines Builds nur schwer zu gewährleisten.

Das Ziel sollte es daher in jedem Projekt sein, einen Build-Prozess zu etablieren, der in der Lage ist, per Knopfdruck ein vollständiges Build zu erzeugen (One Step Builds). Existiert ein solcher Build-Prozess einmal, ist der Aufwand für die Erzeugung von CRISP Builds gering.

CRISP Builds

Complete – vollständig
Repeatable – wiederholbar
Informative – informativ
Schedulable – planbar
Portable – portabel

Die Zutaten für ein automatisiertes Build-System sind übersichtlich. Neben der Anwendung, für die das Build-System aufgesetzt werden soll, sind lediglich ein Versionskontrollsystem, ein Build-Skript und ein Werkzeug zur Planung und Erstellung automatisierter Builds notwendig. Das hier beschriebene Build-System setzt dabei ausschließlich auf Open-Source-Komponenten. Zur Erstellung eines Builds wird ANT in Verbindung mit PDE/Build verwendet. Die Planung und Überwachung der automatisierten Builds findet mithilfe von CruiseControl statt. Es wird vorausgesetzt, dass sich die Anwendung bereits unter Versionskontrolle befindet – im gezeigten Beispiel wird von Subversion ausgegangen. Grundsätzlich kann jedes von CruiseControl unterstützte Versionskontrollsystem, wie Subversion, CVS, VisualSourceSafe, ClearCase, Git oder Mercurial, eingesetzt werden.

Continuous Integration

In seiner ursprünglichen Form bezeichnet Continuous Integration eine Entwicklungspraktik, bei der die Entwickler ihre Arbeit häufig – mindestens täglich – integrieren. Nach jeder Integration werden Tests ausgeführt und ein Build der Anwendung erstellt. So können Integrationsfehler frühzeitig aufgedeckt und behoben werden. Aktuelle Continuous-Integreation-Tools unterstützen diesen Prozess, indem sie in regelmäßigen Zeitabständen das Versionskontrollsystem auf Änderungen überprüfen, automatisch den letzten Stand des Quellcodes auschecken, Tests durchführen und Builds erzeugen. In der Regel lassen sich mehrere Build-Strategien definieren, um auch Daily oder Nightly Builds automatisch erzeugen zu können. Den jeweiligen Build-Status können sich Entwickler über verschiedene Kommunikationsmittel zukommen lassen.

CruiseControl

CruiseControl ist ein Werkzeug zur Continuous Integration und unterstützt die Erstellung und Überwachung automatisierter Builds durch eine Vielzahl bereits vorhandener Plug-ins. Ursprünglich wurde CruiseControl von ThoughtWorks entwickelt. Die Firma hat sich jedoch auf die Pflege eines Enterprise Add-Ons für CruiseControl beschränkt und das originäre CruiseControl unter einer BSD-Lizenz als Open-Source-Framework veröffentlicht.

CruiseControl wird über eine zentrale Konfigurationsdatei (config.xml) mitgeteilt, welche Builds zu welchem Zeitpunkt erstellt werden sollen. Es unterstützt gängige Versionskontrollsysteme und Build-Werkzeuge (z.B. ANT, Maven, rake). Durch bereits vorhandene Plug-ins können sich Entwickler den Status eines Builds zeitnah z.B. per E-Mail, RSS-Feed oder Instant Message mitteilen lassen. Weitere Plug-ins, beispielsweise für das X-10-Protokoll, unterstützen das Ansteuern elektrischer Geräte. So kann im Fehlerfall z.B. eine rote und im Erfolgsfall eine grüne Lavalampe eingeschaltet werden. Ein Webinterface ermöglicht den Zugriff auf Protokolle der letzten Builds. Neue Builds können darüber hinaus – auch außerhalb des definierten Zeitplans – manuell erzeugt werden.

PDE/Build

Das Herz des Build-Systems stellt das eigentliche Build-Skript dar. In diesem sind alle Schritte definiert, die notwendig sind, um aus einer Menge von Quellcode und weiteren Ressourcen ein vollständiges Build zu erzeugen. Die Basis des Build-Skripts ist dabei ANT. Über einen separaten Task des Build-Skripts wird der Eclipse antRunner aufgerufen, der wiederum die PDE/Build-Umgebung ausführt. Sie bezieht alle erforderlichen Informationen aus einer projektspezifischen build.properties-Datei. Die PDE/Build-Umgebung ist ein auf ANT-basierendes Build-System für Eclipse-Plug-ins bzw. Eclipse-RCP-basierte Anwendungen. Sie ist Bestandteil der Eclipse IDE und ist im Plug-in org.eclipse.pde.build realisiert. Die Export-Wizards der Eclipse IDE zur Erstellung von Produkten, Anwendungen oder Plug-ins greifen intern ebenfalls auf diese zurück.

Geschrieben von
Daniel Meisen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.