BuildGrids

Aus DGL Wiki
Version vom 4. Juli 2008, 18:14 Uhr von TAK2004 (Diskussion | Beiträge) (Die Seite wurde neu angelegt: {{Unvollständig}} ==Allgemein== Ein Build Grid ist ein Netzwerk aus meheren Servern, die ein Teil einer Software verarbeiten. Hierbei gibt es unterschiedliche möglich...)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche
Hinweis: Dieser Artikel ist noch unvollständig.
(Mehr Informationen/weitere Artikel)

{{{1}}}
Incomplete.jpg

Allgemein

Ein Build Grid ist ein Netzwerk aus meheren 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,...). Um die Aufgaben möglichst unabhängig zu bewältigen, werden cross build systeme wie Apache Ant, CMake, Marvel und andere verwendet. Diese bieten ein Befehlssatz und Features, die für alle bekannteren Platformen 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). 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

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. 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 heisst 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 Konfigurationdatei, 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. 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 eine 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 deamons. 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 is 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 detailierter 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 lezten 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 heisst.

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>
Abgerufen von „https://wiki.delphigl.com/index.php?title=BuildGrids&oldid=21909“