PHP-Projekte mit Arbit managen
Kommentare

Kontinuierliche Integration
Kontinuierliche Integration bedeutet das kontinuierliche Verifizieren der eigenen Software. Der erste Schritt um das zu erreichen ist bekanntermaßen die lokale Integration.

Kontinuierliche Integration

Kontinuierliche Integration bedeutet das kontinuierliche Verifizieren der eigenen Software. Der erste Schritt um das zu erreichen ist bekanntermaßen die lokale Integration. Das heißt, dass lokal ein Build-Prozess existieren muss, der alle relevanten Tests und Überprüfungen ausführt. Mittlerweile folgt dem auch Arbit und setzt einen lokalen Build-Prozess voraus. Solange irgendeine Form von lokalem Build-Prozess existiert, der sich über die Shell ansteuern lässt und aus dem Dateien mit den Build-Resultaten herausfallen, kann Arbit damit umgehen.

Entsprechend einfach ist aktuell auch die Konfiguration des Build-Moduls. Neben der Angabe, welches Kommando ausgeführt wird, muss angegeben werden, welche Dateien sich nach dem Build wo befinden, damit diese weiter verteilt werden können. Für jede so vom Build-Prozess erzeugte Datei wird dann ein Signal emittiert, das dann von anderen Modulen eingefangen werden kann. Für ein Projekt, das die Ant Build Commons von Manuel Pichler verwendet, sähe die Konfiguration dann entsprechend aus wie in Listing 2.

Listing 2
 [main]
command = ant

[artifacts]
artifacts[checkstyle] = build/logs/checkstyle.xml
artifacts[phpmd] = build/logs/phpmd.xml
# ...

Dem Kommando können optional natürlich noch Argumente, ein Ausführungsverzeichnis und Umgebungsvariablen übergeben werden. Eigene Build-Typen können definiert werden, allerdings muss dafür natürlich ebenfalls eine entsprechende Anzeigelogik existieren. Wenn das Build ausgeführt wurde, wird, je nach Erfolg oder Misserfolg, von dem Build-Modul ein Signal emittiert. Insbesondere über das buildFailed-Signal will man sich als Projektmanager benachrichtigen lassen.

Grafische Aufbereitung

Das Continuous-Integration-Modul aggregiert anschließend nur noch die von dem Build-Modul erzeugten Resultate und bereitet sie grafisch auf. Das können entweder ausführliche HTML Reports, wie in etwa die Fehlerliste von Coding Style Violations, oder die Ergebnisse des Testlaufes sein oder Graphen auf dem Continuous Integration Dashboard. Ich persönlich finde die Graphen, die Projektumfang, Testumfang oder Fehlerzahl beschreiben und mir einen Einblick in die Tendenz über die Projektlaufzeit ermöglichen, am aussagekräftigsten.

Abb. 2: Build-Verlauf im Arbit-CI-Modul

Ein Beispiel für so einen Projektverlauf ist die in Abbildung 2 gezeigte Build Timeline. Auf der x-Achse ist das Datum eingetragen, auf der y-Achse die Tageszeit, und jeder Punkt in dem Graphen repräsentiert genau ein Build. Die Grafik gibt damit sehr schnell Aufschluss über zwei verschiedene Projektmaße: Wann wurde committet und damit ein neues Build getriggert? Und ist das Build erfolgreich verlaufen? In dieser Grafik sind gescheiterte Builds durch einen orangefarbenen Punkt markiert. Klickt man im Continuous-Integration-Modul von Arbit auf einen dieser Punkte, so landet man direkt bei dem Build Report, um zu sehen, was das Scheitern des Builds verursacht hat.

Status

Wie zu Beginn geschrieben, befindet sich Arbit aktuell in einem Alphastatus. Dieser Alphastatus kommt daher, dass zum Zeitpunkt des letzten Release das Projekt noch nicht alle für eine Stable eingeforderten Features implementierte. Nichtsdestotrotz wird es bei einigen Unternehmen bereits zur Verwaltung ihrer Projekte eingesetzt. Die Weiterentwicklung von Arbeit geht aktuell leider weniger zügig voran als es sich die Projektmitglieder wünschen würden. Die stabile Basis und eine bereits gut nutzbare Modullandschaft sind vorhanden, allerdings sind die Entwickler alle beruflich stark involviert, was die Weiterentwicklung leider verzögert. Auf der anderen Seite wird sowohl der Kern von Arbit als Basis für andere Projekte eingesetzt als auch einige der Subprojekte, die im Ecosystem von Arbit entstanden sind, aktiv von anderen eingesetzt.

Kore Nordmann arbeitet seit mehr als zehn Jahren in professionellen Webprojekten auf Basis von PHP. Als Open-Source-Enthusiast beteiligt er sich an verschiedensten Communityprojekten. Kore ist Mitgründer der Qafoo GmbH (http://qafoo.com), die Services rund um hochqualitative PHP-Entwicklung anbietet, sowie Consulting, Training und Support zu Apache Zeta Components.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -