Apache Zeta Components: Build-Systeme
Kommentare

Was tut sich eigentlich bei Apache Zeta Components? Alle Informationen dazu aus der Kolumne aus dem PHP Magazin 5.2011 von Tobias Schlitt.

Aus gegebenem Anlass möchte ich in dieser Kolumne das Thema

Was tut sich eigentlich bei Apache Zeta Components? Alle Informationen dazu aus der Kolumne aus dem PHP Magazin 5.2011 von Tobias Schlitt.

Aus gegebenem Anlass möchte ich in dieser Kolumne das Thema Build-Systeme aufnehmen, das derzeit für Diskussionen auf der Entwickler-Mailingliste des Zeta-Projekts sorgt. Automatisierte Build-Prozesse entstammen eigentlich dem Umfeld kompilierter Sprachen: Hier wird die Erzeugung lauffähiger Binärdateien und weiterer Artefakte wie Bibliotheken automatisiert. Aber auch in PHP-basierten Projekten ergibt der Einsatz eines Build-Systems Sinn, denn auch hier können viele Aufgaben automatisiert werden. Typische Beispiele aus dem Zeta-Projekt finden sich auch bei den meisten anderen Entwicklungsteams: Das Erstellen von Releasepaketen, die Neugenerierung der Websiteinhalte oder das Durchlaufen von Tests und Berechnen von Metriken.

Der Grundaufbau der meisten Build-Systeme ist ähnlich: Der Entwickler beschreibt so genannte Tasks, die jeweils möglichst modular eine Aufgabe realisieren. Beispiele sind „Führe Unit Tests einer Komponente aus“ oder „Erstelle ein Release-File“. Dazu können für Tasks Abhängigkeiten definiert werden: Bevor „Erstelle ein Release-File“ ausgeführt werden darf, soll sichergestellt sein, dass „Führe Unit Tests einer Komponente“ für alle Komponenten erfolgreich durchgelaufen ist.

Stellt sich die Frage: Welches der vielen verfügbaren Build-Systeme soll zum Einsatz kommen? Bis dato waren dies im Zeta-Projekt meist hausgemachte Bash-Skripte und vereinzelte Make-Files. Natürlich können Sie Build-Skripte in jeder Programmiersprache entwickeln; dedizierte Build-Systeme wie GNU Make bieten aber mehr Komfort, indem sie die entsprechende Struktur bereits mitbringen. Es gilt also, für Zeta zu evaluieren, welches Build-System die Anforderungen des Projekts erfüllt. Die komplette Analyse vorzustellen, würde den Rahmen dieser Kolumne leider sprengen, weshalb ich mich hier auf eine kurze Zusammenfassung konzentriere: GNU Make entstammt der C-Entwickler-Gemeinde und ist auf Unix-/Linux-Systemen äußerst populär. Sein großer Vorteil ist, dass so gut wie jeder Entwickler auf diesen Systemen Make bereits installiert und es auch schon mal ausgeführt hat. Vor-, aber auch Nachteil ist, dass Make Files auf Bash (und oft auf Perl) basieren. Der so erreichten Flexibilität fällt die Plattformunabhängigkeit zum Opfer: Windows-Benutzer gucken in die Röhre.

Zum Industriestandard außerhalb der C-Community avanciert derzeit das Java-basierte Ant. Hier werden Build-Skripte in XML definiert und systemunabhängig von einem Java-Tool interpretiert und ausgeführt. Natürlich muss jeder Entwickler, der ein Ant-Build-File ausführen möchte, Java, das Tool selbst und potenzielle Erweiterungen installiert haben. Außerdem: Fehlt ein Basis-Task, muss er in Java selbst implementiert und mit dem Build-Skript ausgeliefert werden. In der PHP-Welt existieren daneben Portierungsansätze dieser beiden Systeme: Pake ist an Make angelehnt, verwendet jedoch PHP als Skriptsprache, und Phing biedert sich an, Ant in PHP nachzubauen. Das Zeta-Projekt evaluiert derzeit Pake detaillierter. Der aktuelle Platzhirsch Ant wurde leider aus verschiedenen Gründen disqualifiziert, maßgeblich, da es PHP-Entwicklern möglichst leicht gemacht werden soll, Builds auszuführen und neue Skripte zu entwickeln. Make wurde insbesondere von Entwicklern mit C-Hintergrund favorisiert, erfüllt aber das Kriterium der Plattformunabhängigkeit nicht. Phing sollte hier einen guten Kompromiss darstellen, bietet leider keine echte Kompatibilität zu Ant, und das „Programmieren“ in XML empfinden einzelne Entwickler als störend.

Abschließend bleibt mir zu empfehlen: Automatisieren Sie in Ihren PHP-Projekten möglichst viel. Die Faustregel heißt: Jede Aufgabe, die mehr als zweimal durchgeführt werden muss, sollte automatisiert werden. Das erspart viel Zeit und eine ganze Menge menschlicher Fehler. Außerdem werden Prozesse dadurch inhärent dokumentiert und natürlich voll reproduzierbar. Build-Skripte ebnen auch den Weg in Richtung Continuous Integration und Continuous Deployment. Welches System Sie letztendlich einsetzen, ist stark von Projekt und Vorlieben abhängig. Meine leicht subjektive Empfehlung zum Schluss: Nutzen Sie Ant!

Tobias Schlitt ist Diplom-Informatiker (Uni) und arbeitet seit mehr als 10 Jahren in professionellen Webprojekten auf Basis von PHP. Als Open-Source-Enthusiast beteiligt er sich an verschiedensten Community-Projekten. Tobias ist Mitgründer der Qafoo GmbH, 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 -