© Sebastian Duda, 123RF.com

Beim Erstellen von Software unterstützen Buildtools und Buildsysteme die Entwickler und ihre Teams. In einem Überblick zeigt dieser Artikel den Klassiker Make und seine Alternativen bis zu Maven und den Buildservices. Dazu gibt’s Empfehlungen für den Einsatz in verschiedenen Szenarien.

Auch in Zeiten automatischer Codegeneratoren bleiben die großen Bauherren moderner Software immer noch menschlich. Ihre Werkzeuge sind Editoren, Compiler, Debugger und Sourcecode-Verwaltungssysteme (siehe den entsprechenden Artikel in diesem Schwerpunkt).

Zusammen ergeben diese Programme den Arbeitsbereich im Umfeld der Software-Entwicklungstools und bilden zusammen das jeweilige Buildsystem für die Software. Eine genauere Abgrenzung und Begriffsdefinition gestaltet sich dabei eher schwierig. Auch die Wikipedia leitet automatisch vom Begriff Buildsystem zum Artikel über Erstellungsprozesse weiter, beschränkt sich dort aber auf die Beschreibung von Kompilation und Linken mit Bibliotheken.

Ohne eine detailliertere Definition und Abgrenzung zu versuchen, versteht dieser Artikel im Folgenden unter Buildtools die eigentlichen Werkzeuge für die automatisierte Software-Erstellung. Buildsysteme bauen darauf auf, sie nutzen Buildtools zusammen mit anderen Komponenten. Das gibt es in den unterschiedlichsten Ausprägungen, vom persönlichen Projekt bis hin zu Software, die möglichst fehlerfrei auf Millionen von Geräten installiert sein soll. Dementsprechend sind auch die Anforderungen der Entwickler an die Tool-Landschaft höchst unterschiedlich, sie reichen vom einfachen Werkzeug bis zu komplexen Szenarien.

Das einfachste Buildsystem ist die Entwicklungsumgebung, mit der der Entwickler Tag für Tag kodiert, kompiliert und Fehler sucht. Bei modernen Umgebungen wie zum Beispiel Eclipse konzentriert er sich da ganz auf den Code. Außer der Definition von externen Abhängigkeiten (zum Beispiel Bibliotheken) ist wenig Input notwendig. Der Build erfolgt automatisch und per Knopfdruck (siehe Abbildung 1).

Abbildung 1: Der automatische Build hört bei Eclipse auf ein Mausklick-Kommando.

Das funktioniert im Allgemeinen sehr gut und deckt die Bedürfnisse von vielen kleinen Ein-Personen-Projekten ab. Schwierig wird das Ganze erst dann, wenn das Programm zum Beispiel besondere Compilerflags für Optimierungen benötigt. Diese selten genutzten Optionen sind dann oft in den “dunklen Ecken” der Entwicklungsumgebung versteckt – selten genutzte Eingabedialoge, die man erst finden muss.

Arbeiten mehrere Entwickler zusammen, gibt es weitere Probleme. Der Code-Austausch funktioniert zwar sehr gut über per Plugin angeschlossene Sourcecode-Verwaltungssysteme wie CVS oder Subversion. Aber identische Projekteinstellungen lassen sich damit nicht so einfach garantieren.

Wichtiger ist jedoch ein Problem, das sich bei der Veröffentlichung des Programms stellt. Die Veröffentlichung der Quellen reicht nämlich selten. Benutzer wollen auch wissen, wie sie aus den Quellen das Programm bauen. Wer den Code aktiv weiterentwickeln will, schätzt die Anwesenheit aller Projektdateien. Anwender dagegen sind meist nur am Ergebnis interessiert, haben keine Programmierambitionen und möchten keine komplette Entwicklungsumgebung installieren, nur um die Software zu erstellen.

Formalisierte Build-Beschreibungen

Hier kommen die Buildtools ins Spiel. Zusätzlich zu den eigentlichen Programmquellen verfasst der Entwickler eine formalisierte Beschreibung des Build (das »Makefile« ). Diese Datei definiert die Schritte (Kompilation, Linken) zusammen mit den notwendigen Optionen für alle beteiligten Programme (Compiler, Linker). Der Anwender benötigt nur noch diese Programme sowie das Buildtool. Mit einem einfachen Aufruf erzeugt er damit die Software aus den Quellen, ohne sich um die Details zu kümmern.

Theoretisch würde auch ein Shellskript als Makefile genügen, insbesondere für den Endanwender. Doch manche Anforderungen kann es nicht erfüllen. Der Entwickler startet beispielsweise unzählige Edit-Compile-Link-Testzyklen, bis das Programm fertig ist. Da das Kompilieren und das Linken zeitaufwändig sind, übersetzen Buildtools über definierte Abhängigkeiten nur die seit dem letzten Lauf geänderten Dateien neu.

Diese Abhängigkeiten muss der Entwickler manuell definieren oder er greift vielleicht auf die Fähigkeiten des Compilers zurück. In aller Regel haben Buildtools auch eingebaute Regelsätze: So kompiliert GNU-Make C-Quellen bereits mit

$(CC) -c $(CPPFLAGS) $(CFLAGS) Quelle.c -o  Quelle.o

solange der Anwender keine zusätzlichen Anweisungen gibt.

GNU-Make – der Klassiker

Make, insbesondere wegen seiner aktiven Weiterentwicklung und seines großen Funktionsumfangs, ist das omnipräsente, aber nicht unumstrittene Buildtool schlechthin. Wie beschrieben kodieren Entwickler ihre Regelsätze im Makefile so, dass Make ihr Projekt möglichst effizient baut. Beliebte Tricks dabei sind Rekursionen (Make ruft sich selbst auf), hierarchische Verzeichnisbäume mit Sub-Makes oder selbstmodifizierende Makefiles. Um komplexe Projekte im Griff zu behalten, muss der Entwickler auch ein Experte für Make sein.

Ein zentraler Kritikpunkt an Make ist seine obskure Syntax. Kommandos müssen zum Beispiel per Tabulator eingerückt sein, sonst gibt es Probleme. Da viele Editoren Tabs automatisch in Leerzeichen umwandeln, sind triviale Fehler programmiert. Aber auch Zeilen wie

ifneq (,$(findstring $(TYPE),$(CD_TYPES)))
TARGET := iso
else
TARGET := img
endif

muten sehr altertümlich an. Dabei sind Bedingungen und Funktionen erst nach und nach Teil von Make geworden, vorher ging vieles nicht oder nur über aufgerufene Shellkommandos.

Make und Autoconf: Das GNU-Buildsystem

Wichtigster Kritikpunkt an Make ist aber, dass sich damit keine portablen, über mehrere Betriebssysteme hinweg gültigen Builddefinitionen schreiben lassen. Zu unterschiedlich sind Konventionen, Pfade, Shells, Compiler und so weiter auf den verschiedenen Plattformen. Hier kommen die Buildsysteme ins Spiel. Sie erzeugen aus abstrakteren Definitionen Plattform- und Tool-spezifische Makefiles. Bekanntestes Beispiel ist das GNU-Buildsystem (GBS) mit den Tools Autoconf und Automake.

Es gibt kaum einen Linux-Anwender, der nicht früher oder später den klassischen Dreischritt »configure; make; make install« aufruft. Er erzeugt dabei mit Autoconf das von ihm dann mit dem Quellcode ausgelieferte Configureskript. Dieses wiederum überprüft die Plattform des Anwenders und erzeugt daraus die eigentlichen Makefiles.

Das GBS ist fast omnipräsent, aber wichtige Projekte haben sich davon abgewandt. So verwendet das KDE-Projekt inzwischen Cmake [1]. Dafür gibt es mehrere Gründe. Ein Problem von Autoconf ist es, dass es die plattformspezifischen Prüfungen über so genannte M4-Makros definiert. M4 ist ein leistungsstarker, aber altertümlicher Textprozessor mit einer schwierigen Low-Level-Syntax. Damit ist einerseits die Einstiegshürde groß, andererseits die Pflege aufwändig.

Ein weiterer Kritikpunkt am GBS liegt im Mechanismus selbst begründet. Das Configureskript untersucht die aktuelle Plattform und baut dafür ein passendes Makefile. Cross-Compilation, für Embedded Devices eine Standardanforderung, ist damit prinzipbedingt schwierig bis unmöglich.

Zu guter Letzt unterstützt das GBS (verständlicherweise) nur GNU-Make als Buildtool. Cmake dagegen kann aus seinen Definitionen heraus Make-Beschreibungen für verschiedenste Tools erstellen. Die Liste ist lang, es unterstützt unter anderem Borland und Watcom Make sowie Microsofts Nmake. Neben Makefiles erzeugt Cmake auch noch Projektdateien für Eclipse CDT, Microsoft Visual Studio und Kdevelop.

Eine weitere Alternative zum GBS ist Trolltechs Qmake [2]. Doch die Namen täuschen, Cmake und Qmake sind keine Make-Alternativen, sondern beide Makefile-Generatoren.

Das Bessere ist des Guten Feind

Natürlich gibt es nicht nur Kritik an Make, sondern auch Anstrengungen, es durch eine bessere Alternative zu ersetzen. Abbildung 2 zeigt die Einträge im Softwareverzeichnis der Free Software Foundation [3]. Die Liste ist aber nicht vollständig, [4] hat noch weitere Links, und auch die Suche über die Softwarekategorien bei Sourceforge findet viele weitere Treffer.

Abbildung 2: Im Softwareverzeichnis der Free Software Foundation finden sich zahlreiche Make-Alternativen.

Bei der großen Auswahl sollte jeder etwas nach seinem Geschmack finden. Neben dem populären Ant (siehe weiter unten) sei insbesondere auf Scons [5] verwiesen. Scons ist in Python implementiert und verwendet Python-Syntax für die Formulierung der Buildregeln. Sein Vorgänger ist Cons [6], dessen Regeln an Perl angelehnt sind. Scons gilt als leistungsstark und einfach erweiterbar, aber auch als langsam.

Bei allen Alternativen muss der Entwickler aber beachten, dass ein einfacheres Buildtool als Make die Arbeit für ihn selbst erleichtern mag, aber für die Nutzer seiner Software eine Einstiegshürde aufstellt. Wer erst ein esoterisches Maketool herunterladen und bauen muss, um damit die eigentliche Software zusammenzustellen, greift dann doch eher zu einer alternativen Software. Unabhängig von dieser Erwägung haben sich in speziellen Ökosystemen eigene Buildtool-Standards durchgesetzt. Prominentestes Beispiel dafür ist Java.

Ant: Java ist anders

Dass Make seine Schwächen hat, war auch schon vor Java bekannt. Mit Java hat aber ein Grundkonzept von Make seine Gültigkeit verloren. Java-Quellcode-Dateien können nicht nur in einem zirkulären, sondern sogar in einem zum Kompilationszeitpunkt undefinierten Abhängigkeitsverhältnis stehen. Make kann also auch kein minimales Set an auszuführenden Kommandos berechnen, sondern muss alle Quelldateien sowieso erneut kompilieren.

Damit lag es nahe, ein neues, auf Java ausgerichtetes Buildtool zu entwerfen. Da auch XML aus derselben Technologiegeneration wie Java stammt, ist das Ergebnis eine in einer XML-Sprache definierte Buildanweisung, die ein Java-Programm (nach der fleißigen Ameise Ant genannt) verarbeitet. Logischerweise nennt sich das »Makefile« hier dann auch »build.xml« .

Leider ist XML eine Dokumentensprache und keine Programmiersprache und gedacht für den Informationsaustausch zwischen Computerprogrammen. Damit hat Ant ähnliche Probleme wie Make. Für Entwickler ist das Schreiben von Ant-Makefiles trotz aller Editor-Unterstützung für XML eine fehleranfällige Geschichte. Außerdem ist die Formulierung etwa von Bedingungen und Schleifen innerhalb der Buildanweisungen etwas gestelzt. Listing 1 zeigt ein Beispiel aus einer »build.xml« .

01 <target name="compile-tools" description="Compile taglet/doclet">
02 <fail message="property jdk.home is undefined!" unless="jdk.home"/>
03 <mkdir dir="${build.home}/tools"/>
04 <javac srcdir="${src.home}"
05 destdir="${build.home}/tools"
06 includes="de/bablokb/tools/**"
07 classpathref="classpath.tools"
08 debug="${compile.debug}"
09 deprecation="${compile.deprecation}"
10 optimize="${compile.optimize}">
11 </javac>
12 </target>

Der Java-Standard

Trotz aller Nachteile ist Ant einer der De-facto-Standards für die Java-Entwicklung. Es hat sich durchgesetzt und eine eigene Abstammungslinie für weitere Buildtools angestoßen, weil es per Plugins erweiterbar ist, seine Java- und XML-Zentriertheit eine gute Tool-Integration erlaubt und dadurch gerade im Zusammenspiel in größeren Umgebungen mit weiteren Komponenten Teil eines sehr mächtigen Entwicklungs- und Buildsystems sein kann. Ein oftmals entscheidender Punkt, der über die rein technischen Aspekte hinausgeht, ist aber die Erweiterung der Perspektive von Buildtools und Buildsystemen auf die Bedürfnisse großer Unternehmen, die insbesondere die großen Enterprise-Java-Umgebungen vorangetrieben haben.

Mehr als Configure-Make-Install

Beim GBS und seinen Epigonen wie Cmake und Qmake steht ein sehr eingeschränkter Teil des Entwicklungsprozesses im Vordergrund. Die Software ist geschrieben und liegt im Quelltext vor. Jetzt gilt es, sie für die Zielplattform zu kompilieren. Eventuelle weitere Schritte wie das Bauen von Installationspaketen im RPM- oder Deb-Format und deren Installation stehen nicht im Fokus.

Bei Java sind neue Aspekte hinzugekommen, die inzwischen zumindest teilweise auch andere Programmentwicklungs-Systeme übernommen haben. Unit-Testing gehört als integraler Bestandteil in den Entwicklungsprozess und erweitert den Edit-Compile-Link-Zyklus. Darüber hinaus spielt sich Java zum überwiegenden Teil auf dem Server ab. Paketierung ist somit ein notwendiger Bestandteil des Entwicklungsprozesses.

Ohne Paketierung gibt es kein Deployment. Das Deployment ist auch nicht mehr nur die einfache Installation auf einem Rechner, sondern ist abhängig von der Zielumgebung. Schon während der Entwicklung muss das Buildsystem mehrere dieser Umgebungen, typischerweise Entwicklung, Test, Freigabe, eventuell sogar Produktion, unterstützen.

Deployment

Die Installation in verschiedenen Umgebungen erhöht die Komplexität deutlich, denn jede Umgebung hat andere Servernamen, Datenbanken, Benutzerkonten und so weiter, alle manuell anpassen ist fehleranfällig und aufwändig. Hier muss das Buildsystem auf Knopfdruck alle Konfigurations- und Paketierungsschritte für die Umgebung automatisch ausführen. Idealerweise spielt das Buildsystem die neue Softwareversion auch direkt in den Anwendungsserver ein.

In kleinen Umgebungen bieten Eclipse oder seine kommerziellen Varianten als Entwicklungsumgebung viele der angesprochenen Funktionen, zum Beispiel einen integrierten Applikationsserver mit einer kleinen Datenbank. Große Umgebungen mit vielen Entwicklern, aufgeteilt in Teilprojekte, nutzen dann dedizierte Test- und Freigabe-Umgebungen. Den Entwicklungsprozess halten ein Vorgehensmodell sowie ein mehr und mehr komplexes Buildsystem zusammen. Letzteres ist selten ein monolithisches System, sondern vielfach eine Sammlung von Tools, Skripten oder Best Practices.

Maven

Der Best-of-Bread-Ansatz hat Vor- und Nachteile. Die eingesetzten Tools sind für ihren Zweck optimal, eine bessere Integration wäre aber oft wünschenswert. Auch dafür gibt es Software, die den Gedanken des Buildsystems aus der Erfahrung heraus weiterentwickelt.

Maven [7] ist ein solches System. Es stellt Konvention vor Konfiguration. Das bedeutet: Je enger sich Projekte in ihrer Struktur und den Entwicklungsschritten an das Maven-Modell halten, umso kleiner fällt das Buildfile aus, da Maven stark auf eingebaute Regeln und Verhaltensweisen aufbaut. Maven arbeitet also normativ, denn selbst das Verzeichnislayout der Quellen ist vorgegeben. Wer auf seinem individuellen Weg besteht, wird mit Maven nicht glücklich. Man kann zwar alles konfigurieren, aber der Aufwand wird immens.

Ein weiterer wichtiger Aspekt von Maven ist seine deklarative Natur. Statt eines Makefile definiert der Entwickler sein so genanntes POM, das Project Object Model. In dieser XML-Datei spezifiziert er, wie seine Komponenten aussehen und welche Projekt- und Bibliotheks-Abhängigkeiten es gibt. Die üblichen Buildziele und Buildregeln stehen nicht im Zentrum, zumindest in der Theorie.

Maven führt eine Reihe nützlicher Konzepte ein: Entwickler hinterlegen Bibliotheksabhängigkeiten im Buildfile und Maven lädt bei Bedarf während des Build aktuelle Bibliotheksversionen aus öffentlichen oder privaten Repositories herunter. Den Ablauf steuert der Anwender bei bedarf feingranular über Versionsattribute. Maven-Repositories könnten in die Rolle wachsen, die zum Beispiel das CPAN für Perl spielt.

Phasen

Ein zentrales Maven-Feature sind die Lifecycles, die wiederum aus einzelnen Phasen bestehen. Der Clean-Lifecycle etwa enthält die Phasen »pre-clean« , »clean« und »post-clean« , der Default-Lifecycle erstreckt sich entsprechend von »validate« über »compile« , »test« , »package« bis hin zu »deploy« .

Phasen wiederum sind verknüpft mit den so genannten Goals von Plugins, die dann die eigentliche Arbeit tun. Abhängig vom Package-Typ des Projekts sind verschiedene Default-Goals an die Phasen geknüpft. Für Jars ist das zum Beispiel das »jar« -Goal des Jar-Plugin. Konfigurationsaufwand steht hier wieder nur für Entwickler an, die etwas anderes wollen, als der Maven-Standard vorgibt.

Ein drittes wichtiges Feature von Maven sind die Buildprofile. Diese kapseln umgebungsspezifische Konfigurationen für ein Projekt, zum Beispiel Servernamen, Datenbankverbindungen, Benutzer und so weiter. Hier gibt es Unterschiede nicht nur für jede produktive Plattform, sondern auch innerhalb des Entwicklungsprozesses, je nachdem, ob gerade ein Deployment auf eine Test- oder Produktionsumgebung stattfindet.

All das sieht vom Konzept her gut durchdacht aus, hier sind Erfahrungen aus echten Projekten sowie aus der Vergangenheit eingeflossen. Maven gibt es seit Anfang Oktober in der Version 3.0. Wer auf der grünen Wiese mit einem Projekt anfängt, das eine gewisse Komplexitätsstufe erreichen wird, der sollte Maven auf alle Fälle in Betracht ziehen. Existierende Projekte nach Maven zu portieren, könnte dagegen wenig Vorteile bringen, abhängig davon, wie viele Spezialitäten sich über die Zeit angesammelt haben.

Jenseits von Maven

Maven steht nicht alleine als großes Buildsystem zur Verfügung. Neben kommerziellen Spin-offs wie Nexus Professional gibt es auch unter dem Apache-Dach weitere Alternativen. Buildr [8] zum Beispiel unterstützt Maven-Repositories, formuliert sein Buildfile jedoch in Ruby-Syntax. Damit fällt die Geschwätzigkeit und Sperrigkeit von XML weg. Weitere Alternativen sind Ivy [9], ein Ant-Subprojekt, oder Gradle (implementiert in Groovy, [10]). Buildr und Gradle erweisen sich auch als flexibler als Maven, da sie nicht dessen normativen Ansatz verfolgen. Der Entwickler bestimmt hier selbst, wie sein Projekt aussieht.

Unabhängig von Implementationsdetails und Philosophie gibt es aber im Entwicklungsprozess liegende Anforderungen, die auch ein System wie Maven nicht abdecken kann. Wirklich große und komplexe Projekte, an denen mehrere Teams gleichzeitig arbeiten oder die sehr viele unterschiedliche Anwendungsfälle abdecken, lassen sich nicht mehr auf den einzelnen Entwickler-PCs bauen und testen. Hier sind Buildserver gefragt, die die aktuellen Quellen verarbeiten und typischerweise nachts einen kompletten Build samt Tests anstoßen. Durch den regelmäßigen Versuch, alle aktuellen Änderungen zusammenzuführen, fallen Fehler so früh wie möglich auf. Das Stichwort hierzu lautet Continuous Integration, der passende Server Hudson [10].

Natürlich wollen Entwickler, Projektverantwortliche, Tester und Anwender auch passende Reports. Wie viel hat geklappt, was ging wo schief, gibt es eine neue Version zum Testen? Idealerweise werden die fertig gebauten Pakete gleich auf einem Server installiert oder liegen auf entsprechenden Webservern zum Download bereit.

Entwicklungshilfe mit Bretzn

Unter dem offenbar fränkisch kolorierten Namen Bretzn tritt derweil ein Projekt an, das es sich zum Ziel gemacht hat, Software quasi per Mausklick publizierbar zu machen. Das Gebäckstück kam als Name ins Spiel, weil dabei “Benutzer, Entwickler und die Anwendung an einem gleichsam wie eine Laugenbreze gewundenen Strang ziehen.” (Entwickler Frank Karlitschek zum Linux-Magazin, (Abbildung 3). Er gibt gerne zu, dass der Name “recht spontan im Umfeld der Open Suse Conferenz 2011 in Nürnberg entstanden” sei. Dort hielt Karlitschek einen Vortrag und stellte kurz vor Beginn fest, dass das Projekt, an dem auch andere prominente Entwickler wie Sebastian Kügler und Dan Leinier Turthra Jensen seit drei Monaten gearbeitet hatten, noch keinen Namen hatte.

Abbildung 3: Bretzn will Entwickler, Anwender und die Applikation einander näher bringen.

Bretzn hilft

Auf der Basis der Open Collaboration Services will Bretzn dem Entwickler die meist als lästig empfundene Aufgabe der Vermarktung und Veröffentlichung abnehmen. Dazu setzt Bretzn dort an, wo die eigentliche Software-Entwicklung bereits zu Ende scheint: Beim Kompilieren und Paketieren für verschiedene Plattformen, beim Gestalten und der Pflege einer Projekt-Webseite und regelmäßigen Announcements.

Bretzn übernimmt vier Aufgaben: Paketbau, Veröffentlichung, Marketing und das Sammeln von Feedback für die Entwickler. “All das lästige Zeug, das Programmierer von der eigentlichen Arbeit abhält, fällt damit hoffentlich weg.” (Karlitschek). Der Bau-Abschnitt des fertigen Framework bietet dabei IDEs für Buildservices und setzt auf Lubos Lunaks OBS-Generator, um auch Cross-Plattform-Buildfiles zu erstellen. Beim Veröffentlichen landet die neue Version im Idealfall gleich in zahlreichen App-Stores, während Bretzn schon die passenden Announcements via Facebook, Twitter, RSS-Feeds und dem Social Desktop verschickt.

Laugen-API

Mit Bretzn publizierte Applikationen können sowohl frei als auch kostenpflichtig sein. Etwaige Einnahmen gehen direkt an den oder die Entwickler. Darüber hinaus ermöglicht das API heute bereits Screenshots, Kategorien, Changelogs, Kommentare, Bewertungen, Suche und Updates. Das Bretzn-API ist vollständig offen und basiert auf den OCS-Diensten von Freedesktop.org. Laut Karlitschek verwenden sie heute bereits KDE, Gnome und Meego. Neben den Open-Desktop-Webseiten um Kde-apps.org gibt es einen Qt-Client, die Meego Garage (Abbildung 4) und sowohl eine KDE- als auch eine Gnome-Anwendung. Die Anbindung an Nokias Ovi-Store, Appup und andere Projekte ist ebenfalls in Arbeit.

Abbildung 4: Neben Clients für KDE und Gnome funktioniert Bretzn auch mit Meegos Garage. Möglich macht dies das API der Open Collaboration Services, optional auch mit dem Open Suse Build Service.

Kartlitschek zur Roadmap: “Das Projekt ist zu drei Viertel fertig, wir planen eine Veröffentlichung im Dezember. Und wir arbeiten zusammen mit anderen Entwicklern auch an dem Proof of Concept für den Suse App Shop, der mit Open Suse 11.4 kommen soll. Wer alle Features testen will, sollte sich den KDE-Client GHNS (Get Hot New Stuff) ansehen.”[17](Markus Feilner)

Bauen mit Buildbot

Selbstverständlich gibt es auch für das automatische, verteilte Bauen verschiedene Open-Source-Lösungen. Wenn es nur um Skalierung geht, hilft Distcc [12]. Umfassenderes bieten Buildbot [13] oder andere Alternativen. Die Apache-Seite [14] verlinkt zu Buildservern, die die Apache Foundation betreibt. Die laufen auch unter unterschiedlichen Produkten, ein Zeichen für die positive Konkurrenz der Lösungen untereinander.

Der Apache-Buildbot-Service für eigene Apache-Projekte zeigt die Leistungsfähigkeit eines solchen Systems. Die Seite [15] verlinkt zu mehreren Reports, um den aktuellen Status der diversen Projekte zu verfolgen (Abbildung 5).

Abbildung 5: Der Apache-Buildbot-Service zeigt den aktuellen Buildstatus der Apache-Projekte an.

Öffentlichen Buildservices mit einer kompletten Infrastruktur (Code-Hosting, Web, Buildsysteme und Buildserver, Bugtracker und so weiter) wird sicher die Zukunft gehören. Als Beispiel sei hier nur der Open Suse Build Service [16] genannt, der mit News um Meego und Bretzn (Kasten “Entwicklungshilfe mit Bretzn”) in letzter Zeit viel Aufmerksamkeit erhielt.

Darüber hinaus?

Bei allen hier vorgestellten Produkten steht letztlich der Kern des Software-Entwicklungsprozess im Mittelpunkt. Aber das reicht meist nicht. Ein Bugtracker etwa hat mit einem Buildsystem nur am Rande zu tun, ist aber gleichwohl ein unverzichtbarer Bestandteil des Software-Bauens. Ebenso sieht es aus mit dem Freigabeprozess, mit Anforderungsanalyse, Dokumentation und mit dem Auditing, zum Beispiel bezüglich Security oder Softwarestandards. Enterprise-Lösungen wie IBMs Jazz [18] versuchen hier die sprichwörtliche Eier legende Wollmilchsau zu bieten. Die Infrastrukturanforderungen für ein solches System sind immens, der Supportaufwand auch. So ein großes System rechnet sich – wenn überhaupt – nur langfristig.

Angesichts der Tatsache, dass die Verfahren und Tools der Software-Entwicklung immer einem regen Wandel unterworfen waren und sind, stellt sich die Frage, ob man überhaupt auf ein so hoch integriertes System setzen soll. Bis sich alle an der Entwicklung Beteiligten auf die neuen Werkzeuge eingestellt haben und die Prozesse sauber und effizient laufen, hat sich die Welt schon weitergedreht. Besser erscheinen kleinere, gut anpassbare Tools, die sich dank offener Schnittstellen an etablierte Systeme wie Mail, Bugtracker und so weiter einer Firma anschließen lassen.

Fazit

Buildtools und Buildsysteme gibt es passend zu jeder Projektgröße. Wer auf der grünen Wiese anfängt, sollte ein System wählen, das der absehbaren Komplexität und dem Umfang seines Projekts entspricht. Wer seine aktuelle Buildumgebung eher als Hemmschuh, nicht als produktivitätssteigernd empfindet, sollte umsteigen. Projektverantwortliche kommen dabei um Evaluierung und Abgleich an eigene Bedürfnisse nicht herum, da die Webseiten der hier vorgestellten Tools alle ein sehr gutes Marketing betreiben und jeweils Einfachheit, Flexibilität und Skalierung versprechen.

Wichtiger als ein möglichst großer Funktionsumfang oder ein möglichst kleines Makefile sind Offenheit, Schnittstellen, Stabilität und Verbreitung. Bei aller Tool-Unterstützung sollte klar sein, dass ein gutes Buildsystem kein Selbstläufer ist, sondern immer dedizierte Unterstützung von Fachleuten benötigt.