Kategorien
Continuous Integration
Wer hat ihn nicht mitbekommen, den Streit um Hudson und die Entstehung von Jenkins. Continuous Integration Server waren eine Zeit lang in aller Munde. Auf PHP-Konferenzen gab immer wieder Vorträge über die Server. Und das auch alles zu Recht. Ich liebe unseren Bamboo!
Aber für all diejenigen, für die Continuous Integration noch ein Buch mit sieben Siegeln ist, hier noch mal die Schnelleinführung von dem, was die meisten glauben. was CI ist. Im nächsten Artikel schreibe ich dann, warum das nicht ganz richtig ist.
Wenn man einen CI-Server einsetzt, dann übernimmt der hauptsächlich eine Aufgabe. Er testet die Applikation. Grob zusammengefasst prüft er in wiederkehrenden Intervallen ein Source-Code-Repository (z.B. SVN), ob Änderungen am Code vorgenommen wurden. Falls es Änderungen gab, so wirft er die vorher definierte Test-Suite an und gibt einem das Ergebnis aus. Je nach Konfiguration bekommen die Teammitglieder dann eine Mail. falls etwas kaputt ist. In den meisten Fällen handelt es sich bei der Test-Suite um Unit Tests. Es ist aber auch problemlos möglich Tools wie Selenium, Code-Sniffer, PHPMD oder ähnliches einzuhängen. Alles was über die Kommandozeile funktioniert, funktioniert auch im CI-Server.
Vorteil von einem solchen Server ist somit, dass kaputter Code nicht lange unentdeckt bleibt, da es jemanden gibt, der sicher nicht vergisst die Tests auszuführen, so wie es einem Entwickler vielleicht passieren könnte. Schön ist es auch, dass es keine Zeit frisst. Niemand sitzt vorm Rechner und lässt die Tests laufen, das macht alles der dumme und günstige Server im Hintergrund.
Das war jetzt also die Quick-and-dirty-Version von dem, was die meisten Leute unter Continuous Intergration verstehen, dem Einsatz eines Continuous Integration Servers. Wie gesagt, im nächsten Artikel ergänzen wir das.
Noch dümmer und billiger geht übrigens auch mit Travis CI vorausgesetzt man nutzt GitHub.
http://www.testically.org/2011/11/16/travis-ci-continuous-integration-to-go/
Had some trouble translating your post, but I managed it. 🙂 You should get to know Cintient, a new open-source and PHP-based CI server. Its premise is to bring CI practices to smaller-to-medium web projects that don’t justify the hassle of setting up a complex CI rig like Jenkins. Cintient is very clean, offers a lot of metrics to analyze your projects and is really dead simple to setup. It’s up on GitHub: https://github.com/matamouros/cintient
Thanks.
Pedro.
Hm, AFAIK sind doch Unit Tests für das gesamte Projekt immer vorbereitet. Warum sollte mal jemand vergessen, diesen auszuführen? Zur Not sagt man sich: Immer nach der Mittagspause wird dieser ausgeführt. Für mich ist das eher der Versuch, Projektqualität zu automatisieren, ohne dabei zu beachten, dass jede Abweichung von einem erfolgreichen Unit Test individuell ist und evntl. sogar seine Gründe hat.
@Daniel S:
Stimmt bedingt. Sobald man in Teams an den Sourcen arbeitet, wird das manuelle Testen aber sehr unübersichtlich.
Zwingend notwending ist zum Beispiel eine Umgebung welche immer gleich bleibt. (PhpVersion, MySql, Sonstwas)
Das erfüllt zB TravisCi wie Christian schon schrieb. Man muss also nicht zwingend Java-SDK-Jenkins-Tomcat-Schiessmichot installieren um in den Genuss von CI zu kommen.
Unabhänging davon kannst dem CI-Server ja die Uhrzeit eurer Mittagspause beibringen. Dann rennt der halt nur einmal am Tag, anstatt bei jedem Commit.
Ich hoffe, dass Michael auch im nächsten Artikel auf Staged Deployment bzw. Continuous Deployment eingehen wird. Das hier war ja nur der „verkürzte Abriss“.
Besten Gruß
Malte
Gerade in größeren Teams sind automatische Tests meines Erachtens unabdingbar und dafür braucht es den CI-Server.
Wir haben für die Entwicklung des papaya CMS und unserer Kundenprojekte einen Statusmonitor im Flur neben der Küche hängen, sodass immer für jeden der Status erkennbar ist: Alles grün? Alles gut! Etwas orange oder rot? Handlungsbedarf!
Und „Abweichungen von einem erfolgreichen Unit Tests“ die „ihre Gründe haben“ sollte es IMHO nicht geben: Was im Trunk landet, hat einen funktionierenden Test zu haben – schließlich wurde der Testcode doch bitte vor dem Programmcode geschrieben, oder? 😉
Gruss aus Köln,
André
@Malte
Java-SDK-Jenkins-Tomcat-Schiessmichot?
Wem sein besserer Code und die damit einhergehende Steigerung der Qualität das nicht Wert ist: Schade
Im Endeffekt: VBox installieren => Jenkins per APT installieren => Template und PPW von Sebastian Bergmann per Git klonen => paar PEAR extension => fertig los!
Der nutzen liegt dabei deutlich über der benötigten Zeit zum einrichten einer umgebung. Und wenn man sich mit der Materie mal auseinandergesetzt hat, auch bezügl Ant/Maven etc., dem fallen bald weitere nützliche Aufgaben ein welche er vom CI Server erledigen lassen kann.