Erstes Projekt in phpUnderControl

PhpUnderControl ist nach der Installation dein neuer Mitarbeiter in der Qualitätsüberwachung. Da im Hintergrund mehrere Builder bereit stehen (CCWeb: “There are builders supplied for Ant, NAnt, Maven, Phing, Rake, and Xcode and the catch-all exec), lassen sich weitere “lästige” Arbeiten verlagern, wie das Bereitstellen von Programmversionen, die Veröffentlichung auf Staging- und/oder Produktivservern, das Anpassen von Datenbanken, die Versionierung beim Erreichen der Anforderungen….

Projekt anlegen und einbinden

Was muss ich wo machen und bitte lange Dokumentationen vermeiden! Ok, es geht in 5 Sekunden.

Nach mehreren Zeilen Ausgaben meldet sich der freundliche Linux Prompt zurück und ein Test im Browser zeigt nach spätestens 5min ein neues Projekt in der Liste.



Farbe und Symbolik unseres php-under-control Projektes lassen nichts Gutes ahnen. In der Tat ist das mitgelieferte Example-Projekt mit Fehlern und schlechtem Codingstil behaftet - man will ja zeigen, was alles aufgedeckt wird.



Die Dokumentation ist auf dem neuesten Stand und die Anwendung kann als Beta den Markt erobern.
Schauen wir uns an was da im Hintergrund alles passiert, um unsere eigenen Projekte an diesem strengen Prüfer vorbei zu bekommen.

Als erstes erkunden wir die Arbeitsumgebung unseres Angestellten. Hat er überhaupt das Projekt richtig angelegt? Blindes Vertrauen schon in der Probezeit? Nein - also nochmal in den Konsolenausgaben unseres 5 Sekunden Projektes nachgeforscht:



finden wir alle relavanten Informationen. Der Workspace (project directory) wird also relativ unter projects/php-under-control angelegt. Ich habe auch gleich noch die entscheidenden Dateien markiert die offenbar miteinander korrespondieren.

  • config.xml - (im root von CruiseControl /opt/cc) steuert die Projektüberwachung
  • build.xml - (Ort ist nicht festgeschrieben) ist ein ANT build file

XML Ping Pong

Bei diesen XML Dateien steht man schnell mal vor der Frage: Wo packe ich das Auschecken von X oder das Kopieren von Y rein?

Ich habe da eine einfache Formel für die Grobabdeckung:

  • Ist es Teil des eigentlichen Build Prozesses? -> build.xml
  • Ist es zur regelmäßigen Überwachung des Projektfortschrittes nötig? -> config.xml

Beide Dateien stehen in engem Zusammenhang. Die config.xml muss die Ordnerstruktur der angelegten Builddateien und Logs kennen, um die entsprechenden Publisher zu steuern. Die Modificationsets der config.xml triggern auch erst ein Build und sind deshalb stark vom Projektzustand, wie z.B. Versionverwaltungssystemen, abhängig. Diese Abhängigkeit erklärt die Häufigkeit dieser beiden Dateien im obigen Konsolenmitschnitt.

Für die Arbeit mit Versionverwaltungen empfiehlt es sich, im Projektordner keine Dateien zu editieren. Das verhindert Merge Konflikte und damit fehlerhafte Builds, die die Entwickler bei sich lokal nicht nachvollziehen können. Dieser “Mitarbeiter” hat immer ein sauberes Arbeitsverzeichnis mit der aktuellen Programmversion, wenn wir uns daran halten.

Erfolgreiches Projekt

Bei unserem Example Projekt können wir uns eine Ausnahme gönnen. Der Spieltrieb sollte an dieser Stelle geweckt sein. Aktuell wird alle 5 Minuten die build.xml ausgeführt. Die entsprechenden Einstellungen dazu sind Thema des nächsten Artikels. Jetzt erst mal viel Spaß beim Ausprobieren.

Aktualisiert am 11. Mai 2009