• Vorträge

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

    • Continuous Integration: Ein Erfahrungsbericht

    von am 11. Mai 2010

    Heute geht der Dank an Daniel Fahlke, er hat sich die Mühe gemacht einen Artikel über seine Erfahrungen mit Continuous Integration zu schreiben. Es ist sein erster Artikel bei uns, seid also nett. Ja dann würde ich mal sagen Bühne frei für Daniel.

    Nun, ihr kennt das bestimmt. Ich und ein Kumpel wollten gemeinsam ein PHP Projekt beginnen. Da wir es damit jedoch nicht so eilig haben, beschlossen wir die Gelegenheit zu nutzen, dies zu einem Musterprojekt für uns zu gestalten, in dem wir alles anwenden, was zu einem vorbildlich geführtem PHP Projekt gehört. Die Verwendung von SVN ergab sich praktisch von selbst. Auch die Verwendung von Unit Tests war klar.

    Aber nun fingen wir an zu grübeln. Nicht nur, dass wir die Auswertung von den Unit Tests gerne Zentral hätten, wir mögen es auch, dass die Ergebnisse und Statistiken in ansehnlicher weise aufbereitet werden. Wir kamen zu dem Schluss, dass wir eine continuous integration Umgebung brauchten.

    Erst mal dazu, was eine continuous integration Umgebung bzw continuous integration selbst ist und was es beschreibt. Als Hilfe gebe ich mal die deutsche Übersetzung “Kontinuierliche Integration” dazu. Wobei, gehen wir doch mal etwas zurück, bevor die Kontinuierliche Integration genutzt wurde. Da lief es folgendermaßen ab. Wenn eine Software weiter entwickelt wurde, dann arbeitete man bis zum nächsten Release und schaute dann, wie man die Software auf der Zielplattform zum laufen bekommt und versucht alle Fehler zu beseitigen. Das ist dann nicht nur ein sehr zeitintensiver Prozess, man muss sich dann teilweise mit der Funktionsweise von  Programmteilen auseinandersetzen, die man zuletzt vor mehreren Monaten angesehen hatte. Wenn man nun diese Integration stetig parallel zur Entwicklung ausführt, erfährt man nicht nur schneller, wenn etwas nicht funktioniert, man ist auch noch direkt in der Materie drinnen, um dies schnell beheben zu können ohne sich wieder lange einarbeiten zu müssen. Dies kann bei größeren Projekten je nach Rechner durchaus schon mal eine halbe bis ganze Stunde pro Integration dauern. Und sämtliche Abhängigkeiten müssten auch noch erfüllt werden. Da ist eine zentrale Stelle fürs Compilieren bzw. der Build Erstellung schon eine erhebliche Erleichterung. Finden tut man dies auch in der Open Source Szene häufig in Form sogenannter Nightly Builds.

    Erweitert wurde dies dann in einigen Sprachen wie zum Beispiel Java um Unittests, die vor jedem Build durchlaufen werden um Fehler die durch Änderungen entstehen schneller auffinden zu können. Dazu kamen dann später noch zusätzlich CodeSniffer, die auf unsaubere Codestellen hinweisen sollen, Programme zur statistischen Auswertung des Codes und welche zur Generierung von Dokumentationen. Und dies wäre dann auch schon eine Beschreibung einer Kontinuierlichen Integration Umgebung.

    Die bekanntesten und verbreitetsten sind wohl Hudson und CruiseControl, welche beide in Java geschrieben sind. Und das war auch schon der Grund, wieso wir uns erstmal weiter nach Alternativen umgesehen haben. Java ist nämlich nicht unbedingt unser Freund und wir hätten möglichst gerne etwas in der Sprache, die wir auch zum Entwickeln nutzen, weil wir gerne verstehen würden wie es funktioniert, oder zumindest verstehen wollten wieso, wenn etwas nicht funktioniert.

    Schließlich hörten wir von der Project Tracking Software Arbit. Nicht nur, dass es komplett in PHP geschrieben ist, es verwendet als Backend CouchDB, welches wir so auch endlich mal gut im Einsatz erleben können und Beispiele für die Verwendung haben. Es gibt jedoch einen durchaus gravierenden Haken. Der derzeitige Release ist noch als Alpha gekennzeichnet. Dies bezieht sich jedoch nicht auf die Stabilität, sondern darauf, dass es noch nicht alle Funktionen besitzt, die von einer vollständigen continuous integration Plattform erwartet würden und das einrichten noch relativ unkomfortabel über das editieren von mehreren Konfigurationsdateien pro Projekt geht. Jedoch muss ich sagen, dass viele der für die Entwicklung genutzten Funktionen bereits verfügbar sind und einwandfrei funktionieren, wenn sie denn erst mal eingerichtet sind.

    Wer sich ein arbeitendes Beispiel ansehen möchte, Arbit nutzt sich selbst als continuous integration Umgebung. ( http://tracker.arbitracker.org/arbit ) Wer Support sucht, findet ihn am ehesten via IRC auf dem freenode server in #arbit bzw auf Deutsch in #arbit-de. Und wie sollte es auch anders sein, freiwillige Tester und Entwickler werden mit offenen Armen willkommen geheißen.

    13 Kommentare »


    • IchBinIch
      am 11. Mai 2010 um 07:18 Uhr

      Hallo,
      dann will ich mal nett sein und sage, schöner Artikel! ;)
      Allerdings weiß ich mittlerweile nur zu gut, was ein CI ist. Mich würde jetzt interessieren, wie Ihr (du und dein Freund) euer “Musterprojekt” konkret umsetzt und wie eurer Entwicklungsprozess am Ende aussieht.
      Ich hoffe auf noch ein paar interessante Artikel zu diesem Thema!

      mfg
      IchBinIch


    • Andi
      am 11. Mai 2010 um 07:45 Uhr

      Sehr guter Einstiegsartikel, der Appetit auf mehr (Details) macht.


    • Stephan Hochdoerfer
      am 11. Mai 2010 um 08:36 Uhr

      Bin auch gespannt auf mehr. Mich würde vor allem einmal ein Vergleich der CI Server interessieren. phpUnderControl scheint weit verbreitet zu sein, über Hudson liest man auch immer mal wieder etwas. Wir haben uns für den leichtgewichtigen Ansatz trac + bitten entschieden. Was ist das Mittel der Wahl?


    • Christian
      am 11. Mai 2010 um 08:54 Uhr

      @Stephan Ich hab da kuerzlich so einen Vergleich zwischen Hudson und phpUnderControl angestellt. Vielleicht interessiert der dich ja.
      http://test.ical.ly/2010/05/05/continuous-integration-hudson-vs-phpundercontrol/


    • Stephan Hochdoerfer
      am 11. Mai 2010 um 09:09 Uhr

      @Christian Danke klingt vielversprechend :)


    • Daniel
      am 11. Mai 2010 um 09:10 Uhr

      Hab ich was verpasst, kommt noch was oder fehlt da der Erfahrungsbericht? Was steht denn da, was man nicht bei Wikipedia oder dergleichen lesen kann?


    • Manuel Pichler
      am 11. Mai 2010 um 09:11 Uhr

      Netter Artikel,

      aber wie einer meiner Vorkommentierer schon schrieb, lässt die Überschrift eher einen Erfahrungsbericht zum Thema Continuous Integration erwarten, als eine reine Begriffsdefinition. Einen Außerdem fehlt mir irgendwie ein bisschen mehr Erklärung zum Wort Integration, denn einer der großen Vorteile dieser Arbeitstechnik besteht ja darin, dass mehrere Entwickler(teams) an ein und dem selben Projekt arbeiten können, als würden sie dies alleine tun. Durch Continuous Integration werden die dadurch fast immer entstehenden Inkompatibilitäten unmittelbar sichtbar und können zeitnah, mit höchster Priorität behoben werden.

      Beste Grüße
      Manuel


    • Daniel Fahlke
      am 11. Mai 2010 um 09:39 Uhr

      Erst mal danke, dass ihr so lieb zu mir seid *g*

      Um mal ein paar Dinge vorweg zu nehmen, das ist nur die Hälfte von meinem Artikel den ich geschrieben habe.
      Der zweite Teil wird nehme ich mal an auch in absehbarer Zeit noch veröffentlicht und geht dann mehr über unsere (relativ geringen) Erwartungen die wir an die Umgebung stellen, für welche wir uns entschieden haben und erzählen dann noch nen wenig darüber.

      Die Begriffserklärung wurde mir außerdem zunächst empfohlen zu machen, da es dazu noch nichts hier gab. Dass die Erklärung nicht so sehr in die Vorteile bei größeren Teams eingeht tut mir Leid, aber ich hatte bisher noch nicht das Vergnügen in einem größeren Entwicklerteam zu arbeiten.
      Ich werde jedoch gerne diesen Artikel noch erweitern um die Dinge, die mir noch genannt werden.


    • Sven
      am 11. Mai 2010 um 09:53 Uhr

      Eine gute Einführung, die Appettit auf mehr macht. Da Teil zwei noch nicht veröffentlich hier schonmal ein paar Anregungen, was ich gerne lesen würde:
      - Welche Umgebung habt ihr verwendet
      - was für Probleme beim Einrichten hattet ihr
      - seit ihr mit dem aktuellen CI Prozess zufrieden
      - fazit ob ihr es wieder so oder vielleicht doch ganz anders machen würdet
      - vielleicht noch kurz ob sich das aus eurer sicht für euer projekt gelohnt hat (soviel ich heraus gelesen hatte ging es ja auch eher ums erfahrung sammeln) oder ob es sich eher nur für größere projekte lohnt


    • Tom
      am 11. Mai 2010 um 10:08 Uhr

      Wir haben uns nach langem Hin und Her für PHPUnderControl entschieden.
      Mich würde ja interessieren ob schon jemand Erfahrung mit Xinc gesammelt hat. Hudson-like interface, Phing- und PHPUnit-Integration, geschrieben in PHP5.

      Klingt zunächst wie ein CI-Server mit den Features von PHPUnderControl und der Nutzerfreundlichkeit von Hudson. Jedoch habe ich ernste Zweifel ob es bereits “ready for business” ist.

      Hat irgendjemand Erfahrungen?


    • Norbert Bartels
      am 11. Mai 2010 um 13:07 Uhr

      Wir nutzen den Hudson. Haben neben CodeSniffer auch pdepend, phpmd und sloccount eingebaut. Da PHP nicht compiliert wird, haben wir vor die ganzen Tools einen Syntax Check gesetzt. PHPUnit ist selbstverständlich. Das ganze System ist bei uns momentan noch in einer Testphase, wird von den Entwicklern sehr gut angenommen und das Management freut sich über die Diagramme.

      phpUnderControl ist bei uns rausgefallen, da es einen Zeitversatz in der Entwicklung zwischen CruiseControl und phpuc gab, der das System etwas instabil werden ließ. Xinc weil wir auch java entwickeln.


    • Nils Langner
      am 11. Mai 2010 um 13:37 Uhr

      SOOO … jetzt mal eine große Entschuldigung. Mein Google Mail hatte den Artikel gekürzt und die letzen zwei Abschnitte damit rausgeworfen. Leider hatte ich den Text hier im System nicht noch mal gegengelesen, sonst wäre mir das aufgefallen. Also SHAME ON ME! Der Artikel ist jetzt aber komplett und dann nochmal von euch gelesen werden :)


    • Julian
      am 11. Mai 2010 um 20:17 Uhr

      Mit der Ergänzung nun ein wirklich gut zu gebrauchender Artikel! :)
      Ich hatte mir Arbit vor einiger Zeit schon einmal angesehen und werde das nun noch genauer unter die Lupe nehmen.

      Noch ein bisschen an der Rechtschreibung (insbesondere groß/klein) arbeiten, dann ist es absolut perfekt :)

      Willkommen und danke für die Informationen!

    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.