Der Buildprozess ist mit Ant umgesetzt. Die Ant-Builddateien werden in einem eigenen Projekt (in dem vor allem das Konfigurationsmanagement arbeitet) versioniert abgelegt. Jedes Produkt hat eine eigene Builddatei, jedem Produktrelease entspricht ein Target in dieser Builddatei. Die Builddateien importieren eine zentrale Builddatei, die für alle Erben die Funktionen des Buildprozesses bereithält. In den Eclipse-Projekten selbst gibt es keine Ant-Builddateien des Buildprozesses.
Für eine Analyse des Buildskriptes müssen folgende Ant Funktionen verstanden werden:
<!-- task definieren -->
<taskdef name="mytask" classname="full.qualified.name" classpath="${cp}" />
:
<target ..>
:
<!-- task nutzen -->
<mytask prop1="abc" .. />
</target>
In diesem Buildprozess wird ein eigener Task benötigt, der in XML Dateien XPath Ausdrücke auswertet.
Eclipse erlaubt die Festlegung gegenseitiger Abhängigkeiten zwischen Projekten. Die Unterstützung dafür ist umfassend und sauber (Debugging, Navigation und Suche, Compile-Reihenfolge). Aus diesem Grund ist für den skizzierten Buildprozess das Dependency Management komplett in der Verantwortung der IDE gelassen worden. Für die Entwicklung ist zudem auf ein Umschalten der Abhängigkeiten von releasedten Projekten zu ihren Sourcen und zurück komplett verzichtet worden (in der Teminologie von Maven wird also immer Snapshot-basiert gearbeitet). Dieses Vorgehen nimmt eine große Last von den Schultern der Entwickler und verlagert sie zurück zum KM, welches nun im Rahmen des Buildprozesses stabile Releasestände generieren muss.
Eclipse hat eine ausgereifte Integration von Subversion (ich beziehe mich auf das Ganymede Release von Eclipse und Subclipse). Das Anlegen von Branches und den Import von Projekten aus einem Subversion Repository (also den Checkout) kann man damit sicher und komfortabel über die Benutzeroberfläche abwickeln. Für die komplette Entwicklungstätigkeit und für den Großteil der Aufgaben des KM kommt man so ohne SVN Client Console über die Runden.
Ganze Produkte können über Eclipse-Projektsets gebündelt und verwaltet (versioniert) werden. Die Einrichtung einer einsatzbereiten Entwicklungsumgebung mit allen Projekten kann mit etwas Übung dann rasend schnell erfolgen.
Subversion verwaltet jede Änderung am Repository als sequentielle Transaktionen. Jede Transaktion inkrementiert einen internen Zähler: die Revisionsnummer. Eine Revisionsnummer adressiert damit zuverlässig einen konsistenten Stand des Repositorys. Auf dieser Grundlage sind in diesem Buildprozess Tags realisiert. Auf Kopien, seien sie bei Subversion noch so billig, wird komplett verzichtet. Der Tag eines Projekts zu einem bestimmten Zeitpunkt ist schlicht die Revision seines Wurzelverzeichnisses. Der gesamte Buildprozess ist dann im Grunde nur eine Vorschrift für den Umgang mit Revisionsnummern.
Für Produkt-Branches werden bei Bedarf Projekt-Branches benötigt. Dabei werden Projekt-Branches nur für diejenigen Prohjekte angelegt, die auch im Rahmen des Produkt-Branches angepasst werden müssen (Bugfixes, neue Feature). Projekt-Branches werden ebenfalls in der Repository-Wurzel als Kopie des ursprünglichen Projekts mit einem passenden Namen angelegt. Die Details werden noch beleuchtet. Auf allseits empfohlene semantische Unterordner 'trunk', 'tags' und 'branches' kann nun komplett verzichtet werden. Jedes Projekt liegt direkt in der Wurzel des Repositorys. Das ist eine wesentliche Vereinfachung im Vergleich zu herkömmlichen Build-Prozessen.
Ant versorgt sich mit Informationen aus Subversion über die --xml Option des status Kommandos. Das dabei erzeugte XML wird mit dem erwähnten XPath Task ausgewertet. Dieser Trick stammt aus Gunther Popps ausgezeichnetem Buch zum Thema: 'Konfigurationsmanagement mit Subversion, Ant und Maven'.
Anbei noch ein paar unabdingbare Funtionen für die Administration eines Subversion Repositorys:
Repository anlegen: > svnadmin create <repository_pfad> : svnserve starten und einrichten: > svnserve -d // startet den SVN Server als Deamon : svnserve als Windowsdienst mit dem Befehl sc (Achtung! Leerzeichen nach = beachten): > sc create svnserve binpath= "<..>\svnserve.exe --service" displayname= "Subverion" depend= Tcpip : Konfiguration über die svn-serve.conf: [general] anon-access = none auth-access = write password-db = passwd // referenziert die Datei 'passwd' realm = SvnRep : und in der datei 'passwd' : [users] fred = geheim dieter = ganzGeheim : Recover eines Repository, letzter Checkpoint wird hergestellt: > svnadmin recover <repository_pfad> : Prüfen eines Repository > svnadmin verify <repository_pfad> : Dump und Wiederherstellen eines Repositorys (OS protabel!) > svnadmin dump <repository_pfad> > repos.dump > svnadmin load <repository_pfad> < repos.dump : Kopieren eines Repositorys im laufenden Betrieb (transaktionssicher) > svnadmin hotcopy <repository_pfad> <hotcopy_pfad>
Produkte erhalten einen strategischen Namen. Dieser sollte besser nicht das geplante Releasedatum oder kryptische Releasenummern enthalten. Stattdessen werden Namen von netten Tieren, griechischen Helden oder ähnliches verwendet. Projekte erhalten Namen in Anlehnung an den Zweck den sie in der Softwarearchitektur erfüllen. Auch Projekte haben keine Nummer und schon garnicht Releasesdaten im Namen. Projektbranches (also das Verzeichnis der Projektwurzel) bekommen ihren Originalnamen gefolgt von einer laufenden Nummer. Der Eclipse-Projektname (in der .project) muss nicht geändert werden. Produktreleases enthalten einen Zähler im Namen, der frei vergeben werden kann. Es bietet sich einen laufende Nummer oder der Zeitstempel des Releases an. Im hier entwickelten Buildprozess werden Produktreleases durch Ant-Targets repräsentiert und damit ist ihre Eindeutigkeit im Namen garantiert. Das alles sind letztlich nur Empfehlungen, einzig zwingend ist die Verwendung von Namen, aus denen sich Systempfade und Targetnamen erzeugen lassen.