Continuous Delivery: geschäftlicher Nutzen, Vorteile, Herausforderungen und Metriken

1. Geschwindigkeit

Automatisierte Pipelines für die Softwareauslieferung helfen Unternehmen, besser auf Marktänderungen zu reagieren. Geschwindigkeit ist besonders bei neuen Features von Bedeutung. Mit einer schnellen Markteinführungszeit können sich Unternehmen gegen ihre Mitbewerber durchsetzen und sich auf dem Markt behaupten.

Geschwindigkeit allein ist jedoch kein Erfolgsmerkmal. Auch die Qualität muss stimmen. Wenn Continuous-Delivery-Pipelines schnell fehlerhaften Code in die Produktionsumgebung übertragen, ist niemandem geholfen.

2. Produktivität

Eine hohe Produktivität steigert die Zufriedenheit der Mitarbeiter – und zufriedene Teams sind motivierter.

Die Produktivität steigt, wenn mühsame Arbeiten und Routineaufgaben wie das Ausfüllen eines Bug-Berichts für jeden gefundenen Fehler automatisch per Pipeline statt manuell ausgeführt werden können. So können sich die Teams auf ihre Ziele konzentrieren, die dann mithilfe von Pipelines umgesetzt werden. Wer würde nicht gerne die unbequemeren Aufgaben an Tools abgeben?

Die Teams überprüfen die von den Pipelines gemeldeten Probleme. Sobald sie die Problembehebung committen, werden wieder Pipelines ausgeführt, um zu überprüfen, ob die Problembehebung erfolgreich war und ob versehentlich neue Probleme verursacht wurden.

3. Nachhaltigkeit

Unternehmen verfolgen nicht nur kurzfristige, sondern auch langfristige Erfolgsziele. Wir wissen, dass es harte Arbeit ist, sich einen Wettbewerbsvorsprung zu verschaffen. Diesen beizubehalten, kann sogar noch anstrengender sein. Es erfordert Disziplin und Unermüdlichkeit. Wer rund um die Uhr hart arbeitet, riskiert jedoch einen Burnout. Wäre es nicht viel cleverer, Routineaufgaben an Computer auszulagern (die übrigens auch keine Kaffeepausen brauchen und nicht widersprechen)?

Jedes Unternehmen – auch außerhalb der Technologiebranche – nutzt Technologie zur Differenzierung. Automatisierte Pipelines verringern den manuellen Arbeitsaufwand und führen letztlich zu Kosteneinsparungen, weil Mitarbeiter teurer sind als Tools. Die hohe Anfangsinvestition kann auf unerfahrene Unternehmensführungen abschreckend wirken. Sorgfältig aufgesetzte Pipelines versetzen das Unternehmen jedoch in die Lage, Kundenanforderungen durch bessere und schnellere Innovationen zu erfüllen. Durch CD kann das Unternehmen die Auslieferung von Features und Fehlerbehebungen flexibler handhaben. Es ist möglich, bestimmte Features nur für bestimmte Kunden oder Kundengruppen zu releasen, um die ordnungsgemäße Funktionsweise und Skalierung zu überprüfen. Features können getestet und entwickelt werden, jedoch im Produkt zunächst deaktiviert bleiben, bis einige weitere Releases erfolgt sind. Die Marketingabteilung möchte bei der wichtigsten Tagung des Jahres einen echten Knaller präsentieren? Mit Continuous Delivery ist dies nicht nur möglich, sondern das reinste Kinderspiel.

Budget: Knapp bei Kasse?

Die Erstellung von Continuous Delivery-Pipelines verlangt die Beteiligung deiner besten Mitarbeiter. Es handelt sich nicht um ein Nebenprojekt, dessen Kosten zu vernachlässigen sind. Ich habe schon oft kopfschüttelnd beobachtet, wie Unternehmen zunächst nur unerfahrene Mitarbeiter für das Projekt eingeteilt und bei der Anschaffung moderner Tools geknausert haben. Irgendwann mussten sie ihren Kurs korrigieren und die erfahrensten Architekten hinzuziehen, um die Architektur zu entkoppeln und ausfallsichere Continuous Delivery-Pipelines zu erstellen.

Kalkuliere nicht zu vorsichtig. Reserviere ausgehend von euren Zielen ausreichend Mittel, um eine unterbrechungsfreie Umsetzung zu gewährleisten. Erstelle zunächst ein MVP (Minimum Viable Product) für die Continuous Delivery-Pipeline, das dann für das gesamte Unternehmen skaliert werden kann.

Gibt es im Unternehmen Vordenker?

Auch mit dem nötigen Budget kann die Umsetzung letztlich an den Mitarbeitern scheitern.

Teams sollten den Mut haben, alte Aufgaben zu automatisieren und sich neuen Projekten zu widmen. Wenn deine Mitarbeiter Vorbehalte gegenüber automatisierten Agents haben, die ehemals manuelle Aufgaben übernehmen, solltest du dir Gedanken um deine Belegschaft machen.

Wenn es scheint, als hättet ihr euch festgefahren, schalte einen Gang hoch. Du musst wissen, wie du deinem Team ein Auto schmackhaft machen kannst, obwohl es nur nach einem schnelleren Pferd gefragt hat. Hole dir für den Anfang Unterstützung von erfahrenen Experten, die euch über die erste Hürde helfen. Letztlich sind deine Mitarbeiter deine wichtigste Ressource. Du solltest sie also ausreichend schulen. Mach es ihnen leicht, sich wie gewünscht zu verhalten, und erschwere unerwünschte Verhaltensweisen – das Ergebnis wird dich positiv überraschen!

Fehlende Priorisierung

"Wir halten die Produktion an und erstellen jetzt Continuous Delivery-Pipelines!" wirst du wohl nicht von deinen Produktinhabern hören.

Zu ihrer Verteidigung: Ihr Fokus liegt auf dem Wettbewerb und daher auf neuen Features, mit denen sie Kunden und Interessenten beeindrucken können. Du hast allerdings ein Problem, wenn in jedem Sprint-Planer Pipelines gegen Produktfeatures abgewogen werden und die Pipelines immer den Kürzeren ziehen.

In manchen Produkt-Backlogs fristen Pipelines – sofern sie überhaupt auftauchen – ein trauriges Dasein ganz am unteren Ende. Wenn es den Führungskräften an Weitsicht mangelt, stufen sie Arbeiten an Pipelines als Ausgaben ein statt als Investitionen, die den Teams zugutekommen. Sie ignorieren die langfristigen Negativfolgen ihrer Entscheidung und kommen damit sogar manchmal durch.

Pipelines stehen für Hygiene. Wenn du dich auf dem Markt behaupten möchtest, musst du dir die Frage stellen: "Ist Hygiene wichtig"? Die Antwort darauf kann nur "Ja" lauten.

Große Mengen an Transaktionsdaten in Pipelines

Stelle dir einen typischen Tag in deinem Softwareentwicklerteam vor. Das Team committet ein vom Unternehmen priorisiertes Feature, committet Tests für dieses Feature und integriert Deployments mit der Continuous-Delivery-Pipeline, sodass jede Änderung automatisch bereitgestellt wird. Das Team stellt fest, dass eine Anwendung nach der Implementierung des neuen Features langsam reagiert, und committet einen Fix für dieses Leistungsproblem. Das Team setzt außerdem Leistungstests ein, um langsame Reaktionszeiten zu erkennen, bevor die Anwendung von der Test- in die Staging-Umgebung wechselt.

Stell dir nun vor, die einzelnen Commits wären Transaktionen. Die Softwareentwicklerteams arbeiten sich Transaktion für Transaktion vor, bis ein Produkt entsteht, mit dem sie Kunden und Interessenten beeindrucken können. Dann geht es wieder von vorne los. Multipliziert mit allen Engineers und Teams im Unternehmen ergibt dies eine riesige Anzahl an Transaktionen.

Analyse der Transaktionsdaten aus der Pipeline

Lassen sich die Transaktionsdaten analysieren, um daraus Informationen zu gewinnen? Aber sicher!

Wie bei allen Transaktionen hindern uns große Datenvolumen daran, relevante Informationen zu erkennen. Daher sollten wir sie zusammenfassen und Analysen durchführen, um Erkenntnisse über unser Unternehmen zu gewinnen. Analysen helfen uns, den Wald vor lauter Bäumen zu sehen. Die folgenden drei Beispiele zeigen, wie wir unsere Verfahren anhand von Pipeline-Analysen und -Einblicken verbessern konnten.

Wir führen jede Woche Hunderte Deployments durch. Dabei fiel uns auf, dass die Anzahl der Deployment-Fehler bei Anwendung A dreimal so hoch war wie bei Anwendung B. Auf Grundlage dieser Erkenntnis prüften wir das Design von Anwendung A hinsichtlich der Umgebungsstabilität und des Konfigurationsmanagements. Wir fanden heraus, dass das Team für das Deployment unzuverlässige virtuelle Maschinen in seinem Rechenzentrum verwendete, während Anwendung B containerisiert war. Wir investierten daraufhin in eine unveränderliche Infrastruktur und prüften nach einem Monat, ob sich unsere Investition ausgezahlt hatte. Und das hatte sie definitiv. Was gemessen werden kann, kann behoben werden.

Ein weiteres Beispiel: Wir stellten fest, dass die Fehleranzahl bei der statischen Codeanalyse für Anwendung B in den letzten Quartalen stetig gestiegen war. Dies könnte darauf hinweisen, dass das Team hinter Anwendung B (erneut) geschult werden muss, um besseren Code schreiben zu können. Außerdem konnten wir beobachten, dass die Tools zur statischen Codeanalyse falsch positive Ergebnisse erzeugten. Sie meldeten also Codeverstöße, obwohl keine vorlagen. Aus diesem Grund führten wir ein Upgrade auf ein in der Branche bekanntes und gängiges Analysetool durch. So ließ sich die Anzahl der falsch positiven Ergebnisse etwas verringern. Wir hielten einen Programmier-Workshop ab, bei dem die berechtigten Fehlermeldungen aus den statischen Analysen besprochen und behoben wurden. Am Ende lief die Arbeit im Team wieder reibungslos.

Eine weitere interessante Erkenntnis war, dass die Codeabdeckung bei den Unit-Tests von Anwendung A zwar unter der von Anwendung B und C lag, bei Anwendung A aber dennoch im letzten Jahr die wenigsten Produktionsprobleme aufgetreten waren. Es ist wunderbar, Unit-Tests zu schreiben und die Codeabdeckung zu messen. Wenn man es jedoch übertreibt, drückt dies die Produktivität des Teams und hat keinen Nutzen für Kunden. Eine wichtige Lektion!

KPIs (Key Performance Indicators)

Wenn es um die Ausrichtung des Unternehmens geht, reichen Meinungen nicht aus. Zunächst müssen wir auf der Basis unserer Vorstellung von Erfolg KPIs definieren. Dann müssen wir die KPIs im Verlauf der Monate, Quartale und Jahre analysieren, um datenbasierte Entscheidungen treffen zu können.

Unternehmens-KPIs/Abteilungs-KPIs

Wir haben oft erlebt, wie einzelne Abteilungen eigene Metriken für den Erfolg definieren. Es ist begrüßenswert, wenn die Abteilungen eine Vorstellung von ihrem Erfolg haben, solange diese Metriken zu den Zielen des Unternehmens passen.

Fehler in der Test-/Staging-/Produktionsumgebung

Manche Unternehmen haben festgelegt, dass die Entwicklerabteilung für die Testumgebung, die QA-Abteilung für das Staging und die Operations-Abteilung für die Produktion verantwortlich sind. Statt sich in Codeabdeckungsberichten für in der Testumgebung ausgeführte Unit-Tests zu vergraben, sollten die Entwickler einen Schritt zurücktreten und das Gesamtbild in allen Umgebungen betrachten – auch wenn sie nicht für alle Umgebungen zuständig sind.

Der Prozentsatz der Fehler in der Staging-Umgebung aufgrund von Leistungstests könnte hoch sein oder auf fehlerhafte Leistungs-Benchmarks oder langsamen Code zurückzuführen sein. Eine Vergleichsanalyse könnte ergeben, dass Pipelines meist bei Integrations-Smoke-Tests in der Produktion fehlerhaft sind, was eine weitere Untersuchung rechtfertigen würde. Die Ursache könnten echte Produktbugs sein. Aber auch fehlerhafter Testcode, ungenaue Testdaten, falsche Testkonfigurationen, Missverständnisse zwischen der Produkt- und Entwicklungsabteilung und andere Ursachen kommen infrage.

Eine genauere Untersuchung könnte ergeben, dass zahlreiche Tests falsch konfiguriert sind. Du könntest dann die Behebung dieser Fehler priorisieren, um häufige Integrationsfehler zu eliminieren. Dass die Entwickler bis zur Produktion für ihren Code zuständig sind, passt auch zum DevOps-Paradigma.

Stabilitätsindex

Sobald wir die KPIs definiert haben, müssen wir herausfinden, ob einzelne KPIs Verzerrungen aufweisen bzw. stark in eine bestimmte Richtung verzerrt sind. In diesem Fall müssen wir sie mit anderen KPIs ausgleichen, die den Schwerpunkt wieder näher zur Mitte rücken. Eine solche KPI ist die Stabilität.

Entwickler messen die Stabilität anhand der Vorlaufzeit von Features (Feature Lead Time), d. h. der Zeitdauer bis zur Einführung eines Features in der Produktion. Da ein Feature eine Reihe von Commits umfasst, lässt sich die Vorlaufzeit von Features noch genauer anhand von CheckIn2GoLive ermitteln. Dies ist die Zeitdauer vom Einchecken bis zur Einführung in der Produktion.

Für die Messung von CheckIn2GoLive eignen sich Pipelines, da ermittelt werden kann, wie lange eine Pipeline braucht, um Code von der Test- zur Staging und schließlich zur Produktionsumgebung weiterzugeben. CheckIn2GoLive zeigt außerdem die MTTR (Mean Time To Resolve) von Defekten an, da der Bugfix durch dieselbe Pipeline (von der Test- zur Staging- bis zur Produktionsumgebung) weitergegeben wird.

Interessanterweise ist das Schlagwort "Geschwindigkeit" meiner Erfahrung nach in der Operations-Abteilung oft negativ konnotiert, da die Mitarbeiter in dieser Abteilung auf Risikominimierung fokussiert sind. Sie messen Fehler anhand der Anzahl der nicht erkannten Defekte und definieren Stabilität auf Basis des Verhältnisses zwischen den von der Pipeline erkannten und den nicht erkannten Defekten.

Unternehmen definieren die Stabilität auf Grundlage der Kundenzufriedenheit oder der Anzahl von Stammkunden. Dies klingt zunächst subjektiv, aber diese Metrik lässt sich anhand der von Kunden gemeldeten Defekte oder anhand von Kundenumfragen berechnen.

Der Stabilitätsindex ist ein typisches Beispiel, das Entwickler, Operations-Abteilung und Geschäftsbereiche jeweils aus einem anderen Blickwinkel betrachten. Das Unternehmen sollte nach Möglichkeit eine gesunde Balance finden, statt eine Sichtweise komplett zu übernehmen. So entsteht ein unparteiischer unternehmensweiter Index für die Stabilität.

Codequalitätsindex

Auch bei der Codequalität sind die unterschiedlichen Perspektiven zu berücksichtigen. Manche Entwickler beurteilen die Qualität ihres Codes anhand der an Unit-Tests gemessenen Codeabdeckung, während andere sie anhand der zyklomatischen Komplexität bewerten. Standardtools für statische Analysen erstellen Berichte zu mehrfach vorhandenem Code, Sicherheitsschwachstellen und potenziellen Speicherlecks. Alle diese Aspekte geben tatsächlich Aufschluss über die Codequalität und bilden zusammen mit möglichen anderen Aspekten einen aussagekräftigen Index.

Geschäftliche KPIs/technische KPIs

Ein weiterer gängiger KPI, den Unternehmen oft nutzen, ist der mit einem Sprint geschaffene Mehrwert. Oft wird dazu lediglich die Anzahl der Releases herangezogen, die aber an sich noch keinen Mehrwert schaffen. Beispielsweise entsteht dem Unternehmen durch simples Verschieben von A nach B keinerlei Nutzen. Manche Unternehmen messen auch die Anzahl der im jeweiligen Sprint hinzugefügten Tests oder die Gesamtanzahl der durchgeführten Tests. Auch diese Zahlen spiegeln jedoch keine echten Geschäftsergebnisse wider, sondern nur den Aufwand der Entwickler. Der in einem Sprint geschaffene Mehrwert muss für das Unternehmen relevant sein.

Als geschäftliche KPIs eignen sich beispielsweise die Anzahl der im letzten Quartal gewonnenen Neukunden und die Anzahl der durch Werbung generierten Klicks im letzten Monat. Pipelines haben keinen direkten Einfluss auf diese geschäftlichen Metriken. Die Zuordnung zwischen geschäftlichen und technischen KPIs dient nur dem Verständnis der Beziehung zwischen technischer Expertise und Geschäftszielen.

Anhand der Zuordnung zwischen geschäftlichen KPIs und Pipelines können wir auch den ROI (Return on Investment) der Pipelines berechnen. Führungsteams nutzen diese Metriken zur Ermittlung von Bereichen mit Optimierungspotenzial und für die Budgetplanung.

Mach dich auf den Weg