Get the MOST

In diesem Beitrag wird gezeigt, wie man eine ganze Reihe von Modulen automatisch mit Hilfe eines Bash-Skriptes neu generieren kann. Auch die Übersetzungen der Module können automatisch neu generiert werden. Das spart mühsame Handarbeit, insbesondere wenn die Anzahl der Module in größeren Projekten zunimmt.

Das erste Skript verwendet den Standalone Generator von ModuleStudio und aktualisiert damit die Implementierung der Module. Dateien, die in den Modellen in der markFiles-Direktive angegeben sind, werden entfernt - das ist aber Geschmackssache und kann je nach Vorliebe anders ausgestaltet werden.

Die Komponenten von ModuleStudio werden nun mit anderen Technologien gebaut. Statt Buckminster wird jetzt das Maven-basierte Tycho eingesetzt. Die Jenkins-Jobs wurden auf Pipelines umgestellt und unterstützen somit nun mehrere Branches.

Tycho für Features in mehreren Repositories

Im ersten Schritt habe ich daran gearbeitet, die Builds lokal mit Tycho zum Laufen zu kriegen. Eine Herausforderung dabei war es, die Builds für alle Komponenten, die in unterschiedlichen Git-Repositories liegen, mit möglichst wenig Redundanz zu beschreiben. Dies funktioniert über eine gemeinsame Root-POM, die im zentralen Produkt-Repository liegt. Dieses muß ohnehin allen Builds zusätzlich zum Repository der jeweiligen Komponente bekannt gemacht werden, da das Branding-Bundle von allen Features benötigt wird.

Gegenwärtig beschäftige ich mich mit zwei interessanten Punkten in Bezug auf Jenkins. Die neu gestaltete Website bietet dazu einen guten Einstiegspunkt.

Der erste Punkt dreht sich darum, Jenkins besser mit GitHub zu verzahnen.

• Hier steht insbesondere eine engere Integration des Build Status im Raum. Die Nutzung von Service Hooks erlaubt es, einen Build via Push zu starten, was sowohl schneller als auch effizienter als das zeitbasierte Polling des Git-Repositories seitens Jenkins abläuft.
• Durch die Commit Status API kann der Erfolg oder Fehler eines Builds zu einem Commit auf GitHub reflektiert werden.
• Der aktuelle Build-Zustand des Repositories sollte auf GitHub angezeigt werden.
• Auch Pull Requests sollten ebenso wie der Hauptbranch gebaut werden.

Der zweite Bereich behandelt Pipelines, mit denen sich der Workflow eines Jobs flexibel orchestrieren lässt.

ModuleStudio 0.7 beinhaltet nun eine automatische Aktualisierung. Damit wird das Herunterladen neuer Versionen unnötig. Beim jeden Start der Anwendung werden verfügbare Updates gesucht und, sofern vorhanden, automatisch heruntergeladen und installiert.

Es gibt zwei Kanäle: stable und staging. Nach jeder erfolgreichen Erstellung eines Produktes durch den CI-Server werden die Dateien in das Staging-Repository kopiert. Release-Builds werden zusätzlich in das Stable-Repository kopiert.

In den Einstellungen von ModuleStudio lässt sich konfigurieren, ob lediglich stable Updates (Standard) oder auch staging Updates gewünscht sind. Falls die staging-Option aktiviert wird (was empfehlenswert ist, wenn man die neuesten Bugfixes und Neuerungen haben möchte), erhält man jedes mal ein Update, nachdem der CI-Server ein neues Produkt gebaut hat (was relativ häufig passiert, zum Beispiel nach einem Generator-Fix).

Wer seine Projekte regelmäßig mit einem Build-Server prüfen und testen lässt, erstellt oftmals auch eine API-Dokumentation. Dafür gibt es auch im PHP-Bereich eine Vielzahl unterschiedlicher Werkzeuge, beispielsweise PHPXref oder ApiGen. Dieser Beitrag stellt das Tool phpDox vor und gibt Einblick in das interessante Feature der Enricher.

Eine API-Dokumentation stellt in der Regel eine navigierbare Übersicht der in einem Projekt vorhandenen Klassen, Schnittstellen, Methoden usw. bereit. Damit können Entwickler, die diese Artefakte in ihrem eigenen Code nutzen wollen, Informationen über die benötigten Methoden einsehen und so beispielsweise herausfinden, welche Argumente eine bestimmte Funktion erfordert.