Eine Aktion zur PHP-Einrichtung Für die wichtigsten Punkte, die notwendig sind, um ein auf PHP basierendes Projekt zu testen, gibt es die Action setup-php. Diese bietet unter anderem folgende Möglichkeiten:
unterschiedliche PHP-Versionen verwenden PHP-Extensions einrichten PHP-Konfigurationen vornehmen zusätzliche, häufig verwendete Tools installieren Diese Aktion sollte für allgemeine Anwendungen keine Wünsche offen lassen. Wir verwenden diese Aktion seit einigen Monaten in mehreren Repositories ohne jegliche Probleme.
Weitergehende Möglichkeiten Auch Matrix-Builds sind möglich: hiermit lässt sich ein Workflow für mehrere Betriebssysteme und/oder PHP-Versionen ausführen.
Nach der allgemeinen Einführung in GitHub Actions kommen wir nun zu dem ersten Anwendungsfall, der in vielen Projekten angewendet werden kann. Fast jedes Softwareprojekt bedient sich heutzutage zusätzlicher Drittkomponenten. Diese müssen regelmäßig geprüft und auf Stand gehalten werden, um sowohl Fehlerkorrekturen als auch neue Funktionen zu erhalten. In den meisten Programmiersprachen und Umgebungen kommen Paketmanager zum Einsatz, mit denen diese Abhängigkeiten verwaltet und gepflegt werden. Das ist eine geeignete Voraussetzung dafür, die Updates zu automatisieren.
Mit GitHub Actions ist es möglich, beliebige Workflows in einem GitHub Repository zu definieren und dort auch automatisch ausführen zu lassen. Das können Builds und Tests zur kontinuierlichen Integration sein, aber auch völlig unabhängige Prozesse, zum Beispiel zur regelmäßigen Prüfung bestimmter Anforderungen.
In den letzten Wochen und Monaten haben wir mehrere Dutzend Workflows mit GitHub Actions abgebildet und entsprechende Erfahrungen gesammelt. Im Rahmen einer kleinen Artikelserie werden wir einige der vielfältigen Möglichkeiten vorstellen, die sich mit GitHub Actions auftun.
Seit dem kürzlich angekündigten Start der Testautomatisierung von ModuleStudio ist bereits eine Menge geschehen. So gibt es knapp 1.000 Tests für die DSL, darunter vorwiegend für UI-unabhängige Komponenten, wie den Parser, den Serialisierer, den Formattierer und die Validierungsregeln. Hier haben wir eine Testabdeckung von etwa 95% erreicht und konnten einige Fehler in der Validierungsschicht beheben.
Auch der Generator wird bereits mit einer Abdeckung von über 90% getestet. Hier ging es bislang allerdings vorwiegend darum, möglichst viele Varianzen zu durchlaufen, um zum Beispiel Null Pointer Exceptions zu verhindern.
Schon ewig geplant, aber lange schmählich vernachlässigt, habe ich bei ModuleStudio die automatisierten Tests. Zwar ist schon seit Längerem die Infrastruktur dahingehend ausgerichtet, was beispielsweise die Git-Struktur und die Jenkins-Pipelines anbelangt, allerdings bringt das relativ wenig, wenn es fast nur Dummy-Tests ohne jeglichen Inhalt gibt.
Da ModuleStudio 1.1.0 kürzlich veröffentlicht wurde, konnten danach in der Entwicklungsversion 1.2.0 einige Altlasten entfernt werden. Da hat es sich im Hinblick auf Timing und Ausgangslage angeboten, endlich zu starten.
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.
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.
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.
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.
