• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Ant – Build Skripte

    von am 9. August 2010

    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.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    13 Kommentare »


    • duffman
      am 9. August 2010 um 07:12 Uhr

      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.


    • robo47
      am 9. August 2010 um 07:21 Uhr

      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.


    • Ralph Meier
      am 9. August 2010 um 07:53 Uhr

      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.


    • Ralf Eggert
      am 9. August 2010 um 08:07 Uhr

      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.


    • Christian
      am 9. August 2010 um 08:30 Uhr

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


    • Sebastian
      am 9. August 2010 um 08:35 Uhr

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


    • Norbert
      am 9. August 2010 um 09:02 Uhr

      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.


    • duffman
      am 9. August 2010 um 09:17 Uhr

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


    • Ulf Kirsten
      am 9. August 2010 um 09:54 Uhr

      @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.


    • Flyingmana
      am 9. August 2010 um 09:55 Uhr

      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?


    • Tom
      am 9. August 2010 um 10:20 Uhr

      @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.


    • Sebastian
      am 9. August 2010 um 22:11 Uhr

      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.


    • Igor
      am 10. August 2010 um 21:59 Uhr

      > Also bei uns haben wir build-skripe die sich um viele Dinge kümmern…

      Aber so Dinge wie Doku neu bauen passiert nicht bei jedem Commit, oder?

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.