Kategorien
Build-Pipeline
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.
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.
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.
Sauber. Ich glaub du hast gerade vortrefflich den Unterschied zw. Unittests (einfach, schnell) und Integrationstests (komplex, langsam) erklärt 🙂
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
Ich hab kann das ja mal als Talk bei der IPC einreichen, vielleicht mag das ja jemand hören bzw sehen. 🙂
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?
Sebastian, inklusive Konfiguration über Puppet und Continuous Deployment in der Cloud? 🙂
Denke momentan an VirtualBox, Vagrant und Chef. Wolkig genug?
Ja, reicht. Wenn ich auf der IPC sein sollte, können wir ja mal vergleichen. 🙂
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.
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?
@DerFichtl: Ich würde mal sagen, sobald der Ausfall der Webseite teurer ist, als das Einrichten solcher Tests.
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 … 😉