Lyndsay Prewer über die Erfolgsfaktoren für Continuous Delivery

Zum Erfolg mit Continuous Delivery – die Geschichte zweier Teams

Lyndsay Prewer

(c) Shutterstock / Screeny

Continuous Delivery gilt mittlerweile als vielversprechender Weg für eine optimierte Software-Entwicklung. Ob die stetige Auslieferung hochwertiger Software aber wirklich den Erfolg bringt, hängt von vielen verschiedenen Faktoren ab, die wiederum in jedem Projekt andere sein können. Lyndsay Prewer (Agile Developer Lead und Berater bei Equal Experts) hat zwei Teams begleitet, die unterschiedlicher nicht hätten sein können. Welche Erfahrungen beide in der Anwendung von CI und CD gemacht haben, wird er in seinem Talk auf der JAX London berichten. Im Folgenden gibt er bereits einen kleinen Vorgeschmack auf seinen Talk und die Erfolgsfaktoren von Continuous Delivery…

Wikipedia zufolge ist Continuous Delivery ein Ansatz in der Software-Entwicklung, mit dem in kurzen Zyklen hochwertige Software produziert wird und der Produktions-Release zu jeder Zeit möglich ist. Continuous Delivery erhält als Best Practice mittlerweile zwar einige Aufmerksamkeit, aber die Übernahme und ständige Weiterentwicklung bleibt eine Herausforderung. Sieht man sich die vielfältigen Teams und Architekturen an, die bereits erfolgreich Continuous Delivery praktizieren, wird offenkundig, dass es hier nicht den einen Königsweg geben kann.

Der folgende Artikel zeigt, wie zwei sehr unterschiedliche Teams Continuous Delivery mit großem Gewinn etabliert und weiterentwickelt haben. Beide Teams waren in der Anwendung von Lean erfahren und auch schon mit agilen Methoden vertraut. Das eine Team hatte für sein Vorhaben Microservices, Scala, MongoDB und Docker auf der grünen Wiese gewählt. Das andere Team stellte sich den technischen Herausforderungen einer monolithischen Architektur mit Legacy Code, .NET, MySQL und Windows.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Modelle für den Team-Erfolg

Aus der Beobachtung beider Teams wurden einige Gemeinsamkeiten ersichtlich, die zu ihrer erfolgreichen Arbeit mit Continuous Delivery beigetragen haben.

  • Eine funktionierende Continuous Integration
    Continuous Integration (CI) ist die Grundlage für Continuous Delivery. Um eine wirklich tragfähige Basis bereit zu stellen, muss das CI-System in einem gutem Zustand sein. Das ist nur möglich, wenn das Team damit übt und sich um das System kümmert. Team-Mitglieder sollten ihre Changes regelmäßig (mehrfach am Tag) integrieren und unverzüglich auf Red Builds antworten. Das Team sollte auch Warnsignale unterdrücken und lang laufende CI-Schritte anpeilen. Diese wichtigen Verhaltensweisen stellen sicher, dass Release Candidates regelmäßig, effizient und schnell hergestellt werden können. Wenn dieser Prozess einmal Stunden statt Minuten dauert, wird Continuous Delivery zu einer Belastung, anstatt als Hilfestellung zu wirken.
  • Automatisierte Tests
    Die Komplexität von Software zu verwalten ist eine enorm herausfordernde Aufgabe. Die richtige Mischung aus automatisierten Tests kann dabei helfen, bei einer Änderung in komplexen Systemen mit Risiko umzugehen. Dazu sollten zunächst die Risiko-Bereiche identifiziert werden (beispielsweise das Fehlen einer Test-Abdeckung oder kaputte Tests), um sie einer genaueren Betrachtung zu unterziehen. In der Anwendung automatischer Testings ist es wichtig, die richtige Verteilung von Unit-, Integrations- und End-to-End-Tests zu finden (nach der gut dokumentierten „Test-Pyramide“). Die Teams, mit denen ich gearbeitet habe, bewegten sich beide auf eine „Tear-Drop Distribution“ zu. Der Ausdruck beschreibt eine sehr kleine Anzahl an End-to-End-Tests, die einer großen Anzahl an Intergrationstests on top aufsitzen. An der Basis befindet sich eine mittlere Anzahl von Unit-Tests. Damit konnte das beste Gleichgewicht zwischen der Verhaltens-Abdeckung und den Änderungskosten erreicht werden, was wiederum eine einfachere Identifizierung des vorhandenen Risikos in der inkrementierten Software ermöglichte.
  • Niedrige Kosten für das Deployment und das Rollback
    Wurde einmal ein Release Candidate vom CI-System produziert und ist das Team auch zufrieden mit dessen Risiko-Level, dann wird ein oder mehrere Deployments stattfinden und zwar vielen verschiedenen Umgebungen (normalerweise QA, Staging/Pre-Production, Produktion). In der Anwendung von Continuous Delivery ereignen sich diese Deployments typischerweise mehrmals pro Woche, wenn nicht sogar mehrmals am Tag. Ein Schlüsselfakor ist dann, die Zeit und den Aufwand für diese Deployments zu minimieren. Das Microservices-Team konnte seinen Overhead auf Minuten verringern, was mehrere Deployments am Tag möglich machte. Das Monolithen-Team konnte den Overhead auf wenige Stunden reduzieren, um damit wöchentliche Deployments zu erzielen. Unabhängig davon, wie oft die Produktions-Deployments stattfinden, müssen die Kosten und der Einfluss des Roll-Back winzig sein (im Sekundenbereich), um die Dienst-Downtime minimal zu halten. Dadurch wird das Rolling Back zu einer schmerzfreien Angelegenheit, es ist dann einfach keine undankbare Aufgabe mehr.
  • Monitoring und Alarmsystem
    Egal wie viel (manuelles oder automatisiertes) Testing ein Release Candidate durchlaufen hat, es gibt immer das Risiko, dass beim Gang in die Produktion etwas schief läuft. Beide Teams aber waren dazu in der Lage, sich die Auswirkung eines Releases beinahe in Echtzeit anzeigen zu lassen, in dem sie Tools wie Elastic Search, Kibana, Papertrail, Splunk und NewRelic verwendeten. Es ist toll, wenn man solche Tools hat, aber sie sind quasi nutzlos, solange man sich nicht mit ihnen beschäftigt. Sie sind auch mit automatischen Warnsignalen (wie zum Beispiel PagerDuty) verbunden. All das erforderte eine Kultur des „sich um die Produktion Kümmerns“, in der das gesamte Team (nicht nur Operations, QA oder Development) wusste, was „normal“ aussah und es damit sofort auffiel, wenn die Zeichen in Richtung Produktion sich zum Schlechteren veränderten.

Fazit

In diesem Artikel wurde gezeigt, wie verschiedene Teams mit sehr unterschiedlichen Methoden sehr erfolgreich Continuous Delivery praktiziert haben. Einige gemeinsame Punkte, die diesen Erfolg ermöglicht haben, wurden angesprochen. Wenn Sie mehr über meine Continuous-Delivery-Reise erfahren möchten und zum Beispiel etwas über die mannigfaltigen Bremsklötze und Beschleuniger oder über die Wirkung von Conway’s Law in den Projekten hören wollen, besuchen Sie meinen Talk auf der JAX London, vom 13.-15. Oktober 2015.

Aufmacherbild: Path into the sun von Shutterstock / Urheberrecht: Screeny

Geschrieben von
Lyndsay Prewer
Lyndsay Prewer
Lyndsay Prewer ist Agile Delivery Lead und momentan Berater für Equal Experts. In seiner Arbeit hilft er Menschen, Teams und Produkten dabei, mit der Anwendung von Agile, Lean und System-Übungen noch besser zu werden. Er ist ehemaliger Raketenwissenschaftler und Entwickler. In den letzten zwanzig Jahren hat er zehn Unternehmen in zwei Hemisphären dabei unterstützt ihre Auslieferung zu optimieren.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: