Kategorien
Continuous Integration – Teil 2
Vor ein paar Tagen habe ich ja angefangen ein wenig über Continuous Integration zu reden und war dabei stehen geblieben, bei dem, was ich glaube, die meisten unter CI verstehen: dem Einsatz eines CI-Servers. Jetzt hab ich gleich mal Anschiss von Tobi S. bekommen, dass man nicht das Falsche vor dem Richtigen erklärt. War mir aber egal, der Artikel war ja eh schon draußen. Ich bin halt ein Rebell und mich hält nichts auf.
Falsch ist das ja alles nicht, was ich erklärt habe, es ist ein wichtiger Bestandteil des Konzepts, dass man nach jedem Commit, also möglichst oft und automatisch durchtestet und sein System baut. Wichtig dabei st aber auch, dass man möglichst oft comittet. In den meisten Fällen ist es ja so, dass man erst seine Änderungen in den Trunk eincheckt, wenn das Feature fertig ist und vollständig implementiert ist. CI geht da einen anderen Weg, nicht wenn das vollständige Feature fertig ist, sondern wenn etwas funktionsfähig fertig ist, wird comittet.
Die Idee dahinter ist, dass man viel einfacher kleine Inkremente in das Gesamtsystem mergen kann, als das große Ganze am Ende. Konflikte mit anderen Änderungen (von den lieben Kollegen) findet man so zeitnah und kann auch von dem Code, den die anderen produzieren profitieren. Ob das System in der Art für einen funktioniert, hängt auch immer davon ab, wie sehr man bereit ist Testabdeckung für seinen Code und seine Funktionalitäten hochzuschrauben. Denn wenn die Abdeckung hoch ist, so weiß man jeder Zeit, ob der Code, den man gerade produziert hat etwas am bereits bestehenden System ändert. Wenn nicht, kann es auch nicht schaden, den Code mit in die Versionskontrolle zu packen.
Continuous Integration ist ein sehr großes Thema, auch wenn es eigentlich nur auf zwei Grundsätzen beruht. Ich werde versuchen in der nächsten Zeit noch mal etwas über einzelne Implementationen zu schreiben, dann will ich auf Feature-Toggles eingehen und etwas für Continuous Deployment verfassen. Wenn euch etwas fehlt, dann schreibt es in den Kommentaren. Ich kümmere mich dann darum.
Ich hoffe nur, dass du nicht auch (wie alle anderen Artikel bisher) nur herusstelllst, wie toll doch Continuous Deplayment ist, sondern auch mal ein funktionierendes Beispiel dazu packst 🙂 Denn konkrete Beispiele zum ausprobieren findet man nicht.
@Dennis: Sag mal was du genau hören willst, dann schreib ich drüber. Im Prinzip ist es ja nur Ant-File erstellen (http://www.phphatesme.com/blog/tools/ant-build-skripte/) und laufen lassen. Aber würde gerne ausführlicher werden, wenn es da Wünsche gibt.
CI ist nicht nur sinnvoll um ein Projekt regelmäßig zu deployen und die Tests durchlaufen zu lassen, sondern auch um einen Überblick über die Veränderung der Softwäre-Qualität im Auge zu behalten durch entsprechende Tools für Metriken: http://qualityassuranceinphpprojects.com/pages/tools.html. Wollt ich nur mal erwähnt haben, aber auch dazu gab es von Nils schon Beiträge, kann ich mich dunkel erinnern.
Mich persönlich würden noch Alternativen zu Hudson/Jenkins interessieren, wie zum Beispiel arbittracker: http://www.arbittracker.org/arbit.html, weil es direkt aus dem PHP-Bereich kommt. Aber leider scheint dort schon länger nichts mehr passiert zu sein.
@Dennis einen schönen Einstieg (für Jenkins) findest Du u.a. auch hier http://jenkins-php.org/
Gestern hatte ich noch ein schönes ant build file für ein php-Projekt auf github gesehen, aber irgendwie finde ich es jetzt nicht mehr 🙁