Corsin Decurtins, CTO von Netcetera, präsentiert am Internet Briefing, wie Continuous Delivery dabei helfen kann, den Software-Delivery-Prozess zu optimieren, Deployments stressfreier zu machen und die Qualität zu verbessern.
Corsin Decurtins zum Thema «Software-Deployments»
Vortrag von Corsin Decurtins, CTO bei Netcetera am Internet Briefing von Reto Hartinger.
Deployments von grossen Server-Applikationen sind oft risikoreich und kosten Entwicklungsteams und System-Administratoren viele Nerven und graue Haare. Der Weg von der Entwicklungsumgebung in die Produktion ist oft viel steiniger als gedacht.
Continuous Delivery propagiert zur Lösung dieses Problems Deployments sehr viel häufiger zu machen. Wie kann Continuous Delivery dabei helfen, den Software-Delivery-Prozess zu optimieren, Deployments stressfreier zu machen und die Qualität zu verbessern?
In Grossfirmen werden ca. 4 Deployments pro Jahr aufgeschaltet. In Web 2.0 Firmen sind eher 15 Deployments pro Jahr üblich. Bei beiden sind business-kritische Anwendungen mit Cashflows involviert. Deployments bergen also ein entsprechendes Risiko, dass Kunden nicht mehr online buchen können und damit Umsatzausfälle entstehen.
Ein Deployment ist die Installation von neuer Software (Release) in einer Zielumgebung. Dabei werden meist eine bestehende Version ersetzt, Daten migriert und Systeme umkonfiguriert.
Die Komplexität kommt aus der Datenmigration, mehreren Komponenten, Abhängigkeiten, etc. Das bedeutet verschiedene Risiken und entsprechende Kosten für Spezialisten, die an Randzeiten zur Verfügung stehen müssen.
Automatisierte Software-Delivery-Pipeline
In einem professionellen Setup wandert eine neue Version der Software über verschiedene Testsysteme und Qualitätssicherungsmassnahmen aus der Entwicklung (dev) in die Produktion (prod).
If it hurts, do it often: Wenn Deployments umständlich sind, sollte man sie häufiger durchführen, um die Prozesse zu optimieren.
Automatisierte Integrationstests mit Jenkins, Hudson, Maven, Puppet oder ähnlichen Tools in der Entwicklungsumgebung sind weit verbreitet. Oft werden diese automatisierten Abläufe inklusive Testing aber nicht bis in die Produktion eingesetzt.
Automatisierte Deployments
Optimal ist ein automatisiertes Deployment, das die Software automatisch bis in die Produktion aufschaltet.
Ein Deployment könnte folgende Struktur haben:
- Bestehende Applikation über den neuen Release informieren
- Eine Maintenance-Seite aufschalten
- Die laufende Applikation stoppen
- Die neue Software-Version installieren
- Die Datenbankmigration starten
- Die neue Software-Version starten
- Tests durchlaufen
- Entry Server umkonfigurieren
- Maintenance Seite ausschalten
Dabei ist wichtig, dass man die Pre-Conditions prüft, bevor man einen Schritt ausführt: Ist tatsächlich die zu ersetzende Version im Einsatz? Auch Post-Conditions sind zu prüfen: Ist das eingetreten, was man erwartet hat?
Auch automatische oder manuelle Rollbacks sollten vorgesehen werden: Wurden die nötigen Backups gezogen/Snapshots erstellt? In diesem Zusammenhang müssen Fehler überhaupt erst erkannt werden können.
Die vollständige Automatisierung ist aufwändig umzusetzen. Es empfiehlt sich, die eingesetzten Prozesse über kleinere Scripts und manuelle Eingriffe langsam in Richtung Automatisierung weiterzuentwickeln. Auch kann bei kleineren Deployments weniger schief gehen.
Um Datenmigrationen weniger kritisch zu gestalten, kann man folgende Patterns beachten:
- on-the-fly Migration mit verschiedenen Datensätzen (kompliziert)
- read-only Availability, zwischenzeitliche Nutzereingaben werden in Queue zwischengespeichert
- Storage Layer Abstraction
- NoSQL Storage Layer
Automatisierte Abnahme-Tests
Nicht nur die Software, sondern auch der Prozess, wie man Software in die Produktion aufschaltet, sollte getestet werden. In einer Pre-Production Umgebung sollten alle Funktionen mit den finalen Daten getestet werden. Dies ist natürlich ein potentieller Kostentreiber, oft wird deshalb eine etwas schwächere Testumgebung aufgestellt.
Deployments sind nicht die Lieblingsbeschäftigung der meisten Entwickler. Es kann helfen, wenn man ihnen gute Integrations-Tools zur Verfügung stellt, die ihnen das Problem löst. Dann werden die meisten Entwickler bereitwillig in Richtung Automatisierung mitwirken.
Continuous Inspection zur Qualitätssteigerung
Per «Canary-Deployments» kann man neue Features nur einer Teilgruppe der User zur Verfügung stellen und so die Akzeptanz testen. Sind die Funktionen okay, rollt man die Funktionen auf alle User aus. Facebook und Google stellen ihre neuen Funktionen meist zuerst nur einer Testgruppe zur Verfügung.
Sind Test- und Produktivumgebung nicht identisch, so müssen die Automatisierungs-Skripts so abstrahiert werden, dass das Deployment nicht scheitert, weil man einmal in die Cloud und einmal in die effektive Produktion deployed.
Auch im Umfeld von Deployments kann man Key Metriken identifizieren und dann Deployments entsprechend monitoren. In einem EIS (Enterprise Information System) können auch SLA-Informationen hinterlegt werden: Ist an einem bestimmten Tag überhaupt ein Wartungsfenster erlaubt?
Time-To-Production
Durch die häufigeren Deployments kann man neue Features auch schneller an den Markt bringen. Besonders im Umfeld der agilen Software-Entwicklung sind häufige und deshalb automatisierte Deployments gefragt.
https://twitter.com/#!/WalterSchaerer/status/187146750925094913
