Zuverlässige Software-Releases durch Build-, Test- und Deployment-Automatisierung
Obwohl ich viel lese, ist dies meine erste Buchrezension für meinen Blog. Ich musste in der Schule viele Rezensionen schreiben, aber die zähle ich nicht, da ich wenig Interesse an diesen Büchern hatte. Diese Rezension ist anders - ich war wirklich an dem Buch interessiert, das ich gelesen habe.
Warum habe ich dieses Buch gekauft?
Ich arbeitete bei einem Softwareunternehmen mit einem manuellen Auslieferungsprozess. Ich war dafür verantwortlich, Produktupdates an Kunden und unser Support-Team zu liefern, wann immer es einen Hotfix oder eine andere Softwareänderung gab. Updates erfolgten häufig, mindestens alle zwei Wochen.
Nachdem die Build-Agenten die Assemblies an einem bestimmten Ort abgelegt hatten, war es meine Aufgabe, die Testsysteme zu aktualisieren, zu testen und alles zu verpacken, um es an den Kunden zu versenden. Ich wurde für zwei Rollen eingestellt: Release Engineer (um Updates pünktlich zu versenden) und Tester. Leider hielt mich das Versenden all dieser Updates extrem beschäftigt, und es blieb wenig Zeit zum Testen - dank des insgesamt manuellen Prozesses.
Ich wollte eine Lösung, um Zeit freizumachen und die Auslieferungsqualität zu verbessern. Ich schaute mir viele Bücher an: einige über Application Lifecycle Management, andere über Prozesse. Keines verband alles auf eine praxisnahe Weise. Bis…
Das Buch Continuous Delivery von Jez Humble und David Farley tat genau das. Es erklärte das große Ganze und ging genug ins Detail, um eine klare, prägnante Sicht auf das Thema zu geben.
Worum geht es?
In einem früheren Entwurf dieses Beitrags fasste ich den Inhalt in mehreren Absätzen zusammen; ich habe diese Zusammenfassung entfernt. Viele Quellen erklären den Inhalt des Buches bereits im Detail. Mein Fokus liegt hier darauf, meine persönliche Erfahrung zu teilen, anstatt diese Zusammenfassungen zu wiederholen.
Schau dir diese Seiten für ein vollständiges Inhaltsverzeichnis und weitere Informationen an, aber vergiss nicht, hierher zurückzukommen.
- Die offizielle Seite des Buches
- Die Verlagsseite des Buches
- Inhaltsverzeichnis bei Safari Books
- Das Buch auf Amazon
Was waren meine wichtigsten Erkenntnisse?
Wenn ich drei Highlights aus dem Buch auswählen müsste, wären es diese - und ich werde erklären, warum. Danke an den Verlag, dass ich diese Illustrationen verwenden darf.
(Übrigens hat der Verlag derzeit eine Aktion für viele ihrer meistverkauften Agile-Bücher - schau es dir an.)
Die erste Illustration zeigt eine Deployment-Pipeline aus Prozessperspektive. Sie visualisiert, wo sich Softwareänderungen zu einem bestimmten Zeitpunkt befinden und deren Zustand. Durch das Betrachten dieses Diagramms kann ein Release-Manager sofort den potenziellen Umfang und die Qualität der bevorstehenden Auslieferungen einschätzen.
Der Begriff “Deployment-Pipeline” wirft Fragen auf: Wie sieht sie aus? Wie funktioniert sie? Was brauche ich, um eine zu bauen? Das Bild unten beantwortet mehrere dieser Fragen - Bilder sagen oft mehr als Worte.
Du kannst das gesamte Kapitel 5, “Anatomy of the Deployment Pipeline”, sogar kostenlos lesen. Cool!
“Woher kommst du, wo bist du jetzt und wohin gehst du” könnte ein Titel für die Tabelle unten sein. Sie half mir, meine aktuelle Situation zu verstehen und worauf ich mich konzentrieren sollte.
| Praxis | Build-Management und Continuous Integration | Umgebungen und Deployment | Release-Management und Compliance | Testing | Datenmanagement | Konfigurationsmanagement |
|---|---|---|---|---|---|---|
| Level 3 - Optimierend: Fokus auf Prozessverbesserung | Teams treffen sich regelmäßig, um Integrationsprobleme zu besprechen und sie mit Automatisierung, schnellerem Feedback und besserer Sichtbarkeit zu lösen. | Alle Umgebungen werden effektiv verwaltet. Bereitstellung vollständig automatisiert. Virtualisierung wird verwendet, wenn anwendbar. | Operations- und Delivery-Teams arbeiten regelmäßig zusammen, um Risiken zu managen und die Zykluszeit zu reduzieren. | Produktions-Rollbacks selten. Fehler werden sofort gefunden und behoben. | Release-zu-Release-Feedback-Loop für Datenbankperformance und Deployment-Prozess. | Regelmäßige Validierung, dass die CM-Policy effektive Zusammenarbeit, schnelle Entwicklung und nachvollziehbare Änderungsmanagement-Prozesse unterstützt. |
| Level 2 - Quantitativ verwaltet: Prozess wird gemessen und kontrolliert | Build-Metriken werden gesammelt, sichtbar gemacht und es wird danach gehandelt. Builds werden nicht kaputt gelassen. | Orchestrierte Deployments werden verwaltet. Release- und Rollback-Prozesse getestet. | Umgebungs- und Anwendungszustand werden überwacht und proaktiv verwaltet. Zykluszeit wird überwacht. | Qualitätsmetriken und Trends werden verfolgt. Nicht-funktionale Anforderungen definiert und gemessen. | Datenbank-Upgrades und -Rollbacks werden bei jedem Deployment getestet. Datenbankperformance wird überwacht und optimiert. | Entwickler checken mindestens einmal täglich in die Hauptlinie ein. Branching wird nur für Releases verwendet. |
| Level 1 - Konsistent: Automatisierte Prozesse werden über den gesamten Anwendungslebenszyklus angewendet | Automatisierter Build- und Testzyklus bei jeder Änderung. Abhängigkeiten werden verwaltet. Wiederverwendung von Skripten und Tools. | Vollständig automatisierter, Self-Service, Push-Button-Prozess für Software-Deployment. Gleicher Prozess für jede Umgebung. | Änderungs- und Genehmigungsprozesse definiert und durchgesetzt. Regulatorische und Compliance-Bedingungen erfüllt. | Automatisierte Unit- und Akzeptanztests, letztere mit Testern geschrieben. Testing ist Teil des Entwicklungsprozesses. | Datenbankänderungen werden automatisch als Teil des Deployment-Prozesses durchgeführt. | Bibliotheken und Abhängigkeiten werden verwaltet. Versionskontrollnutzungsrichtlinien durch Änderungsmanagement-Prozess bestimmt. |
| Level 0 - Wiederholbar: Prozess dokumentiert und teilweise automatisiert | Regelmäßiger automatisierter Build und Testing. Jeder Build kann aus der Quellcodeverwaltung mit automatisierten Prozessen neu erstellt werden. | Automatisiertes Deployment in einige Umgebungen. Erstellung neuer Umgebungen ist günstig. Alle Konfiguration externalisiert/versioniert. | Schmerzhafte und seltene, aber zuverlässige Releases. Begrenzte Nachvollziehbarkeit von Anforderungen zu Release. | Automatisierte Tests werden als Teil der Story-Entwicklung geschrieben. | Datenbankänderungen mit automatisierten Skripten, versioniert mit der Anwendung. | Versionskontrolle wird für alles verwendet, was zur Neuerstellung der Software benötigt wird: Quellcode, Konfiguration, Build- und Deploy-Skripte, Datenmigrationen. |
| Level -1 - Regressiv: Prozesse nicht wiederholbar, schlecht kontrolliert und reaktiv | Manuelle Prozesse für Software-Building. Keine Verwaltung von Artefakten und Reports. | Manueller Prozess für Software-Deployment. Umgebungsspezifische Binaries. Umgebungen manuell bereitgestellt. | Seltene und unzuverlässige Releases. | Manuelles Testen nach der Entwicklung. | Datenmigration nicht versioniert und manuell durchgeführt. | Versionskontrolle entweder nicht verwendet, oder Check-ins erfolgen selten. |
Als Randnotiz habe ich auch ein hilfreiches Gist gefunden, das dich in die richtige Richtung weist.
Fazit
Dieses Buch erweiterte meine Perspektive als Software-Ingenieur: die Arbeit endet nicht beim Check-in. Software ist vielleicht nie wirklich fertig, aber der wichtigste Moment ist, wenn der Kunde mit einem Lächeln unterschreibt.
Als Release Engineer zeigte mir das Buch, wie man Prozesse effizient hält und Risiken von Anfang an reduziert. Manuelle Schritte führen in jeder Phase Risiken ein. Ich möchte meine Kreativität und Energie nutzen, um einzigartige Probleme zu lösen und großartige Software zu liefern - nicht für repetitive manuelle Arbeit.
Alles in allem war dies das nützlichste Buch, das ich in letzter Zeit gelesen habe. Danke an die Autoren, dass sie es geschrieben haben, und für den Einfluss, den es auf mein Berufsleben und meine Perspektive hatte.
Fertig für heute!