Wer hat Angst vor kontinuierlichen Deployments?

Hartmut Schlosser

Arten Ihre Deployments auch immer in Stress aus, wenn Sie sie alle zwei bis drei Wochen einmal anstoßen? Dann sollten Sie mal überlegen, ob Ihre Deployment-Infrastruktur wirklich das Gelbe vom Ei ist.
Wieviel manuelle Arbeit müssen Sie noch reinstecken? Wieviele Tests werden während des Deployments noch nicht-automatisiert eingeflochten?

Vielleicht sollten Sie sich überlegen, ob Sie nicht den Weg hin zu einem Continuous Deployment einschlagen können.

Was Continuous Deployment bedeutet?

Jede Commit-Aktion im verwendeten Versionskontrollsystem startet automatisierte Unit-Tests und löst ein Deployment aus, das sofort das produktive System betrifft. Das Risiko: Wird ein Bug von den Tests nicht erkannt, geht dieser live und wird sofort für den Kunden im Live-System sichtbar.

Dieses Risikos war sich Famigo CTO Cody Powell durchaus bewusst, als er sich entschied, das Android- und iOS-Familienprojekt auf Continuous Deployment umzustellen. Die Vorteile, die Continuous Deployment mit sich brachten, diskutiert Powell in seinem lesenswerten Erfahrungsbericht „Who’s Afraid of Continuous Deployment?„:

  1. Continuous Deployment macht das Deployment zur Sebstverständlichkeit

    Soll Continuous Deployment überhaupt funktionieren, dann müssen die manuellen Eingriffe vor und während eines Deployments von vorneherein auf ein absolutes Minimum reduziert werden. Man wird quasi zu seinem Glück, der Automatisierung, gezwungen. Und wenn ein Deployment scheitert, dann scheitert es schnell und frühzeitig.

  2. Fokus auf den Testprozess

    Allzu häufig fällt das gründliche Schreiben von Tests dem geschäftigen Entwickler-Alltag zum Opfer. Hand auf´s Herz, wer hat schon einmal den Satz gehört – oder gar selbst ausgesprochen: „Den Test dafür schreib´ ich später“? Für Continuous Deployment sind wiederholbare Tests eine notwendige Voraussetzung. Und was, wenn die Testabdeckung für das existierende Projekt lausig ist? Powell rät: Fang an, Tests zu schreiben! Der anfängliche Stress zahlt sich später in jedem Fall aus!

  3. Gute Source-Control-Praktiken

    Continuous Deployment wird unmöglich, wenn 50 Entwickler jederzeit Quellcode in den Trunk einchecken. Quellcode-Systeme verfügen nicht umsonst über Branches. Größere Features und Refactorings sollten in eigenen Branches soweit getrieben werden, dass sie stabil laufen und dann in den Hauptzweig eingepflegt werden können.

  4. Und am wichtigsten: Continuous Deployment macht Spaß

    Es befriedigt die innere Entwickler-Seele doch ungemein, wenn man in der Lage ist, komplexe Probleme auf relativ einfache Art und Weise zu lösen. Und als Nebeneffekt: Wenn ich in der Lage bin, wichtige Features in Minutenschnelle in ein Live-System zu integrieren, dann steigt mein Wert als Mitarbeiter ungemein.

Und wie setze ich nun ein Continuous Deployment System auf? Powell empfiehlt zunächst, einen CI-Server wie Hudson zu installieren. Ein Hudson-Job scannt dann das Quellcode-Repository und startet bei Veränderungen die Unit-Tests und den Build-Vorgang. Darüberhinaus wird ein Shell-Skript angestoßen, das den alten Produktionscode archiviert und die aktuellen Dateien aus dem Continuous-Integration-System in die Produktiv-Umgebung kopiert. Bei Famigo ist man laut Cody Powell so in der Lage, Deployment-Projekte in wenigen Sekunden abzuarbeiten.

Continuous deployment is an ideal solution in any environment where you must me able to iterate very quickly. At our startup, that is a must. If you give it a shot with one of your simpler projects, I think you’ll soon be won over, just as I’ve been.

Wie kontinuierlich läuft der Deployment-Prozess bei Ihnen ab?

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.