Build-Automatisierung mit Cruisecontrol

Im Softwaretechnikpraktikum meines Studienganges habe ich als Software-Qualitätsbeauftragter die Build-Management-Software Cruisecontrol eingesetzt.
Hier will ich von einen Erfahrungen mit Cruisecontrol berichten:

Die Software arbeitet im Grunde wie folgt:
Sie überprüft die Quellcodeverwaltung eines Software in regelmäßigen Abständen (im SoPra-Projekt zweimal am Tag) und erstellt einen neuen Build der Software.
Dabei können dann System wie ant oder maven zum Einsatz kommen, um den Ablauf des Build-Vorganges zu steuern (im Projekt "ant").
Die Ergebnisse jedes Build-Vorganges werden dann auf einer Webseite veröffentlicht und per Email an die Entwickler verschickt. Es gibt sogar eine Erweiterung von Cruisecontrol zum Ansteuern eines Blicklichtes, dass als Alarmzeichen in einem Projektbüro dient.

Zusätzlich zu dem reinen Compilieren haben wir auch jedesmal die javadoc-Dokumentation aktuallisiert, die Einhaltung der Codekonventionen mit Checkstyle überprüft und natürlich die JUnit-Testfälle ausgeführt. Gleichzeitig wurde auch die Codeabdeckung der Testfälle mit emma ermittelt.

Die Automatisierung der Builds und der Tests hat sich meiner Meinung nach Bewährung.
Cruisecontrol spielt die zentrale Rolle und ist (bis auf die kleinen Macken) mittlerweile wirklich gut gelungen.
Der Server wurde durch Checkstyle und Emma erweitert und Cruisecontrol arbeitet auch gut mit diesen Tools zusammen.

Aber Cruisecontrol hat kleine Macken.
- Für jede Änderung an der Konfiguration muss der Server gestoppt und neugestartet werden.
- Ich habe nicht vorausgefunden, wie man Cruisecontrol so einstellt, dass zu bestimmten Tageszeiten also z.B. jedes Mal um acht Uhr, eine Build gestartet wird.
- Auch scheint es nicht so gut möglich zu sein die Software so einzustellen, dass zum Beispiel einmal am Tag ein volles Build (z.B. mit Codeüberdeckung und javadoc) erstellt wird und sonst (alle 10 Minuten) nur ein kleines Build. Dafür scheinen zwei seperate Cruisecontrol Projekte notwendig zu sein. Schade, diese Funktion hätte ich gut gebrauchen können.
- Es werden bei jedem Build (zumindest so wie wir es eingestellt hatten) unheimliche Mengen an Daten erstellt. Jeder Build belegte mehr als 10 Megabyte auf der Festplatte. Man sollte also eine Menge Festplattenplatz freihalten.
- Die Emails, die an die Entwicklern verschickt werden, werden sehr schnell sehr groß. Die Mails waren im Projekt im Schnitt ca. 500 Kilobyte groß. Die Entwicklern, die nur ein Modem-Anschluss haben, waren davon nicht begeistert.

Mein Fazit ist: Trotz einiger Macken ist Cruisecontrol in Projekten auch kurzfristig einsetzbar und kann helfen die Codequalität zu erhöhen. Insbesondere dadurch das Entwickler, die fehlerhaften Code einchecken auffallen und per Mail angeprangert werden. Im Softwaretechnikpraktikum ist es aber so gewesen, dass die Sanktionsmöglichkeiten fehlen, um guten Code auch von allen einzufordern.
Gerade aber die Möglichkeit den gesamten Buildprozess auf einem Server integieren, hilft dem Team einen Überblick über den aktuellen Stand der Software zu geben.
Schon vor mehr als zwei Jahren habe ich einmal einen Bericht über Cruisecontrol im Java Magazin gelesen, damals habe ich es aber nicht eingesetzt, da die Dokumentation noch sehr schlecht gewesen ist. Dies hat sich geändert mit User Guides und dem Cruisecontrol Wiki werden viele Fragen beantwortet.