BuildGrids: Unterschied zwischen den Versionen

Version vom 5. Juli 2008, 13:54 Uhr

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

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.

• Subversion
• CVS
• 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. 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.

• BuildGrid mit CruiseControl
• First steps with CruiseControl

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}).

• 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.

• 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).