Kategorien
Continuous Integration: Ein Erfahrungsbericht
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.
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
Sehr guter Einstiegsartikel, der Appetit auf mehr (Details) macht.
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?
@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/
@Christian Danke klingt vielversprechend 🙂
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?
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
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.
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
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?
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.
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 🙂
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!