• Vorträge

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

    • Build-Pipeline

    von am 4. Februar 2011

    Ich hatte ja vor kurzem das Vergnügen drei Vorträge von Martin Fowler zu hören, da er einen Abend Zeit hatte uns Hamburgern ein wenig zu erzählen. Da ich Gurus immer mal wieder gerne zuhöre, war ich natürlich dabei. Der Vortrag war auch ok, aber eigentlich hat mich der Vortrag, der vorgelagert war, viel mehr interessiert. Es ging um Continuous Integration und Continuous Deployment. Ja ich weiß, alter Hut.

    Solche Vorträge sind für mich immer ein Erfolg, wenn man eine neue Sache dabei lernt. Und was soll ich sagen? Es ist passiert. Es wurde das Konzept der Build-Pipeline vorgestellt, was ich recht einfach und trotzdem spannend fand. Ich passe das ganze mal für die PHP/Webentwicklungs-Welt an.

    Wir kennen alle Selenium und wissen, dass das Ausführen echt schmerzhaft sein kann. Schmerzhaft im Sinne der Dauer. Ein ausführliches Testsetup kann da schon mal 30min dauern. Das ist natürlich Zeit, die man nicht hat. Was passiert also? Man ruft die Tests nur ab und zu auf.

    Hat man einen Continuous Integration Server, wie zum Beispiel Bamboo, Cruise Control oder Hudson, dann will mal möglichst schnell Feedback über das Stück Code, dass man gerade eingecheckt hat. Eine halbe Stunde warten will niemand. Unit Tests sind schnell, also werden nur diese dort eingehängt.

    Für mich war das immer Fakt und deswegen habe ich auch gar nicht mehr lange drüber nachgedacht: Alles was lange dauert, hat im Build nicht zu suchen. Tja, da war ich wohl zu kurzsichtig. Wer sagt denn, dass es nur einen Build geben kann. Die Idee der Build-Pipeline ist also geboren.

    Ich versuch das mal kurz zu beschreiben. Wir haben einen ersten Build-Durchgang. Dieser führt alle Unit Tests aus, sobald etwas comitted wurde. So wie das immer passiert. Ist dieser Build fehlerfrei durchgelaufen, wird die nächste Runde angetriggert. Hier werden jetzt alle Selenium-Tests ausgeführt. Wenn die Selenium-Tests durch sind, werden noch zeitintensivere Tests ausgeführt. Lasttests zum Beispiel. Jedes mal wenn einer von den langen Tests durchgelaufen ist, wird geprüft, ob ein Test vorher in der Pipeline schon positiv durchlief und baut dann gleich wieder.

    Ich finde die Idee auf jeden Fall sehr gut, was sie überhaupt verständlich? Eigentlich wollte ich ja ein paar Grafiken dazupacken, aber irgendwie wurde es dann doch so spät, dass keine Zeit mehr war. Werde auch versuchen das bei uns mal umzusetzen und danach die Skripte hier zur Verfügung zu stellen.

    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 »


    • Thorsten
      am 4. Februar 2011 um 08:01 Uhr

      Für unser aktuelles Projekt machen wir das ähnlich und steuern das per Ant. Ein einfaches “ant phpunit” führt wirklich nur die Unittests aus, das machen alle Entwickler lokal auf ihren Developer-VMs. Nach dem Push des Commits in unser zentrales Git-Repo startet dann Hudson (bald Jenkins) und führt ein “ant phpunit-integration” aus, bei dem dann auch neben einem Integrationstest via Zend_Test die Code Coverage gecheckt wird zzgl. von PHP_Depend, PHP_MD, PHP_CodeSniffer, phploc und PHP_CodeBrowser, was natürlich einiges an Zeit kostet.


    • Guido Faust
      am 4. Februar 2011 um 08:14 Uhr

      Gerade mit Hudson/Jenkins lässt sich das sehr einfach realisieren, hier kann man bei jedem “Projekt” in den Einstellungen angeben, ob es ein anderes antriggern soll, bzw. ob es von einem vorgelagerten Build abhängig ist.


    • Stephan Hochdoerfer
      am 4. Februar 2011 um 08:48 Uhr

      Sauber. Ich glaub du hast gerade vortrefflich den Unterschied zw. Unittests (einfach, schnell) und Integrationstests (komplex, langsam) erklärt :)


    • Arne Riemann
      am 4. Februar 2011 um 09:17 Uhr

      Moin,

      interessantes Thema, es wäre wirklich mal klasse dazu ein Tutorial oder ähnliches zu haben, welches den gesamten Aufbau so einer Plattform behandelt. Also falls sich jemand berufen fühlt :-)

      Arne


    • Thorsten
      am 4. Februar 2011 um 09:24 Uhr

      Ich hab kann das ja mal als Talk bei der IPC einreichen, vielleicht mag das ja jemand hören bzw sehen. :-)


    • Sebastian Bergmann
      am 4. Februar 2011 um 11:33 Uhr

      Ach Thorsten, ich halte doch schon einen Vortrag auf der IPC Spring über “Continuous Integration with Jenkins” ;-) Und natürlich werde ich da auch was über Build Pipelines erzählen.

      Allerdings frage ich mich gerade, warum wir den Vortrag nicht zu zweit eingreicht haben?


    • Thorsten
      am 4. Februar 2011 um 11:36 Uhr

      Sebastian, inklusive Konfiguration über Puppet und Continuous Deployment in der Cloud? :-)


    • Sebastian Bergmann
      am 4. Februar 2011 um 11:38 Uhr

      Denke momentan an VirtualBox, Vagrant und Chef. Wolkig genug?


    • Thorsten
      am 4. Februar 2011 um 11:39 Uhr

      Ja, reicht. Wenn ich auf der IPC sein sollte, können wir ja mal vergleichen. :-)


    • Tom
      am 4. Februar 2011 um 21:54 Uhr

      Na ja, so wirklich neu ist das mit den Build-Pipelines nun gerade nicht.

      Aber was ich wirklich spannend finde ist die Zukunft von Hudson. Erst hieß es, Oracle besäße die Rechte am Namen “Hudson”. Dann las man an anderer Stelle, das Projekt würde in “Jenkins” umbenannt (http://jenkins-ci.org/content/hudsons-future).
      Andernorts konnte lesen “Hudson is dead – long live Jenkins!” (http://qualityswdev.com/2011/01/11/hudson-is-dead-long-live-jenkins/).

      Und neuerdings sieht man bei Hudson-CI ein Oracle-Logo und eine Mitteilung von Winston (Oracle), es gäbe da zwar so einen “Fork” aber Oracle würde “Hudson” jetzt selbst weiterentwickeln. (http://hudson-ci.org/docs/news.html)

      Gibt es jetzt also “Hudson” made by Oracle und einer Allianz der Willigen, sowie einen “Jenkins”-Fork als Open-Source, betreut von einer Community, die sich im Stich gelassen fühlt?

      Das wirft auch ein interessantes Licht auf die anderen Projekte, die Oracle von Sun übernommen hat. Man fragt sich als Entwickler unweigerlich, was als nächstes kommt.


    • DerFichtl
      am 7. Februar 2011 um 19:16 Uhr

      Mich würd mal interessieren ab welcher Projektgröße man ein solches Test-Setup aufbauen sollte … kann man das in Code Zeilen oder Entwicklern sagen?


    • Nils Langner
      am 7. Februar 2011 um 20:37 Uhr

      @DerFichtl: Ich würde mal sagen, sobald der Ausfall der Webseite teurer ist, als das Einrichten solcher Tests.


    • DerFichtl
      am 7. Februar 2011 um 23:43 Uhr

      Hallo Nils. Find ich grundsätzlich eine super Antwort aber ob ich damit so einfach durchkomme, ich hör da schon einige Gegenargumente …

      1. Bisher hat es auch wunderbar ohne funktioniert
      2. Braucht zu viel Zeit, es geht ja jetzt schon viel zu langsam vorwärts
      3. Test-Server usw. bringen zusätzliche Komplexität/Kosten

      Wahrscheinlich kann mans sehr einfach durchsetzen wenn die Seite wirklich mal etwas länger steht … ;)

    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.