,
3 Min. Lesezeit
In Kapitel 4: Das Wesentliche verfolgen – KPIs und Dashboards haben wir beleuchtet, wie die Visualisierung von Arbeitsabläufen und die Festlegung passender KPIs uns halfen, Engpässe zu identifizieren und unsere Teams auf die Wertschöpfung auszurichten. Mit einem besseren Überblick über unsere DevOps-Pipeline begannen wir, tiefergehende Fragen zu stellen – nicht nur, wo die Engpässe lagen, sondern auch, warum sie entstanden.
In Kapitel 5 widmen wir uns einer der wichtigsten technischen und prozessualen Veränderungen auf unserem Weg der Transformation: der Optimierung unserer Branching-Strategie und der Einführung von Continuous Deployment. Diese Anpassungen waren ausschlaggebend, um wiederkehrende Verzögerungen zwischen Entwicklung und Produktion zu beseitigen.
Den neuen Engpass erkennen
Die Analyse des Arbeitsflusses und das Erkennen von Engpässen, an denen sich Aufgaben stauen, waren entscheidend für unsere DevOps-Transformation. Dieser Fokus auf den Fluss bildet den Kern unserer Herangehensweise, bei der wir das DevOps-Dreieck – bestehend aus Tools, Architektur und Menschen – eingesetzt haben, um eine schnellere und zuverlässigere Bereitstellung zu ermöglichen.
Obwohl wir die Testbarkeit durch mehr Unit-Tests und eine bessere Testautomatisierung verbessern konnten, stellten wir fest, dass sich die Codequalität zwar verbesserte, der Engpass aber weiterhin in der Scrum-Testphase lag. Trotz der Fortschritte bei der Testautomatisierung staute sich die Arbeit immer noch, und der Engpass verlagerte sich von der Entwicklung zum Systemtest. Wichtige Leistungskennzahlen (KPIs) zeigten, dass die laufende Arbeit pro Team während der Entwicklung abnahm, der Code jedoch immer noch am Übergang zum Systemtest stecken blieb. Diese Verzögerung verhinderte letztendlich einen reibungslosen Arbeitsfluss.
Die Ursache: Branching-Strategie und verzögerte Zusammenführungen
Die Analyse zeigte, dass die Ursache des Rückstands in unserer Branching-Strategie lag. Entwickler und Tester erstellten Feature-Branches vom Hauptzweig, sobald sie mit neuen Funktionen begannen. Während der Entwicklung übertrugen die Ingenieure ihre Änderungen auf entfernte Feature-Branches, um ihre Arbeit mit anderen zu synchronisieren. Allerdings wurde dieser Code nicht oft genug in den Hauptzweig zurückgeführt.
Die CI/CD-Pipelines waren auf dem Hauptzweig eingerichtet und führten automatisierte Tests sowie die Bereitstellung in der Cloud durch, gefolgt von Regressionstests. Da die neuesten Änderungen jedoch nicht regelmäßig in den Hauptzweig übertragen wurden, liefen die Pipeline-Ausführungen mit veraltetem Code, wodurch sie überflüssig und ineffektiv wurden.
Die Lösung: Kurzlebige Feature-Branches
Um dieses Problem zu lösen, erkannten wir, dass eine Feinabstimmung der Branching-Strategie erforderlich war. Obwohl verschiedene Branching-Strategien Vor- und Nachteile haben, entschieden wir uns, bei der Feature-Branch-Strategie zu bleiben, jedoch mit einer wichtigen Änderung: kurzlebige Feature-Branches, die häufiger in den Hauptzweig zurückgeführt werden.
Die Strategie der kurzlebigen Feature-Branches bietet mehrere Vorteile, wobei der wichtigste Nutzen ein verbesserter Arbeitsfluss und die Beseitigung von Engpässen im Entwicklungszyklus ist. Kurzlebigere Branches sorgen dafür, dass das Zusammenführen von Code einfacher, schneller und weniger fehleranfällig ist. Dieser Ansatz ermöglicht zudem ein schnelleres Feedback, was die Gesamtqualität und Geschwindigkeit des Entwicklungsprozesses verbessert.
Continuous Deployment: Die Herausforderung der Pipeline
Der Aufbau robuster Continuous-Deployment-Pipelines ist eine komplexe Aufgabe, die einen fokussierten, schrittweisen Ansatz erfordert. Unserer Erfahrung nach ist es ratsam, ein spezialisiertes Plattformteam für die Einrichtung und Wartung dieser Pipelines zu haben, anstatt jedes Scrum-Team einzeln daran arbeiten zu lassen. Obwohl die Verantwortung für Continuous-Delivery-Pipelines letztendlich bei den Scrum-Teams liegen muss, profitiert die anfängliche Einrichtung erheblich von einem dedizierten Plattformteam.
Plattformteam: Kognitive Belastung reduzieren und Fokus ermöglichen
Für die Strukturierung unseres Plattformteams ließen wir uns von Team Topologies von Matthew Skelton und Manuel Pais inspirieren. Das Buch betont, wie wichtig ein spezialisiertes Plattformteam ist, das für den Aufbau und die Verwaltung der Infrastruktur – in unserem Fall der CD-Pipelines – zuständig ist. Diese Struktur ermöglicht es den Scrum-Teams, sich auf die Funktionsentwicklung zu konzentrieren und gleichzeitig von einer stabilen und standardisierten Pipeline-Einrichtung zu profitieren.
Wie im Buch beschrieben:
„Das Plattformteam ist für den Aufbau und die Pflege der internen Plattform zuständig, die von den Stream-Aligned-Teams genutzt wird, um ihre Arbeit zu erledigen. Ziel der Plattform ist es, die kognitive Belastung für diese Teams zu verringern, damit sie 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 die wertstromorientierten Teams verlassen konnten. Dies ermöglichte es uns, die kognitive Belastung der Entwicklungsteams zu reduzieren, sodass sie sich auf die Wertschöpfung konzentrieren konnten, anstatt sich mit Infrastrukturproblemen zu befassen.
Die Weiterentwicklung der Plattform für kontinuierliche Verbesserung
Ein Plattform-Team zu haben bedeutet nicht nur, die Pipelines einzurichten; es geht darum, die gemeinsame Infrastruktur und die Tools im Laufe der Zeit weiterzuentwickeln. Ein engagiertes Plattform-Team ist am besten in der Lage, schrittweise Verbesserungen an der Continuous-Delivery-Pipeline vorzunehmen, um sicherzustellen, dass sie den Bedürfnissen der Teams entspricht und sich an unser Wachstum und unsere Skalierung anpasst. Diese kontinuierliche Weiterentwicklung stellt sicher, dass die Plattform zuverlässig, skalierbar und effizient bleibt – und unsere Teams befähigt, optimale Leistungen zu erbringen.
Als Nächstes: Automatisierung und Feedback
Nachdem das Branching optimiert und die Deployments reibungslos ablaufen, wenden wir uns der letzten Etappe unserer DevOps-Reise zu: Automatisierung und Feedback. Im nächsten und letzten Kapitel werden wir untersuchen, wie die Schließung des Kreislaufs mit automatisierten Erkenntnissen und schnellem Feedback die Arbeitsweise unserer Teams verändert hat.
Bleiben Sie auf dem Laufenden!
