Mon May 08 17:18:04 +0200 2006 , Updated at
Continuous Integration
Continuous Integration soll bei wachsenden und zunehmend komplexer werdenden Software Projekten das Entwickler Team unterstützen. Das Problem ist, daÃ? durch das ständige Zusammenspiel mehrerer Entwickler, sich früher oder später sogenannte Integrationsfehler einschleichen können: Beim Zusammenführen von einander unabhängig entwickeltem Code entstehende Inkompatibilitäten. “Aber es funktioniert auf meiner Maschine” ist in solch einem Falle eine oft gehörte Aussage und zeigt auf, dass es selten zwei identisch konfigurierte Entwicklermaschinen gibt. Je früher man solchen Integrationsfehlern begegnet, desto schneller und einfacher können sie behoben werden.
Das folgende hier beschriebene Scenario geht von einer Traumkonstellation mit Ruby on Rails & Subversion & und dem Continuous Builder Rails Plugin aus. Desweiteren kommen darin mehrere agile Paradigmen vor: integrate early, integrate often & automate deployment & testing.
Wie kann so etwas aus Entwicklersicht aussehen:
Unser Star Coder Rob MacCool hat nach 3 Stunden intensivem coden das Mini Feature XYZ sammt Tests fertig. Jetzt updated er nochmals seine lokale Working Copy um vor dem Commit noch ein letztes mal alle Tests durchlaufen zu lassen. Liefen die Tests erfolgreich durch, kommt der ganze Bollen ins Repositority. Nach ein paar Minuten schaut er in die CI Mailingliste und erfährt dort ob alle Tests glatt durchgelaufen sind. So kann er sich jetzt relaxt seiner nächsten Tätigkeit zuwenden. Er kann sicher sein, dass sein neuer Code keine Integrationsfehler hervorgerufen hat.
Wirklich wichtig ist, dass neu erstellter Code regelmäÃ?ig, am besten mehrmals täglich commited wird. Je länger Code zurückgehalten wird, desto eher wird er Probleme verursachen. Am besten Commits in kleinen logischen Einheiten zusammen fassen und das Ganze mit sinnvollen Commit Messages kommentieren. Zudem basiert Continuous Integration komplett darauf, dass es zu jedem Stückchen Code auch Tests gibt. Denn diese Tests liefern dann das Feedback ob neu eingecheckter Code Probleme verursacht oder nicht. Ausserdem muÃ? alles was zum Projekt gehört auch in der Versionskontrolle stecken. Ein oft zitierter Spruch hierzu ist: “Code welcher nicht im SCM steckt, existiert nicht!”.
Ein Rechner mu� zum Integrations Server gekürt werden. Gut ist, wenn die einzelnen Hardware- und Software Komponenten zu denen des Produktionsservers so identisch wie möglich sind. Dies ist aber leider nur selten komplett machbar. Dieser Server leistet dann mehrere Dienste. Zum einen verwaltet er das Subversion Repositority. Zum anderen überwacht das Continuous Builder Plugin die SVN Commits und führt die Tests aus. Feedback über den Verlauf der Tests werden per eMail an die Entwickler oder auch an eine Mailingliste, über RSS oder an einen IRC Channel gesendet. Dieser Server kann auch als Preview Server dienen, indem das CI Plugin nach erfolgreichen Ablauf der Tests den Code exportiert und somit den aktuellen Stand des Projekts an einer Preview URL zu Verfügung stellt. Dieser Server könnte auch Trac hosten: Ein Webbasiertes Project Managment Utility mit Wiki und Issue Tracking System. Und ja nicht das Backup vergessen! Eine sich auch bewährte Sache ist es den Deployment Vorgang zu scripten und diesen an Subversions Commit Hook zu koppeln. Das Deployment also durch taggen oder branchen ausführen.
Diese Infrastruktur sollte man schon vor dem eigentlichem Projektbeginn aufsetzten und zur Verfügung haben. Continuous Integration sollte sich möglichst einfach und reibungslos in die tägliche Arbeit einführen lassen.
