BuildGrids - Versionsgeschichte

Openglerf: Grammatik :(

2012-03-21T14:48:50Z

Grammatik :(

TAK2004 am 7. Juli 2008 um 10:52 Uhr

2008-07-07T10:52:29Z

I0n0s: Nur Rechtschreibung - Inhalt ist noch nötig

2008-07-05T12:54:43Z

Nur Rechtschreibung - Inhalt ist noch nötig

Änderungen zeigen

TAK2004 am 5. Juli 2008 um 12:40 Uhr

2008-07-05T12:40:30Z

TAK2004 am 5. Juli 2008 um 12:01 Uhr

2008-07-05T12:01:56Z

TAK2004: 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...

2008-07-04T17:14:50Z

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

Neue Seite

{{Unvollständig}}
==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 [http://www.example.com 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 [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.
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 [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.
*[http://subversion.tigris.org/ Subversion]
*[http://www.nongnu.org/cvs/ CVS]
*[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.
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.
*[http://cruisecontrol.sourceforge.net/buildgrid.html BuildGrid mit CruiseControl]
*[http://confluence.public.thoughtworks.org/display/CC/MultiplePlatforms 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 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 [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 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">
:::<noWiki></noWiki>
::</'''target'''>
::<'''target''' ''name''="compile_LINUX" ''depends''="compile">
:::<noWiki></noWiki>
::</'''target'''>
::<'''target''' ''name''="compile">
:::<noWiki></noWiki>
::</'''target'''>
:</'''project'''>

@@ Zeile 27: / Zeile 27: @@
 ::</'''exec'''>
 :</'''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 das Binary Doxygen, mit dem Parameter Doxyfile, aus.
-Doxyfile ist hierbei eine Konfigurationsdatei, die doxygen sagt, was er zu tun hat.
+Doxyfile ist hierbei eine Konfigurationsdatei, die Doxygen sagt, was es zu tun hat.
 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 Buildlogs.
-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, bei welchen man übersichtlich alle Projekte aufgelistet bekommt, nähere Informationen findet, Builds erzwingen kann als auch 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.
@@ Zeile 42: / Zeile 42: @@
 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.
+Man kann es natürlich auch andersherum 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.
+Außerdem kann man dann den Linuxserver ohne X11 installieren und das spart eine Menge unnötiger Dämons.
 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.
+Es ist praktisch, wenn man noch ein Dokugenerator 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].
 Ein Versionierungssystem sollte auch verwendet werden, hier kann man z.B. folgende verwenden.
@@ Zeile 58: / Zeile 58: @@
 *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.
+Nun werden die Logfiles nach den OS-Flag benannt.
 Wer es detaillierter mag, der kann folgende Links besuchen.
@@ Zeile 68: / Zeile 68: @@
 *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}).
+Daraufhin 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.
+Nachfolgend guckt jeder CruiseControl Prozess bei der URL nach und will sich diesem Dashboard unterordnen.
 *folgender Block, ist unser Projekt
 :<'''project''' ''name''="Projektname_${env.OS}">
@@ Zeile 85: / Zeile 85: @@
 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 [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.
 Hierbei wird ${env.OS} durch z.B. WINDOWS_NT(für Windows XP) oder LINUX(für Standard Linux Distro's) ersetzt.
@@ Zeile 105: / Zeile 105: @@
 :</'''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.
+Schlägt der Compile-Task fehl, 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.
 [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.
 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 Linuxsystem 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([[Benutzer:TAK2004|TAK2004]]).

@@ Zeile 1: / Zeile 1: @@
-{{Unvollständig}}
+{{Unvollständig|korrektur vom Lektor fehlt}}
 ==Allgemein==
 Ein Build Grid ist ein Netzwerk aus mehreren Servern, die ein Teil einer Software verarbeiten.

@@ Zeile 11: / Zeile 11: @@
 ==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.

@@ Zeile 29: / Zeile 29: @@
 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.
-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.
+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.
@@ Zeile 102: / Zeile 102: @@
 ::</'''target'''>
 :</'''project'''>