Unsere Software dirigiert den Weg aller Pakete zu ihren Empfängern. In den Paketzentren der Schweizerischen Post liefern unsere Services für jedes Paket die nächste durchzuführende Aktion. Wenn diese Dienste nicht laufen, entstehen enorme Kosten. Trotzdem rollen wir unsere geschäftskritischen Software-Services mehrmals täglich aus und jeder Commit in den Master Branch geht direkt auf die Produktionsumgebung. Magie? Nicht ganz.
Continuous Integration / Delivery / Deployment
Continuous Integration bezieht sich auf das Integrieren, Builden und Testen von Code in der Development-Umgebung, worauf das Continuous Delivery aufbaut.
Beim Continuous Delivery kann eine Software zu jeder Zeit auf die Produktionsumgebung ausgerollt werden. Dazu wird eine Deployment-Pipeline verwendet, durch welche neue Features kontinuierlich in die Software integriert werden, automatische Tests ausgeführt werden und die Software auf Produktions-ähnliche Umgebungen ausgerollt wird.
Das Continuous Deployment ist eine Form des Continuous Delivery, welche voll automatisiert ist und jede Software-Version sofort auf die Produktionsumgebung ausgerollt wird.
Unsere Qualitäts-Kultur-Prinzipien
Damit Continuous Deployment in einem geschäftskritischen Umfeld funktioniert, braucht es viel Disziplin, Herzblut und insbesondere ein Team mit den entsprechenden Werten. Folgende Rahmenbedingungen helfen uns dabei:
- Trunk Based Development
- 24/7 Pikett durch Entwickler
- Strenge Code Reviews durch PRs und entsprechende Gates in den Repo-Einstellungen
- Null-Toleranz für Roslyn und Sonar Issues
- Errors & Warnings in den Logs werden sofort analysiert
- Keine End-2-End-Tests (d.h. es werden nur die Applikation selbst und die Contracts getestet)
- Stetige Überprüfung der Quality Gates und Anpassungen bei Bedarf
- Automation, Automation, Automation, …
Dazu kommt eine ausgiebige Test-Strategie, wobei auf Level Unit Test und Component Integration Test eine 100%-Abdeckung angestrebt wird:
- Unit Tests: Jede Klasse wird in Isolation getestet.
- Component Integration Tests: Startet eine Instanz der Applikation In-Memory und mockt externe Systeme In-Memory.
- User Story Tests: Testet einen kompletten Flow, spezifiziert von Business Analysten.
- System Integration Tests: Integration mit dem echten System, implementiert als gewöhnlicher Unit Test, läuft auf Kubernetes in einem temporären Namespace.
Deployment Tools
Ohne das richtige Werkzeug geht nichts. Eines der wohl wichtigsten Tools ist Jenkins, mit welchem die voll automatisierte Pipeline aufgesetzt ist und Quality Gates beinhaltet. Es ist unabdingbar, die Tools mit all ihren Stärken und Schwächen sehr gut zu kennen.
Monitoring, Alerts und Quality Reports
Dank Tools wie Splunk und Grafana können wir unsere Applikationen stets überwachen und werden bei Auffälligkeiten sofort benachrichtigt (während der Arbeitszeit via Microsoft Teams und während dem Pikett via OpsGenie).
Ein eigens entwickeltes Tool erstellt in unserem Confluence Space wöchentlich automatisch einen Quality Report unserer Applikationen. Dieser enthält Statistiken und Trends von diversen konfigurierbaren Metriken. Wir besprechen den Report innerhalb des Teams einmal wöchentlich in einem eigens dafür vorgesehenen Meeting und definieren bei Bedarf zugehörige Action Points als Jira Issues.
Facts & Figures
- 15 Developer, 4 Business Analysts, 3 Solution Architects, 1 Scrum Master, 1 Product Owner
- End-2-End Responsibility & 24/7 Pikett
- 99.8% Unit Test Coverage
- ~200k Lines of Code (C#)
- ~9 Deploys pro Tag
Fazit
Ein richtig umgesetztes Continuous Deployment ermöglicht das Liefern von stabilen Softwareprodukten – selbst in einem geschäftskritischen Umfeld – aus mehreren Gründen:
- Dank eingebauten Quality Gates wird ein automatisches Ausrollen einer instabilen Software verhindert.
- Vollständig automatisierte Tests entdecken Fehler vor dem Rollout.
- Keine Downtime und keine Wartungsfenster.
- Durch aktives Monitoring können potenzielle Bugs noch vor dem Auftreten effizient behoben werden.
- Die Entwickler können sich auf ein stabiles Toolset und eine solide Pipeline verlassen und dank der ausserordentlichen Testabdeckung neue Features entwickeln, ohne den gesamten Applikations-Kontext kennen zu müssen – das Vertrauen in den Code und die eigene Arbeit wird dadurch massiv gestärkt.
Mehr erfahren
- Die Beitrag-Reihe zum Thema Continuous Delivery in Martin Flowler’s Blog ist sehr empfehlenswert.
- Das Buch Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation von Jez Humble und Dave Farley ist eine der besten Lektüren, um sich in dieses Thema zu vertiefen.
