Facebook
Twitter
Google+
Kommentare
7
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

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.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

7 Comments

  1. 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.

    Reply
  2. 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.

    Reply
  3. @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

    Reply
  4. 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é

    Reply
  5. @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.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen