Continuous Integration im Überblick

5 Kommentare

„Ihr seid doch agil, benutzt ihr auch den Hudson?“

Das ist eine gute Frage, die man – so oder so ähnlich – immer wieder von Leuten hört, die durchaus an agilen Themen interessiert sind, sich aber noch nicht wirklich weiter damit beschäftigt haben.

Aber was ist jetzt eine gute Antwort auf diese Frage? Ein einfaches „Ja!“ entspricht zwar den Tatsachen, würde der Sache aber nicht wirklich gerecht werden. Die tool-orientierte Antwort könnte auch lauten: „Ja, wir benutzen Hudson, aber wir könnten auch Bamboo oder Cruise Control nutzen.“ Verbunden mit einer länglichen technischen Begründung, warum wir uns letzten Endes für Hudson als Werkzeug entschieden haben. Hilfreich? Vermutlich eher nicht! Also nehmen wir noch einen Anlauf für eine Antwort: „Ja, wir benutzen Hudson als einen Teil unserer Umgebung für kontinuierliche Integration (Continuous Integration). Dieses wird komplementiert durch ein passendes SCM-Konzept und automatisierte Tests.“ Soweit so gut, aber zu kontinuierlicher Integration gibt es doch noch eine Menge mehr zu sagen und damit sind wir am eigentlichen Start dieser kleinen Artikelserie über Continuous Integration.

Kontinuierliche Integration – Was, Wie und Warum?

Was steckt hinter dem Begriff der kontinuierlichen Integration? Ich könnte jetzt hier natürlich Wikipedia zitieren, aber da kann jeder nach Bedarf selber nachlesen. Und es soll ja in diesem Überblick auch noch nicht zu sehr in die Tiefe gehen, das kommt dann später. Also:

Bei kontinuierlicher Integration werfen alle Entwickler allen Programmcode (mehrmals) täglich zusammen. Durch Kompilation auf einem unabhängigen Server – z.B. mit Hilfe von besagtem Hudson – wird garantiert, dass alle Teile zusammenpassen. Automatische Tests stellen sicher, dass der gesamte Programmcode wie erwartet zusammen funktioniert. Dieser gesamte Prozess läuft mehrmals täglich durch.

Das hört sich sicherlich einfacher an, als es ist. Aber bevor wir hier mehr ins Detail und die damit verbundenen Probleme – oder besser Herausforderungen 😉 – gehen, nehmen wir uns erst noch die Frage nach dem „Warum?“ vor. Warum sollte man kontinuierliche Integration in seinen Projekten und Produkten einführen? Für agile Projekte stellt sich diese Frage nicht wirklich. Ohne kontinuierliche Integration sind die kurzen Demo- und Produktzyklen überhaupt nicht durchführbar. Hierbei sind insbesondere automatisierte Tests das Rückgrat des Entwicklungsprozesses. Das Ziel dahinter ist zu jedem Zeitpunkt ein funktionierendes (Software-)Produkt ausliefern – oder zumindest demonstrieren – zu können. Als weiterer positiver Effekt werden (Integrations-)Probleme sehr früh im Projekt sichtbar und sind damit im Allgemeinen noch einfacher und damit kostengünstiger zu lösen.

Damit kommen wir wieder zu einer Frage: „Kann man kontinuierliche Integration auch in klassischen Projekten (Stichwort „Wasserfall“) verwenden?“ Die Antwort lautet denke ich jein. Testautomatisierung ist sicherlich auch in klassischen Projekten eine große Hilfe, denn auch hier kann der (manuelle) Testaufwand sonst irgendwann aus dem Runder laufen. Sein volles Potential entwickelt die kontinuierliche Integration aber erst zusammen mit agilen Entwicklungsmethoden, die dann auch zu sehr kurzen Entwicklungszyklen führen.

Was bleibt ist die Frage nach dem „Wie?“ Diese Frage bedarf einer umfangreicheren Antwort und wird daher im nächsten Abschnitt näher beleuchtet.

Aufbau einer Umgebung für kontinuierliche Integration

Eine Umgebung für kontinuierliche Integration kann beliebig komplex werden, abhängig von verschiedenen Faktoren wie dem Projektumfang, der Größe des Teams und auch dem Anspruch an das System.

Einschub „Gebrochene Builds“: Es ist unmöglich über Continuous Integration zu sprechen, ohne zu klären was wir unter einem Gebrochenen Build oder auch Broken Build verstehen. Unter einem Build wird bei kontinuierlicher Integration der gesamte Vorgang verstanden Programmcode zu integrieren, kompilieren und die automatischen Tests auf der neuen Version laufen zu lassen. Schlägt einer dieser Teile fehl spricht man von einem Gebrochenen Build oder sagt auch Das Build ist rot im Gegensatz zu Grünen Builds wenn alles funktioniert hat. Ein rotes Build wirkt wie ein Stoppschild. Es bedeutet es gibt aktuell keine funktionierende Software und im Prinzip darf niemand neuen Programmcode mehr freigeben, bis das Problem behoben ist und das Build wieder grün ist. Wie man genau mit gebrochenen Builds umgeht ist sicherlich von Team zu Team unterschiedlich, aber es ist Fakt, dass man keine kontinuierliche Integration anwendet, wenn man sich nicht um gebrochene Builds kümmert. Und wie kann der nächste Entwickler seine Änderungen Testen, wenn der offizielle Stand ohnehin nicht funktioniert?

Das folgende Diagramm gibt einen Überblick über ein einfaches – aber vollständiges – CI-Environment. Im Rahmen dieser Artikelserie soll diese Umgebung komplett aufgebaut werden. Doch dazu mehr weiter unten im Ausblick.

ContinuousIntegration_Basic

Mit ein wenig Erfahrung kann man durchaus ein potentielles Problem an obigem Setup erkennen. Es liegt eine Menge Verantwortung bei jedem einzelnen Entwickler sicherzustellen, dass der Build nicht gebrochen wird. D.h. idealerweise müssten Tests – auch Integration Tests – lokal bei jedem Entwickler ausführbar sein, damit diese vor einem Commit ausgeführt werden können. Dies ist jedoch für ein kleineres Team (5 – 8 Entwickler) durchaus ok.

Natürlich kann man ein CI-System beliebig weiter hoch skalieren, um damit Probleme im Build auch mit technischen Mitteln zu verhindern. Eine Möglichkeit ist ein hierarchisches System, bei dem die Entwickler nicht direkt ihren Code freigeben können, sondern dieser zunächst auf einem Pre-CI-System getestet wird. Nur Code der dort erfolgreich verifiziert wurde, wird für das finale CI-System freigegeben und dort erneut getestet.

ContinuousIntegration_Advanced

Mit einem solchen System – welches sich noch weiter hoch skalieren lässt – kann man effektiv verhindern, dass individuelle Fehler von Entwicklern sofort auf das Build durchschlagen. Allerdings ist auch offensichtlich, dass die Kosten für Hardware und Betreuung eines solchen Systems schnell anwachsen. Mit dem richtigen Mindset lassen sich nach meiner Meinung auch mit einem einfacheren System sehr gute Ergebnisse erzielen.

Ausblick

Damit es nicht nur bei der Theorie bleibt wird der Aufbau einer CI-Umgebung in den folgenden Artikeln näher beleuchtet. Die Artikel werden hier verlinkt sobald diese verfügbar sind (so ist zumindest der Plan :-)):

  • Reproduzierbare Builds mit Subversion, Maven und JUnit.
  • Builds automatisch ausführen und Artefakte deployen mit Hilfe eines Hudson CI-Servers.
  • Integration Tests einbinden auf Basis des Robot Frameworks.

Den ersten Schritt könnte man natürlich auch voraussetzen, aber ich denke es macht schon Sinn zunächst auf den Build-Prozess als solchen einzugehen. Danach können wir uns an die Automatisierung machen, d.h. am Ende von Schritt zwei steht bereits eine fertige und funktionierende CI-Umgebung. Diese wird dann im dritten Schritt noch einmal weiter aufgebohrt indem am Beispiel des Robot Frameworks gezeigt wird, wie sich auch Integration Tests einfach in das CI-Environment einbinden lassen.

Thomas Jaspers

Langjährige Erfahrung in agilen Softwareprojekten unter Einsatz von Java-Enterprise-Technologien. Schwerpunkt im Bereich der Testautomatisierung (Konzepte und Open-Source Werkzeuge).

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Michael Hüttermann

    Hello,
    interesting article, thanks. One question, what is the special with Hudson in that infrastructure? It looks like this setting can be rolled out with other CI products too. Could you detail that a bit more?

    Thanks.

    Best regards
    Michael

  • Thomas Jaspers

    9. November 2009 von Thomas Jaspers

    Hi Michael,

    first of all thanks for commenting, it is always nice to get some feedback on the blog.

    Coming to your question: Sure you could replace Hudson with any other CI-Tool in the diagram above, like Cruise Control or Bamboo. But as we have decided to use Hudson – and the question about Hudson really came up – I thought I do this on concrete examples. Same way you could replace Subversion by ClearCase or nowadays GIT 😉 and when it comes to Agile Testing Tools one could use FitNesse or Cucumber instead of Robot Framework as your Agile Testing Tool.

    But especially when it gets more concrete in the next parts of this series it makes of course sense to show tools that we use and that we know and so let’s start with some reasoning why we have been chosen Hudson as our CI-Tool:

    When it comes to „Cruise Control“ some collegues (including me) have been using it in some projects and it felt somehow bulky, thus we have been doing a „shootout“ between Hudson and Bamboo. The biggest advantage of Bamboo would have been the good integration with other Atlassian-Tools that we are using and better reporting functionality. On the other hand Hudson is really easy to setup and configure, it is offering multiple build steps and has very good support for Maven. Also accessing all the relevant files using the concept of the Hudson workspace was a „plus“. (I have to admit that I never looked at Bamboo again since then, so some features might have been added by now.)

    Luckily we have really excellent tools in this whole area of Testing and CI and as mentioned in the beginning it is for sure often a matter of taste and existing experience which tool is used in the end. Thus if you are planning to take a CI-Tool into use it would definitly make sense to have some short evaluation round (it’s fun) and if you are already using some tool and you are happy with it I would not change it … like we are happy with Hudson and are not changing ;-).

    Ok, long answer, hopefully also too some extend helpful :-).

    Best Regards
    – Thomas

  • Michael Hüttermann

    Hi Thomas,
    thanks for explaining .. absolutey right, there are many tools available in the area. Exactly that was the reason I was asking about your motivation to take Hudson. I was addressed by that question („why do they use Hudson?“) at the beginning, as you start your article mentioning and stressing out Hudson, but then I did not find anything about that. Now I got an idea about your reasons.

    Thank you!!

    Michael

  • Robin

    Hallo Zusammen,

    ich recherchiere gerade etwas über CI und CD. Egal wie viel Literatur ich lese oder wie sehr ich Google bemühe, ich finde keine klare Abgrenzung dazu wo CI aufhört und wo CD anfängt. Ich hätte gedacht, dass CI mit dem erfolgreichen Build (inkl. aller Tests die auf der CI Umgebung ausgeführt werden können und relativ schnell relativ viele Szenarien abdecken) abgeschlossen ist, also quasi mit der Ablage der Binaries an Ort X oder irgendeinem Repository.

    CD war ist für mich der Punkt ab dem ich für weitere Tests (um einen Softwarestand zu bekommen der jederzeit ausgeliefert werden kann) weitere Umgebungen (Test, Stage, Prod) provisionieren / nutzen muss.

    Nun irritiert mich bei der Grafik, die ja einen CI Prozess darstellen soll, etwas der Step des „Test Environments“. Wo / wie grenzt ihr zwischen CI / CD ab? Ich weiß der Artikel ist uralt. Würde mich trotzdem über eine Antwort freuen 🙂

    Viele Grüße

    Robin

  • Thomas Jaspers

    Hi Robin,

    der Artikel ist alt, aber die Themen sind noch aktuell :-). Ich versuche mal mein Verständnis zu erklären und dabei löst sich hoffentlich auch der Punkt mit den „Test Environments“.

    CI ist – genau wie Du sagst – das ständige Bauen der Software, so dass „deploy-bare“ Artefakte dabei erzeugt werden und dann auch der Test der Software. Dabei ist die erste Teststufe im allgemeinen Unit-Tests, die zur Compile-Zeit ausgeführt werden. Zu CI gehören aber auch Automatisierte Akzeptanztests, d.h. die Artefakte werden auf einer Testumgebung (Test Environment ;-)) automatisiert deployed und es werden automatisierte Tests, z.B. mittels Selenium für eine Webanwendung ausgeführt. Dieser Schritt ist relativ schwierig und aufwändig und wird daher in vielen Projekten ausgelassen, d.h. die Artefakte werden evtl. noch deployed und es laufen natürlich immer die Unit-Tests, aber da ist dann Schluss und es wird händisch weiter getestet.

    CD geht jetzt einen – großen – Schritt weiter, d.h. die automatisierten (Akzeptanz)-Tests sind so gut, dass die Software nachdem diese durchlaufen wurden wirklich released und auf Produktion ausgerollt werden kann. Dies erfolgt vollständig automatisiert und kann damit wirklich richtig oft passieren, ggf. mehrmals am Tag. Ohne diesen hohen Grad der Automatisierung – und mit entsprechend vielen manuellen Schritten trotz CI – finden produktive Installationen ja sonst nur alle paar Monate statt. Mit CD kann ich einen Bug fixen und quasi sofort bis nach Produktion ausrollen. Ich habe allerdings persönlich noch in keinem Projekt gearbeitet, wo wirklich dieser Grad an Automatisierung erreicht wurde ;-). Aber da kann man sich ja auch immer noch durchaus weitere Abstufungen vorstellen.

    Viele Kollegen von mir sind bei dem Thema aber deutlich mehr up-to-date und haben den CD-Prozess z.B. auf dieser Seite nochmal sehr umfangreich beschrieben:
    https://www.codecentric.de/leistungen/loesungen/bauen-sie-erfolgreiche-software/continuous-delivery/

    (Keine Sorge, Du musst da nix kaufen ;-).)

    Hoffe ich konnte Dir ein wenig helfen.

    Viele Grüße
    – Thomas

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.