BuildGrids: Unterschied zwischen den Versionen

Aus DGL Wiki
Wechseln zu: Navigation, Suche
K (Nur Rechtschreibung - Inhalt ist noch nötig)
Zeile 1: Zeile 1:
 
{{Unvollständig}}
 
{{Unvollständig}}
 
==Allgemein==
 
==Allgemein==
Ein Build Grid ist ein Netzwerk aus meheren Servern, die ein Teil einer Software verarbeiten.
+
Ein Build Grid ist ein Netzwerk aus mehreren Servern, die ein Teil einer Software verarbeiten.
Hierbei gibt es unterschiedliche möglichkeiten, wie z.B. das aufteilen von Platformen(PC_WIN32, PC_WIN64, PC_LINUX32, PC_LINUX64, PS3_LINUX, GP2X_LINUX), Tasks(compile,doc,clean,package) oder in kombination(compile_FreeBSD_32,compile_Windows_NT_64,...).
+
Hierbei gibt es unterschiedliche Möglichkeiten, wie z.B. das Aufteilen von Plattformen(PC_WIN32, PC_WIN64, PC_LINUX32, PC_LINUX64, PS3_LINUX, GP2X_LINUX), Tasks (compile, doc, clean, package) oder in Kombination (compile_FreeBSD_32, compile_Windows_NT_64, ...).
Um die Aufgaben möglichst unabhängig zu bewältigen, werden cross build systeme wie Apache Ant, CMake, Marvel und andere verwendet.
+
Um die Aufgaben möglichst unabhängig zu bewältigen, werden Crossbuild-Systeme wie Apache Ant, CMake, Marvel und andere verwendet.
Diese bieten ein Befehlssatz und Features, die für alle bekannteren Platformen portiert wurden.
+
Diese bieten ein Befehlssatz und Features, die für alle bekannteren Plattformen portiert wurden.
Wenn alle Stricke reissen und die Aufgabe zu complex wird, dann kann auf die lokale scriptsprache zurück greifen(z.B. Bash oder Batch) oder Binaries ausführen(cl.exe ..., glxinfo).
+
Wenn alle Stricke reißen und die Aufgabe zu komplex wird, dann kann auf die lokale Skriptsprache zurück greifen(z.B. Bash oder Batch) oder Binaries ausführen(cl.exe ..., glxinfo).
Das Ziel ist ein automatisiertes abarbeiten von Tasks, wenn eine änderung statt gefunden hat.
+
Das Ziel ist ein automatisiertes Abarbeiten von Tasks, wenn eine Änderung statt gefunden hat.
So kann man z.B. den Buildprozess anschmeissen, wenn im SVN/CVS/Perforce/... eine änderung statt fand.
+
So kann man z.B. den Buildprozess anschmeissen, wenn im SVN/CVS/Perforce/... eine Änderung statt fand.
 
Dieser Artikel beschäftigt sich mit CruiseControl, einem Java basierten OpenSource Buildsystem.
 
Dieser Artikel beschäftigt sich mit CruiseControl, einem Java basierten OpenSource Buildsystem.
  
 
==CruiseControl==
 
==CruiseControl==
 +
 
[[Bild:Buildgrid.png|right|framed|Schematische Übersicht über das Build Grid.]]
 
[[Bild:Buildgrid.png|right|framed|Schematische Übersicht über das Build Grid.]]
 
CruiseControl ist ein Buildsystem, welches auf Apache Ant aufbaut und ein eigenen Webserver mit bringt.
 
CruiseControl ist ein Buildsystem, welches auf Apache Ant aufbaut und ein eigenen Webserver mit bringt.
Der Webdienst läuft standardmässig auf Port 8080 aber kann wie jede andere Einstellung einfach angepasst werden.
+
Der Webdienst läuft standardmäßig auf Port 8080 aber kann wie jede andere Einstellung einfach angepasst werden.
 
Im Hauptverzeichnis liegt eine '''config.xml''', in welcher die Projekte registriert und im groben eingestellt werden.
 
Im Hauptverzeichnis liegt eine '''config.xml''', in welcher die Projekte registriert und im groben eingestellt werden.
 
So findet man hier ein Tag '''modificationset''', welches dafür sorgt, ob ein Build angeworfen wird, weil z.B. im SVN eine neue Revision vorhanden ist.
 
So findet man hier ein Tag '''modificationset''', welches dafür sorgt, ob ein Build angeworfen wird, weil z.B. im SVN eine neue Revision vorhanden ist.
Zeile 19: Zeile 20:
 
Mehr zu den einzelnen Tags und deren Möglichkeiten findet man [http://www.example.com hier] oder später in diesem Artikel.
 
Mehr zu den einzelnen Tags und deren Möglichkeiten findet man [http://www.example.com hier] oder später in diesem Artikel.
 
Für jedes Projekt kann man nun eine ant Buildfile im Projekteverzeichnis anlegen.
 
Für jedes Projekt kann man nun eine ant Buildfile im Projekteverzeichnis anlegen.
Default heisst so eine Buildfile '''build.xml''' und enthält die genauen Task eines Projektes.
+
Default heißt so eine Buildfile '''build.xml''' und enthält die genauen Task eines Projektes.
 
So kann z.B. ein Task aussehen.
 
So kann z.B. ein Task aussehen.
 
:<'''target''' ''name''="builddoc" ''description''="generate the documentation">
 
:<'''target''' ''name''="builddoc" ''description''="generate the documentation">
Zeile 27: Zeile 28:
 
:</'''target'''>
 
:</'''target'''>
 
Dieser Task hört auf den Namen builddoc und führt die Binary doxygen, mit dem Parameter Doxyfile, aus.
 
Dieser Task hört auf den Namen builddoc und führt die Binary doxygen, mit dem Parameter Doxyfile, aus.
Doxyfile ist hierbei eine Konfigurationdatei, die doxygen sagt, was er zu tun hat.
+
Doxyfile ist hierbei eine Konfigurationsdatei, die doxygen sagt, was er zu tun hat.
Genauere Informationen gibt es [http://www.example.com hier] oder im verlauf dieses Artikels.
+
Genauere Informationen gibt es [http://www.example.com hier] oder im Verlauf dieses Artikels.
 
Für jedes Projekt wird default im '''cruisecontrol/logs/...''' Ordner Log geführt, dabei gibt es ein allgemeines CruiseControl Log(cruisecontrol/logs/cc.log) und für jedes Projekt noch ein eigenen Ordner mit den build Logs.
 
Für jedes Projekt wird default im '''cruisecontrol/logs/...''' Ordner Log geführt, dabei gibt es ein allgemeines CruiseControl Log(cruisecontrol/logs/cc.log) und für jedes Projekt noch ein eigenen Ordner mit den build Logs.
CC bringt ein dashboard mit, wo man übersichtlich alle Projekte aufgelistet bekommt, nähere Informationen findet, Builds erzwingen kann und Informationen zum aktuell laufenden Build erhält.
+
CC bringt ein Dashboard mit, wo man übersichtlich alle Projekte aufgelistet bekommt, nähere Informationen findet, Builds erzwingen kann und Informationen zum aktuell laufenden Build erhält.
Dieses dashboard kann an eigene bedürfnisse angepasst werden, hierfür wurde es in xml und css zerlegt.
+
Dieses Dashboard kann an eigene Bedürfnisse angepasst werden, hierfür wurde es in XML und CSS zerlegt.
 
Zu finden ist das ganze im '''cruisecontrol/webapps/dashboard/''' Ordner.
 
Zu finden ist das ganze im '''cruisecontrol/webapps/dashboard/''' Ordner.
Verbunden werden die einzelnen CruiseControl über ein extra port, worüber die Kommunikation statt findet.
+
Verbunden werden die einzelnen CruiseControl über ein extra Port, worüber die Kommunikation statt findet.
 
Der User muss nur in der config.xml das Ziel angeben und das sieht so aus.
 
Der User muss nur in der config.xml das Ziel angeben und das sieht so aus.
 
:<'''dashboard''' ''url''="http://buildserver:8080/dashboard"/>
 
:<'''dashboard''' ''url''="http://buildserver:8080/dashboard"/>
  
 
==Das eigene Build Grid==
 
==Das eigene Build Grid==
Als erstes brauchen wir eine Zentralen Ort, wo wir unsere Builds, Sources, Dokumentation und so weiter ablegen.
+
Als erstes brauchen wir einen zentralen Ort, wo wir unsere Builds, Sources, Dokumentation und so weiter ablegen.
 
Hierzu kann man ftp, Samba/cifs, nfs oder ähnliches verwenden.
 
Hierzu kann man ftp, Samba/cifs, nfs oder ähnliches verwenden.
 
Es ist ziemlich einfach, wenn man auf ein Windows System einen Ordner frei gibt, der für einen neuen User(z.B. Builder) volle Rechte gewährt. Nun kann jede Linuxkiste per '''samba''' oder '''cifs''' auf die Freigabe zugreifen.
 
Es ist ziemlich einfach, wenn man auf ein Windows System einen Ordner frei gibt, der für einen neuen User(z.B. Builder) volle Rechte gewährt. Nun kann jede Linuxkiste per '''samba''' oder '''cifs''' auf die Freigabe zugreifen.
 
Man kann es natürlich auch andersrum machen aber in der Regel programmieren die Entwickler auf Windows und nutzen Gui basierte Tools, wie z.B. SVN,CVS,Visual Studio, Delphi und andere Programme.
 
Man kann es natürlich auch andersrum machen aber in der Regel programmieren die Entwickler auf Windows und nutzen Gui basierte Tools, wie z.B. SVN,CVS,Visual Studio, Delphi und andere Programme.
Ausserdem kann man dann den Linuxserver ohne X11 installieren und spart ne menge unnötiger deamons.
+
Ausserdem kann man dann den Linuxserver ohne X11 installieren und spart ne menge unnötiger Daemons.
 
Nun lädt man sich CruiseControl und installiert Java SE und Java JDK.
 
Nun lädt man sich CruiseControl und installiert Java SE und Java JDK.
CruiseControl wird in den share entpackt, da die anderen Server CC vom Share aus aufrufen.
+
CruiseControl wird in den Share entpackt, da die anderen Server CC vom Share aus aufrufen.
 
Somit nutzen alle die gleiche Konfiguration, Version und Sourcecode.
 
Somit nutzen alle die gleiche Konfiguration, Version und Sourcecode.
Es is praktisch, wenn man noch ein Doku Generator installiert, z.B. doxygen, javadoc oder pasdoc.
+
Es ist praktisch, wenn man noch ein Doku Generator installiert, z.B. doxygen, javadoc oder pasdoc.
 
Weitere nützliche Tools sind [http://nsis.sourceforge.net/Main_Page NSIS] und [http://www.cmake.org/HTML/index.html CMake].
 
Weitere nützliche Tools sind [http://nsis.sourceforge.net/Main_Page NSIS] und [http://www.cmake.org/HTML/index.html CMake].
 
Ein Versionierungssystem sollte auch verwendet werden, hier kann man z.B. folgende verwenden.
 
Ein Versionierungssystem sollte auch verwendet werden, hier kann man z.B. folgende verwenden.
 
*[http://subversion.tigris.org/ Subversion]
 
*[http://subversion.tigris.org/ Subversion]
 
*[http://www.nongnu.org/cvs/ CVS]
 
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.perforce.com/ Perforce](Lizenz beachten, es ist bis zu einer bestimmten nutzung in vollem Umfang frei.)
+
*[http://www.perforce.com/ Perforce](Lizenz beachten, es ist bis zu einer bestimmten Nutzung in vollem Umfang frei.)
 
CC ist zwar für Build Grids ausgelegt aber man hat noch nicht alles angepasst, wie z.B. die Logausgabe.
 
CC ist zwar für Build Grids ausgelegt aber man hat noch nicht alles angepasst, wie z.B. die Logausgabe.
 
Hierzu muss man leider nochmal an CC hand anlegen.
 
Hierzu muss man leider nochmal an CC hand anlegen.
Zeile 59: Zeile 60:
 
Nun werden die log files nach den OS flag benannt.
 
Nun werden die log files nach den OS flag benannt.
  
Wer es detailierter mag, der kann folgende Links besuchen.
+
Wer es detaillierter mag, der kann folgende Links besuchen.
 
*[http://cruisecontrol.sourceforge.net/buildgrid.html BuildGrid mit CruiseControl]
 
*[http://cruisecontrol.sourceforge.net/buildgrid.html BuildGrid mit CruiseControl]
 
*[http://confluence.public.thoughtworks.org/display/CC/MultiplePlatforms First steps with CruiseControl]
 
*[http://confluence.public.thoughtworks.org/display/CC/MultiplePlatforms First steps with CruiseControl]
Zeile 67: Zeile 68:
 
*entferne das beispielprojekt
 
*entferne das beispielprojekt
 
*füge <'''property''' ''environment''="env"/> hinzu
 
*füge <'''property''' ''environment''="env"/> hinzu
Nun können wir über ${env.x} auf die lokalen Umgebungsvariablen zugreifen, wobei x der name der Umgebungsvariable ist(z.B. ${env.OS} oder ${env.PATH}).
+
Nun können wir über ${env.x} auf die lokalen Umgebungsvariablen zugreifen, wobei x der Name der Umgebungsvariable ist(z.B. ${env.OS} oder ${env.PATH}).
 
*füge <'''dashboard''' ''url''="http://name_deines_pc:8080/dashboard"/> hinzu
 
*füge <'''dashboard''' ''url''="http://name_deines_pc:8080/dashboard"/> hinzu
 
Nun guckt jeder CruiseControl Prozess bei der URL nach und will sich diesem Dashboard unterordnen.
 
Nun guckt jeder CruiseControl Prozess bei der URL nach und will sich diesem Dashboard unterordnen.
Zeile 81: Zeile 82:
 
::<'''/schedule'''>
 
::<'''/schedule'''>
 
:</'''project'''>
 
:</'''project'''>
Ein minimales Projekt besteht aus einem modificationset und schedule.
+
Ein minimales Projekt besteht aus einem Modificationset und Schedule.
Das modificationset wird vom schedule alle 300 Sekunden aufgerufen und prüft, ob eine änderung seit dem lezten mal aufgetreten ist.
+
Das Modificationset wird vom Schedule alle 300 Sekunden aufgerufen und prüft, ob eine Änderung seit dem letzten Mal aufgetreten ist.
 
Wenn ja darf der Schedule ausgeführt werden, sonnst wird er übersprungen und wartet wieder 300 Sekunden.
 
Wenn ja darf der Schedule ausgeführt werden, sonnst wird er übersprungen und wartet wieder 300 Sekunden.
Als modificationset wird ein svn repo verwendet, man kann auch p4,cvs,vss oder [http://cruisecontrol.sourceforge.net/main/configxml.html#modificationset andere Systeme] nutzen.
+
Als Modificationset wird ein svn repo verwendet, man kann auch p4,cvs,vss oder [http://cruisecontrol.sourceforge.net/main/configxml.html#modificationset andere Systeme] nutzen.
Schedule ist eine Art Task und wird alle 300 Sekunden aufgerufen, der Parameter showProgress sorgt dafür, dass das dashboard in kurzen Abständen aktualisiert wird, wenn ein Build am laufen ist.
+
Schedule ist eine Art Task und wird alle 300 Sekunden aufgerufen, der Parameter showProgress sorgt dafür, dass das Dashboard in kurzen Abständen aktualisiert wird, wenn ein Build am laufen ist.
 
Schedule führt ein Apache Ant Build File aus, welches mit dem target compile_${env.OS} aufgerufen wird.
 
Schedule führt ein Apache Ant Build File aus, welches mit dem target compile_${env.OS} aufgerufen wird.
Hierbei wird ${env.OS} durch z.B. WINDOWS_NT(für Windows XP) oder LINUX(für standard Linux Distro's) ersetzt.
+
Hierbei wird ${env.OS} durch z.B. WINDOWS_NT(für Windows XP) oder LINUX(für Standard Linux Distro's) ersetzt.
Also wird in build.xml ein Task gesucht, der unter Windows XP compile_WINDOWS_NT heisst.
+
Also wird in build.xml ein Task gesucht, der unter Windows XP compile_WINDOWS_NT heißt.
  
 
Nun kommt die Apache Ant Build File dran.
 
Nun kommt die Apache Ant Build File dran.
Zeile 106: Zeile 107:
 
Schlägt der compile Task fehlt, dann werden die anderen beiden garnicht erst ausgeführt.
 
Schlägt der compile Task fehlt, dann werden die anderen beiden garnicht erst ausgeführt.
 
Wenn man für das eigene Projekt z.B. eine Scriptsprache verwendet und den Interface Code generieren will, dann kann man im compile Task dies tun und dann den wirklichen compilier Task anwerfen.
 
Wenn man für das eigene Projekt z.B. eine Scriptsprache verwendet und den Interface Code generieren will, dann kann man im compile Task dies tun und dann den wirklichen compilier Task anwerfen.
[http://ant.apache.org/manual/coretasklist.html Hier] findet man eine Liste von möglichen Befehlen, die man in einen Task packen kann. So kann '''exec''', wie wir weiter oben schon geshen haben, Datein ausführen oder mit '''copy''' einzelne Datein kopieren.
+
[http://ant.apache.org/manual/coretasklist.html Hier] findet man eine Liste von möglichen Befehlen, die man in einen Task packen kann. So kann '''exec''', wie wir weiter oben schon gesehen haben, Dateien ausführen oder mit '''copy''' einzelne Dateien kopieren.
Wenn wir also auf unserer Windows Machiene CC anwerfen und dann über ein Netzwerk Freigabe, mit Linux, CC anwerfen, dann registriert es sich beim entsprechend konfiguriertem Dashboard und neben den Windows Build Task tauchen dann Linux Build Tasks im Dashboard auf. Wenn die Linux basierten Tasks dann auf korrektheit geprüft wurden, wird im Dashboard der Task aktiviert und zeigt den letzten Buildstatus an.
+
Wenn wir also auf unserer Windows Machiene CC anwerfen und dann über ein Netzwerk Freigabe, mit Linux, CC anwerfen, dann registriert es sich beim entsprechend konfiguriertem Dashboard und neben den Windows Build Task tauchen dann Linux Build Tasks im Dashboard auf. Wenn die Linux basierten Tasks dann auf Korrektheit geprüft wurden, wird im Dashboard der Task aktiviert und zeigt den letzten Buildstatus an.
 
Rot wäre ein fehlgeschlagener, grün ein erfolgreicher und gelb ein laufender Build.
 
Rot wäre ein fehlgeschlagener, grün ein erfolgreicher und gelb ein laufender Build.
 
Wenn CC auf dem Linux System nicht mehr läuft, dann wird der Task im Dashboard wieder deaktiviert und kann nicht aufgerufen werden.
 
Wenn CC auf dem Linux System nicht mehr läuft, dann wird der Task im Dashboard wieder deaktiviert und kann nicht aufgerufen werden.
  
  
Nun kommt der anstrengende Teil, selbstlehre, nun heisst es erkennen was man für das eigene Projekt braucht und eine Lösung dafür zu entwickeln.
+
Nun kommt der anstrengende Teil, Selbstlehre, nun heisst es erkennen was man für das eigene Projekt braucht und eine Lösung dafür zu entwickeln.
 
Da kann ich nur noch viel Erfolg wünschen, wenn es größere Problemen gibt, schreibt ins Forum oder wendet euch direkt an mich([[Benutzer:TAK2004|TAK2004]]).
 
Da kann ich nur noch viel Erfolg wünschen, wenn es größere Problemen gibt, schreibt ins Forum oder wendet euch direkt an mich([[Benutzer:TAK2004|TAK2004]]).

Version vom 5. Juli 2008, 13:54 Uhr

Hinweis: Dieser Artikel ist noch unvollständig.
(Mehr Informationen/weitere Artikel)

{{{1}}}

Incomplete.jpg

Allgemein

Ein Build Grid ist ein Netzwerk aus mehreren Servern, die ein Teil einer Software verarbeiten. Hierbei gibt es unterschiedliche Möglichkeiten, wie z.B. das Aufteilen von Plattformen(PC_WIN32, PC_WIN64, PC_LINUX32, PC_LINUX64, PS3_LINUX, GP2X_LINUX), Tasks (compile, doc, clean, package) oder in Kombination (compile_FreeBSD_32, compile_Windows_NT_64, ...). Um die Aufgaben möglichst unabhängig zu bewältigen, werden Crossbuild-Systeme wie Apache Ant, CMake, Marvel und andere verwendet. Diese bieten ein Befehlssatz und Features, die für alle bekannteren Plattformen portiert wurden. Wenn alle Stricke reißen und die Aufgabe zu komplex wird, dann kann auf die lokale Skriptsprache zurück greifen(z.B. Bash oder Batch) oder Binaries ausführen(cl.exe ..., glxinfo). Das Ziel ist ein automatisiertes Abarbeiten von Tasks, wenn eine Änderung statt gefunden hat. So kann man z.B. den Buildprozess anschmeissen, wenn im SVN/CVS/Perforce/... eine Änderung statt fand. Dieser Artikel beschäftigt sich mit CruiseControl, einem Java basierten OpenSource Buildsystem.

CruiseControl

Schematische Übersicht über das Build Grid.

CruiseControl ist ein Buildsystem, welches auf Apache Ant aufbaut und ein eigenen Webserver mit bringt. Der Webdienst läuft standardmäßig auf Port 8080 aber kann wie jede andere Einstellung einfach angepasst werden. Im Hauptverzeichnis liegt eine config.xml, in welcher die Projekte registriert und im groben eingestellt werden. So findet man hier ein Tag modificationset, welches dafür sorgt, ob ein Build angeworfen wird, weil z.B. im SVN eine neue Revision vorhanden ist. Es gibt auch Tags wie bootstrappers(läuft vor dem build ab) oder schedule(der build process). Mehr zu den einzelnen Tags und deren Möglichkeiten findet man hier oder später in diesem Artikel. Für jedes Projekt kann man nun eine ant Buildfile im Projekteverzeichnis anlegen. Default heißt so eine Buildfile build.xml und enthält die genauen Task eines Projektes. So kann z.B. ein Task aussehen.

<target name="builddoc" description="generate the documentation">
<exec executable="doxygen">
<arg path="Doxyfile"/>
</exec>
</target>

Dieser Task hört auf den Namen builddoc und führt die Binary doxygen, mit dem Parameter Doxyfile, aus. Doxyfile ist hierbei eine Konfigurationsdatei, die doxygen sagt, was er zu tun hat. Genauere Informationen gibt es hier oder im Verlauf dieses Artikels. Für jedes Projekt wird default im cruisecontrol/logs/... Ordner Log geführt, dabei gibt es ein allgemeines CruiseControl Log(cruisecontrol/logs/cc.log) und für jedes Projekt noch ein eigenen Ordner mit den build Logs. CC bringt ein Dashboard mit, wo man übersichtlich alle Projekte aufgelistet bekommt, nähere Informationen findet, Builds erzwingen kann und Informationen zum aktuell laufenden Build erhält. Dieses Dashboard kann an eigene Bedürfnisse angepasst werden, hierfür wurde es in XML und CSS zerlegt. Zu finden ist das ganze im cruisecontrol/webapps/dashboard/ Ordner. Verbunden werden die einzelnen CruiseControl über ein extra Port, worüber die Kommunikation statt findet. Der User muss nur in der config.xml das Ziel angeben und das sieht so aus.

<dashboard url="http://buildserver:8080/dashboard"/>

Das eigene Build Grid

Als erstes brauchen wir einen zentralen Ort, wo wir unsere Builds, Sources, Dokumentation und so weiter ablegen. Hierzu kann man ftp, Samba/cifs, nfs oder ähnliches verwenden. Es ist ziemlich einfach, wenn man auf ein Windows System einen Ordner frei gibt, der für einen neuen User(z.B. Builder) volle Rechte gewährt. Nun kann jede Linuxkiste per samba oder cifs auf die Freigabe zugreifen. Man kann es natürlich auch andersrum machen aber in der Regel programmieren die Entwickler auf Windows und nutzen Gui basierte Tools, wie z.B. SVN,CVS,Visual Studio, Delphi und andere Programme. Ausserdem kann man dann den Linuxserver ohne X11 installieren und spart ne menge unnötiger Daemons. Nun lädt man sich CruiseControl und installiert Java SE und Java JDK. CruiseControl wird in den Share entpackt, da die anderen Server CC vom Share aus aufrufen. Somit nutzen alle die gleiche Konfiguration, Version und Sourcecode. Es ist praktisch, wenn man noch ein Doku Generator installiert, z.B. doxygen, javadoc oder pasdoc. Weitere nützliche Tools sind NSIS und CMake. Ein Versionierungssystem sollte auch verwendet werden, hier kann man z.B. folgende verwenden.

CC ist zwar für Build Grids ausgelegt aber man hat noch nicht alles angepasst, wie z.B. die Logausgabe. Hierzu muss man leider nochmal an CC hand anlegen.

  • cruisecontrol/lib/cruisecontrol.jar öffnen(mit 7z rechtsklick->7-Zip->öffnen)
  • log4j.properties bearbeiten
  • 3. Zeile von unten zu log4j.appender.FILE.File=logs/cc_$\{os.name\}.log ändern

Nun werden die log files nach den OS flag benannt.

Wer es detaillierter mag, der kann folgende Links besuchen.

Nun können wir uns daran machen, ein eigenes Projekt zu erstellen.

  • öffne cruisecontrol/config.xml
  • entferne das beispielprojekt
  • füge <property environment="env"/> hinzu

Nun können wir über ${env.x} auf die lokalen Umgebungsvariablen zugreifen, wobei x der Name der Umgebungsvariable ist(z.B. ${env.OS} oder ${env.PATH}).

Nun guckt jeder CruiseControl Prozess bei der URL nach und will sich diesem Dashboard unterordnen.

  • folgender Block, ist unser Projekt
<project name="Projektname_${env.OS}">
<modificationset>
<svn RepositoryLocation="svn://location_of_server/repo"/>
</modificationset>
<schedule interval="300" showProgress="true">
<ant uselogger="true" anthome="apache-ant-1.7.0" buildfile="projects/Projektname/build.xml" target="compile_${env.OS}">
<property name="platform" value="${env.OS}"/>
</ant>
</schedule>
</project>

Ein minimales Projekt besteht aus einem Modificationset und Schedule. Das Modificationset wird vom Schedule alle 300 Sekunden aufgerufen und prüft, ob eine Änderung seit dem letzten Mal aufgetreten ist. Wenn ja darf der Schedule ausgeführt werden, sonnst wird er übersprungen und wartet wieder 300 Sekunden. Als Modificationset wird ein svn repo verwendet, man kann auch p4,cvs,vss oder andere Systeme nutzen. Schedule ist eine Art Task und wird alle 300 Sekunden aufgerufen, der Parameter showProgress sorgt dafür, dass das Dashboard in kurzen Abständen aktualisiert wird, wenn ein Build am laufen ist. Schedule führt ein Apache Ant Build File aus, welches mit dem target compile_${env.OS} aufgerufen wird. Hierbei wird ${env.OS} durch z.B. WINDOWS_NT(für Windows XP) oder LINUX(für Standard Linux Distro's) ersetzt. Also wird in build.xml ein Task gesucht, der unter Windows XP compile_WINDOWS_NT heißt.

Nun kommt die Apache Ant Build File dran. Hierfür muss erstmal eine build.xml im cruisecontrol/projects/Projektname/ erstellt werden.

<project name="Projektname" default="all" basedir=".">
<target name="compile_Windows_NT" depends="compile">
<!-- irgendwelche Windows build Aufgaben -->
</target>
<target name="compile_LINUX" depends="compile">
<!-- irgendwelche Linux build Aufgaben -->
</target>
<target name="compile">
<!-- irgendwelche Aufgaben die für beide builds gelten -->
</target>
</project>

Das Build besteht aus 3 Targets, wobei compile_Windows_NT und compile_LINUX von compile abhängig sind und dieses auch zuerst aufrufen. Schlägt der compile Task fehlt, dann werden die anderen beiden garnicht erst ausgeführt. Wenn man für das eigene Projekt z.B. eine Scriptsprache verwendet und den Interface Code generieren will, dann kann man im compile Task dies tun und dann den wirklichen compilier Task anwerfen. Hier findet man eine Liste von möglichen Befehlen, die man in einen Task packen kann. So kann exec, wie wir weiter oben schon gesehen haben, Dateien ausführen oder mit copy einzelne Dateien kopieren. Wenn wir also auf unserer Windows Machiene CC anwerfen und dann über ein Netzwerk Freigabe, mit Linux, CC anwerfen, dann registriert es sich beim entsprechend konfiguriertem Dashboard und neben den Windows Build Task tauchen dann Linux Build Tasks im Dashboard auf. Wenn die Linux basierten Tasks dann auf Korrektheit geprüft wurden, wird im Dashboard der Task aktiviert und zeigt den letzten Buildstatus an. Rot wäre ein fehlgeschlagener, grün ein erfolgreicher und gelb ein laufender Build. Wenn CC auf dem Linux System nicht mehr läuft, dann wird der Task im Dashboard wieder deaktiviert und kann nicht aufgerufen werden.


Nun kommt der anstrengende Teil, Selbstlehre, nun heisst es erkennen was man für das eigene Projekt braucht und eine Lösung dafür zu entwickeln. Da kann ich nur noch viel Erfolg wünschen, wenn es größere Problemen gibt, schreibt ins Forum oder wendet euch direkt an mich(TAK2004).