Ant - Build Skripte - the web hates me

Nachdem mein Artikel über JavaScript-Komprimierung so bombig angekommen ist wollen wir heute mal wieder ein wenig über was diskutieren, bei dem es kaum eine andere Meinung geben kann. Eigentlich erkläre ich nur ein paar Fakten und stelle euch ein Tool vor. Viele von euch werden es schon mal gehört haben, wie viele es tatsächlich verwenden weiß ich leider nicht. Auf jeden Fall geht es um das Build Tool ant.

Der kleine Helfer stammt aus dem Java-Umfeld. Zumindest kam er damals dafür auf. Schon lange haben sich viele Programmiersprachen an dieses Tool rangemacht. Vielleicht werden sich jetzt ein paar Leute fragen, wofür man ein Build-Skript im PHP-Geschäfft braucht. Man baut ja schließlich nichts. Trotzdem kann man das gebrauchen, auch in einer interpretierten Welt.

Viele von euch werden ein Continuous Integration System verwenden. Vielleicht kennt man von dort ant. In vielen CI-Lösungen ist dies nämlich die Standard-Lösung für Projekte. Was kann in einem Bau denn zum Beispiel passieren? Also bei uns haben wir build-skripe die sich um viele Dinge kümmern. Ein paar möchte ich hier auszählen.

PHP_CodeSniffer. Bei jedem Commit will ich, dass der CodeSniffer ohne Fehler durchläuft
PHP lint. Die Sourcen sollten keine Sytaxfehler beinhelten
PHPUnit. Meine Unit Tests sollten durchlaufen
QUnit. Meine JavaSkript Unit Tests sollten auch durchlaufen
PHPDoc. Meine Doku soll erstellt und an den richtigen Ort kopiert werden

Jetzt könnte ich natürlich ein Shell-Skript schreiben, dass all diese Dinge ausführt. Will ich aber nicht, denn das Apache-Projekt kann das viel geschmeidiger und wie ich finde viel intuitiver. Schauen wir uns doch einfach so ein Skript an, bevor ich noch mehr erzähle, was niemanden interessiert.


<project name="phpdoc" default="build" basedir="..">
  <target name="phpdoc">
    <echo message="Creating PHPDoc" />
    <mkdir dir="phpdoc" />
    <exec dir="${basedir}" executable="/app1/cmcwork/bin/phpdoc">
      <arg line="--directory ${basedir}/path/to/sources}
                 --quiet on
                 --undocumentedelements on
                 --title 'phm-Dokumentation'
                 --sourcecode on
                 --output HTML:Smarty:PHP
                 --target phpdoc" />
    </exec>
  </target>
  <target name="build" depends="phpdoc" />
</project>

Ich würde mal sagen, dass Skript erklärt sich von selbst. Allumschließend gibt es immer das Projekt, das gruppiert die einzelnen Tasks, die aufgerufen werden können. Diese Tasks nennen sich übrigens Targets im Ant-Jargon. Im Projekt kann ich dann noch einen default Task angeben, der aufgerufen wird, wenn ich mein ant Skript ohne ein explizites Target aufrufe.

Ich habe hier bewusst ein Beispiel ausgewählt, dass jeder einfach so lesen kann. Natürlich gibt es noch viele Features, die aus diesem kurzem Snippet nicht klar werden, aber für den ersten Einblick reicht es wohl. Da fällt mir gerade ein, dass ja noch was fehlt. Wie rufe ich das ganze denn eigentlich auf? Simpler könnte es nicht sein.

Ihr speichert das Skript unter build.xml und gebt auf der Kommandozeile ant ein. Fertig. Den Rest macht das Tool von selbst. Im besten Fall ist jetzt bereits eure Dokumentation erstellt.

Diese oder nächste Woche werde ich noch einen Beitrag nachreichen, der erklärt, wie man mit Properties umgeht und auch Fallentscheidungen einbaut. Aber ich denke es reicht für heute erstmal.

14 Comments

Das tolle an Netbeans ist ja, dass es eine voll Unterstützung von Ant hat. Die Build.xml wird im Projekt ganz normal angezeigt, per Kontextmenu lassen sich anschliesst die verschiedenen Buildvarianten auswählen, sprich die man mit dem Tag definiert hat. Eine Konsole braucht man nicht mehr. Man auch die build.xml 1:1 vom Integrationsserver benutzen. Man muss nur die Pfade anpassen.

Anstatt Pfade anpassen, kann sie auch in variablen packen und in einer externen datei speichern (properties-dateien lassen sich ja problemlos laden) und das buildscript lädt dann anhand von env-variablen, hostname oder ähnlichem, die passende properties-datei.

Kennt jemand noch ne gute Seite mit Tutorials oder sonstige gute Quellen? Bin mit der API nie wirklich warm geworden.

Gibts ne Möglichkeit, sich für PHP Teile des Build Skriptes per GUI zusammenzuklicken? Wenn ich mit Java vergleiche empfand ich das immer ein bisschen mühsam.

Und bei Eclipse kann man dann noch Ant so einsetzen, dass man im Projekt nur Shift+Alt+x und dann c drücken muss und schon geht es los.

Und was ist mit phing? Wo sind die Unterschiede/Vorteile/Nachteile?

Und in vim ist es so eingerichtet dass man sogar nur :!ant drücken muss 😉

Da man Ant-Skripte auch importieren kann, muss man nicht immer das gesamte Skript für jedes neue Projekt schreiben bzw per copy & paste „erstellen“. Der Import hat weiter den Vorteil, dass neue Tasks automatisch in allen Projekten verfügbar sind.

@Nils: in deiner Auflisting sollte phpmd und pdepend nicht fehlen. Auch ist phpdoc für CI ziemlich übel, da die Buildzeit dadurch enorm verlängert wird. Ich lasse das phpdoc daher nur in einem „nightly build“ laufen.

Wenn Ant auf einen Arbeitsplatzrechner angewendet wird, finde ich phpDoc ein wenig überflüssig. Es reicht wenn es auf einen Server ausgeführt wird.

@Christian
Phing ist zu 100% Ant-kompatibel, d.h. die gleichen Build-Skripte kannst du auch per Phing ausführen. Bei Phing kannst du zusätzlich eben eigene Tasks als PHP-Implementation schreiben, die vorhandenen Tasks sollten aber in 95% der Fälle zu 95% ausreichen. Und bei den restlichen 5% kannst du nun entscheiden ob du dies manuell machst, lieber Ant oder Ping erweitern willst oder deine Anforderungen anpasst. Ist sicherlich auch eine Kostenfrage.

Also ich finde Ant nicht so toll.

Der einzige Grund der sich mir da zunächst erschließt, dass man die erlaubten nutzbaren Programme beschränken will.
Ansonsten ist jegliche Form von xml doch immer ein etwas höherer Aufwand, weil man noch eine weitere „Syntax“ lernen und anwenden muss.

Bietet Ant denn wenigstens den Vorteil, dass die einzelnen Aufgaben parallel und eventuell auf unterschiedlichen Maschinen ausgeführt werden können?

@Flyingmana genau das ist der Grund: mit Ant kann man unter Windows oder MacOS ein Skript schreiben, dass anschließend unverändert unter Linux läuft. Deswegen benutzt man das für Build-Prozesse, vor allem in heterogenen Umgebungen und für CI-Server, die eine bekannte Syntax der Log-Dateien voraussetzen um automatisch Reportings zu erzeugen.

Im Übrigen haben wir in der Praxis keinen Vorteil von Phing zu Ant festgestellt. Die speziellen, auf PHP zugeschnittenen Steps in Phing haben in der Praxis alle nicht so funktioniert wie erwartet, weil zum Teil wichtige Parameter gefehlt haben. Wir mussten alles auf Execs zurückbauen.

Wir haben auch Ant im Einsatz. Die Lernkurve ist steil. Die Dokumentation ist eigentlich für einen PHP Developer ausreichend.

Wenn man sowieso weiss das hauptsächlich auf Linux kisten eingesetzt wird kann man die einzelnen Targets auch über exec lösen. Das klappt super bei uns.

Eine komplette Magento Installation inklusive Konfiguration innerhalb von 6 Minuten – mit einem Befehl ant install

Die angesprochene property Datei sollte man auch auf jedenfall verwenden. Wir nennen diese deploy.properties und im Kopf der build.xml ist ein Kommentar mit allen möglichen Konfigurationseinstellungen für die Spezifika des Projektes.

So kann jeder Entwickler seine eigene Konfiguration verwenden und auf den Entwicklungs – und CI Servern ist auch jeweils eine eigene Einstellung.

Alles in allem hat es uns schon sehr viel Zeit eingespart und wir können das gleiche für jedes neue Projekt verwenden.

Zum Thema phing weiss ich nur das es nicht mehr aktiv weiterentwickelt wird. Es gab damals einige Probleme auf die ich gestossen bin die ich nicht lösen konnte.

Somit hatte ich mich für ant entschieden.