3 Min. Lesezeit
In Kapitel 4: Nachverfolgung wichtiger Aspekte – KPIs und Dashboards haben wir untersucht, wie die Visualisierung von Arbeitsabläufen und die Definition der richtigen KPIs uns dabei halfen, Engpässe zu erkennen und unsere Teams auf die Wertschöpfung auszurichten. Mit einem besseren Einblick in unsere DevOps-Pipeline begannen wir, tiefergehende Fragen zu stellen – nicht nur, wo sich die Engpässe befanden, sondern auch, warum sie auftraten.
In Kapitel 5 befassen wir uns mit einer der bedeutendsten technischen und prozessualen Veränderungen auf unserem Transformationsweg: der Verfeinerung unserer Verzweigungsstrategie und der Ermöglichung einer kontinuierlichen Bereitstellung. Diese Änderungen waren entscheidend, um anhaltende Verzögerungen zwischen Entwicklung und Produktion zu beheben.
Identifizierung des neuen Engpasses
Die Analyse des Arbeitsflusses und die Identifizierung von Engpässen, bei denen sich Arbeit staut, waren ein zentraler Aspekt bei der Umsetzung unserer DevOps-Transformation. Dieser Fokus auf den Fluss bildet das Herzstück unserer Anwendung des DevOps-Dreiecks – Werkzeuge, Architektur und Menschen –, um eine schnellere und zuverlässigere Bereitstellung zu erreichen.
Während wir durch eine steigende Unit-Test- und Testautomatisierungsabdeckung Fortschritte bei der Verbesserung der Testbarkeit erzielten, stellte sich heraus, dass sich zwar die Codequalität verbesserte, der Engpass jedoch weiterhin in der Scrum-Testphase lag. Trotz der Fortschritte bei der Testautomatisierung staute sich die Arbeit, und der Engpass verschob sich von der Entwicklung hin zum Systemtest. Die Leistungskennzahlen (KPIs) zeigten, dass die laufenden Arbeiten (Work-in-Progress) pro Team während der Entwicklung zwar abnahmen, der Code am Übergabepunkt zum Systemtest jedoch weiterhin stecken blieb. Diese Verzögerung hinderte uns letztendlich daran, einen reibungslosen Ablauf zu erreichen.
Die Ursache: Branching-Strategie und verzögerte Merges
Die Analyse ergab, dass die Wurzel des Rückstands in unserer Branching-Strategie lag. Entwickler und Tester erstellten beim Start neuer Funktionen Feature-Branches vom Hauptzweig (Main Branch). Während der Code-Entwicklung pushten die Engineers ihre Änderungen in Remote-Feature-Branches, um ihre Arbeit mit der anderer zu mergen. Dieser Code wurde jedoch nicht häufig genug wieder in den Hauptzweig zurückgeführt.
Die CI/CD-Pipelines waren auf dem Hauptzweig eingerichtet, führten automatisierte Tests aus, übertrugen die Daten in die Cloud und durchliefen anschließende Regressionstests. Da die neuesten Änderungen jedoch nicht regelmäßig in den Hauptzweig gepusht wurden, liefen die Pipeline-Ausführungen mit veraltetem Code, wodurch sie überflüssig und wirkungslos wurden.
Die Lösung: Kurzlebige Feature-Branches
Um dies zu lösen, wurde uns klar, dass eine Feinabstimmung der Branching-Strategie erforderlich war. Obwohl verschiedene Branching-Strategien Vor- und Nachteile haben, beschlossen wir, an der Feature-Branch-Strategie festzuhalten – allerdings mit einer entscheidenden Anpassung: kurzlebigen Feature-Branches, die häufiger in den Hauptzweig zurückgeführt werden.
Die Strategie der kurzlebigen Feature-Branches bietet mehrere Vorteile, wobei der wichtigste in einem verbesserten Arbeitsfluss und der Beseitigung von Engpässen im Entwicklungszyklus liegt. Kürzere Branches sorgen dafür, dass Code-Zusammenführungen (Merges) einfacher, schneller und weniger fehleranfällig sind. Dieser Ansatz ermöglicht zudem ein schnelleres Feedback, was die Gesamtqualität und die Geschwindigkeit des Entwicklungsprozesses steigert.
Continuous Deployment: Die Herausforderung bei der Pipeline
Das Einrichten robuster Continuous-Deployment-Pipelines ist eine komplexe Aufgabe, die einen fokussierten, schrittweisen Ansatz erfordert. Unserer Erfahrung nach ist es empfehlenswert, ein dediziertes Plattformteam für die Einrichtung und Wartung dieser Pipelines einzusetzen, anstatt jedes Scrum-Team individuell daran arbeiten zu lassen. Zwar muss die endgültige Verantwortung für Continuous-Delivery-Pipelines bei den Scrum-Teams liegen, doch profitiert die erste Einrichtungsphase stark von einem dedizierten Plattformteam.
Plattformteam: Reduzierung der kognitiven Belastung und Fokus auf das Wesentliche
Als Inspiration für die Strukturierung unseres Plattformteams diente uns das Buch Team Topologies von Matthew Skelton und Manuel Pais. Das Buch betont, wie wichtig ein dediziertes Plattformteam ist, das für die Einrichtung und Verwaltung der Infrastruktur – in unserem Fall der CD-Pipelines – verantwortlich ist. Diese Struktur ermöglicht es den Scrum-Teams, sich auf die Entwicklung von Funktionen zu konzentrieren und gleichzeitig von einem stabilen und standardisierten Pipeline-Setup zu profitieren.
Wie es im Buch heißt:
„Das Plattformteam ist für den Aufbau und die Wartung der internen Plattform verantwortlich, die stream-ausgerichtete Teams zur Erledigung ihrer Arbeit nutzen. Zweck der Plattform ist es, die kognitive Belastung für stream-ausgerichtete Teams zu verringern, damit diese sich auf die Wertschöpfung konzentrieren können.“
Durch die Zentralisierung der Verantwortung für die Pipelines konnten wir eine gemeinsame Plattform schaffen, auf die sich stream-ausgerichtete Teams verlassen konnten. Dies half uns, die kognitive Belastung der Entwicklungsteams zu verringern, sodass sie sich auf die Bereitstellung von Mehrwerten konzentrieren konnten, anstatt sich mit Infrastrukturproblemen auseinanderzusetzen.
Weiterentwicklung der Plattform für kontinuierliche Verbesserungen
Ein Plattformteam zu haben bedeutet nicht nur, die Pipelines einzurichten; es geht darum, die gemeinsame Infrastruktur und die Tools im Laufe der Zeit kontinuierlich weiterzuentwickeln. Ein dediziertes Plattformteam ist am besten in der Lage, schrittweise Verbesserungen an der Continuous-Delivery-Pipeline vorzunehmen, um sicherzustellen, dass sie den Anforderungen der Teams entspricht und sich an unser Wachstum anpasst. Diese fortlaufende Entwicklung stellt sicher, dass die Plattform zuverlässig, skalierbar und effizient bleibt – und befähigt unsere Teams, Bestleistungen zu erbringen.
Als Nächstes: Automatisierung und Feedback
Nachdem das Branching optimiert und die Bereitstellungen im Fluss sind, widmen wir uns der letzten Grenze auf unserer DevOps-Reise: Automatisierung und Feedback. Im nächsten und letzten Kapitel erfahren Sie, wie das Schließen des Kreislaufs durch automatisierte Einblicke und schnelles Feedback die Arbeitsweise unserer Teams verändert hat.
Seien Sie gespannt!
