Es ist soweit, ich bin stolz, die erste Version von “PhpCilux” präsentieren zu dürfen.
Eigentlich wollte ich es ja “Daisy” nennen, da ich bei gleichnamigen Sturm über Deutschland mit der Entwicklung begonnen hatte. Allerdings gibt es schon viel zu viele Projekte mit dem Namen “Daisy”.
PhpCilux soll als Name vielmehr symbolisieren, dass es php-Anwendung mittels CI beleuchten kann. Der Name war eine wirklich schwere Geburt, aber jetzt wieder weiter im Text.
Ich beschäftige mich schon seit einer Weile mit Continuous Integration. Dabei habe ich natürlich auch phpUnderControl installiert und eingesetzt. Ich denke, dass ist der Platzhirsch, wenn man sich mit dem Thema im Rahmen einer PHP Entwicklungsumgebung beschäftigt. Es ist auch durchaus zu recht in aller Munde, da es groß und mächtig ist. Für mich aber irgendwie zu mächtig, zu groß und zu komplex. Neben phpUnderControl gibt es noch diverse andere Tools. Im PHP-Umfeld ist dabei sicherlich noch Xinc interessant. Allerdings sieht es so aus, als ob das aktuell nicht mehr weiterentwickelt wird.
Dann bin ich eher aus Zufall auf Sismo gestoßen. Ich finde diesen Ansatz cool, einfach und intuitiv zu bedienen! Es gibt genau nur die Informationen wieder, die man hier benötigt:
- Projekt erfolgreich: ja/nein
- Build erfolgreich: ja/nein
- Navigieren durch die Projekte und Builds
Sismo ist leider noch nicht veröffentlicht. Ich wollte aber unbedingt so ein Tool haben, somit habe ich mich entschlossen so was ähnliches zu entwickeln. Das Ergebnis ist nun da: PhpCilux.

Und was kann es?
Es kann eigentlich gar nicht so viel und das ist auch so gewollt!
Eigentlich kann es nur die Logfiles von PHPUnit und PHP_CodeSniffer anzeigen und mit Informationen aus dem SVN-Log anreichern. Ich brauche hier keine generierten Quellcode-Dokumentationen, Code Coverage oder irgendwelche Softwaremetriken. Nicht, dass dies unwichtig wäre, aber das dient eher zu Verbesserung bzw. Dokumentation des Projektes. Was ich im Rahmen einer einfachen Continuous Integration haben will, ist eigentlich ganz einfach und läßt sich in folgender Aussage auf den Punkt bringen: Könnte man das Projekt jetzt deployen? Dafür reichen meiner Meinung nach zunächst Unit-Tests und eine Auswahl an CodeSniffs. Durch die Beschränkung auf diese zwei Tools erreicht man, dass der Buildprozess recht schnell bleibt und somit auch häufig statt finden kann.
Damit PhpCilux die Builds eines Projektes anzeigen kann, bedarf es eigentlich auch nicht viel. Pro generiertem Projekt gibt es einen Ordner. In diesem Ordner gibt es dann einen Unterordner “reports”, welcher wiederum die eigentlich Build-Ordner enthält. In den einzelnen Ordern können dann die Logfiles von PHPUnit, PHP_CodeSniffer oder SVN liegen: phpcs.txt, phpunit.txt und svnlog.xml.
Als Projektname wird der Name des Ordners verwendet. Gleiches gilt auch für die Namen der einzelnen Builds.
Wie diese Daten dort hin gelangen, ist PhpCilux vollkommen egal. Für meine Entwicklungen habe ich mich für ein phing-Buildscript entschieden. Sie könnten aber auch via Cronjob, manuelles Kopieren oder irgend einen anderen Weg dort landen. Also jedem das seine und für mich kein Aufwand einer Entwicklung.
So kommen wir jetzt zum Schluß. Es ist früh und ich muss morgen ja wieder arbeiten. Aber eins noch: Ich freue mich auf konstruktives Feedback und mal sehen, vielleicht gibt es auch bald den großen Bruder für PhpCilux…