Administration phpUnderControl

Die Logs nicht vergessen

Allzu gerne werden sie vernachlässigt - die Logdateien und alten Sicherungen. Unser phpUnderControl läuft nun schon einige Tage und ohne weitere Konfiguration wird das Example Projekt “php-under-control” alle 5 min neu getriggert und es erzeugt fleißig Dokumentationen und Auswertungen.

Da unser Continuous Integration Tool seinem Namen alle Ehre macht erzeugt es fortlaufend neue Dateien im ./artifacts Ordner. Das muss nicht auf jedem Server zum Problem führen. Bei richtiger Konfiguration sind diese Dateien sogar gewollt. Doch wer braucht schon die Nightly Builds der letzten 3 Jahre?

Also entweder das Aufräumen wird als Teil des Build Prozesses integriert und damit voll steuerbar oder die schnelle Variante die phpUnderControl mitliefert reicht für den Anfang.

Der Befehl kürzt die Sammlung auf die letzten 10 Builds. Weitere Optionen findet ihr in der Doku.

Achtung: Dieses Aufräumen ist relevant für die angezeigte Statistik im Menüpunkt Metrics.





Feintuning wird nötig

Es wird also Zeit dem neuen Helfer genauere Anweisungen für sinnvollere Projektbegleitung zu geben.

Ab hier wird es jetzt so projektspezifisch, dass ich einige Vorgaben machen muss
1. Meilenstein:

  • das example project wird in ein CVS Repository importiert
  • phpUnderControl soll das CVS Repo überwachen
  • das Projekt wird auf einem Arbeitsrechner ausgecheckt

Na dann mal los. CVS hatte ich neben weiteren Versionsverwaltungen ja bereits mit auf dem Entwicklungsserver installiert. Bleibt noch CVS Repository anlegen, Arbeitskopie des Projektes besorgen und dann ins CVS importieren.

Es sollten einige positive Echos in der Konsole erscheinen. Ok, jetzt dieses Projekt als Arbeitskopie auschecken.

Da wir die build.xml in der Versionsverwaltung integriert haben, müssen wir eine Besonderheit beim Konfigurieren von phpUnderControl beachten. Da bei der Überwachung nur die Änderung im CVS Repository als Auslöser eines neuen Builds dient, fehlt das Aktualisieren/Updaten der eventuell modifizierten build.xml bevor CruiseControl sie durch unsere fleißige Ameise (ANT) jagt. Aber da wir nicht die ersten sind, die das bemerken gibt es natürlich einen Ausweg.

Aber der Reihe nach: CVS Überwachung einbauen, build.xml updaten und dann ANT starten. Wo war das gleich nochmal? Ah ja, die Arbeitsanweisungen unseres Continuous Integration Tools stehen in der config.xml. Zeit diese unter die Lupe zu nehmen.



Jedes Projekt hat also seinen Abschnitt im XML. Hier mal ein Crashkurs für die Tag Elemente:
<project>

Dieses Element steht für ein Projekt und enthält in den eingeschlossenen Elementen die Informationen für das wann und wie eines Builds
Attribute:
name - eindeutiger Name innerhalb der CC Umgebung
buildafterfailed - [true|false] - aktiviert bei true weitere Builds auch nach Fehlern. Ist nützlich, wenn der Fehler durch Systemprobleme (DB, Netwerk, …) entstand, aber erzwingt auch Wiederholungen, wenn der Code wirklich nicht zu builden ist.

<schedule>

Dieses Element ist Pflicht und gibt an in welchem Intervall CruiseControl dieses Projekt tiggert. Außerdem enthält es den Aufruf der eigentlichen Buildprozesse.
Attribute:
interval - defaults ‘300′ (5 Minuten) - Sekunden bis zum nächsten Versuch

modificationset

Ist ein Intervall erreicht und das nächste Build steht an, werden erst mal die hier eingetragenen Bedingungen gecheckt. Damit könnte man dieses Element als Filter betrachten. Es verhindert unnötige Buildprozesse oder startet bewusst z.B. Nightly Builds auch ohne Änderungen am Quellcode.
Attribute:
    requiremodification
    default ‘true’ - soll eine Änderung erst das Ereignis auslösen; alternativ kann dieses Attribut durch das Kindelement <alwaysbuild/> auch umgangen werden.
    Damit haben wir unseren Example Zustand gleich geklärt.
    quietperiod
    optional - gibt eine Zeitspanne in Sekunden an, wie alt die erwartete Änderung mindestens sein soll.
    Das ist nützlich wenn in großen Projekten oder langsamen Verbindungen die Versionsverwaltungen einen inkonsistenten Zustand haben könnten.
    Ich bin mir nicht sicher, ob das nur bei CVS passieren könnte, da andere ja atomar arbeiten.

<bootstrappers\>

Hier können Anweisungen rein die noch vor jedem Build durchlaufen sollen. Da hatten wir doch Bedarf - genau - unser build.xml enthält ja die Anweisungen für einen neuen Buildprozess und bevor es vom ANT benutzt wird, müssten wir die gewünschte und aktuellste Version im Projekt liegen haben. Das erledigen wir durch einen CVS update in diesem Element.

Na jetzt haben wir genug Theorie. Unser Meilenstein schreit nach Taten. Folgende Anpassungen müssen in die /opt/cc/config.xml Datei:

Ich habe gleich noch das Projekt “connectfour” entfernt. Testen wir die Änderungen, indem wir im Browser nachsehen. Aber vorher noch eine CVS Version unseres Projektes in den CC Projektordner. Richtig wäre ein ordentlicher checkout, aber schneller ist:

Der Meilenstein ist erreicht. Ich erhalte unter http://lamp:8080/cruisecontrol/buildresults/php-under-control

Aktualisiert am 15. Juni 2009