3 Minuten lesen
Unter Kapitel 4: Verfolgen, worauf es ankommt - KPIs und Dashboardshaben wir untersucht, wie die Visualisierung von Arbeitsabläufen und die Definition der richtigen KPIs us geholfen haben, Engpässe zu erkennen und unsere Teams auf die Wertschöpfung auszurichten. Mit der besseren Sichtbarkeit unserer DevOps-Pipeline begannen wir, tiefergehende Fragen zu stellen - nicht nur, wo die Engpässe lagen, sondern auch, warum sie auftraten.
In Kapitel 5 befassen wir uns mit einer der wichtigsten technischen und prozessualen Veränderungen auf unserer Transformationsreise: der Verfeinerung unserer Verzweigungsstrategie und der Aktivierung der kontinuierlichen Bereitstellung. Diese Änderungen waren ausschlaggebend für die Beseitigung der anhaltenden Verzögerungen zwischen Entwicklung und Produktion.
Identifizierung des neuen Engpasses
Die Analyse des Arbeitsflusses und die Ermittlung von Engpässen, in denen sich die Arbeit staut, war ein wichtiger Aspekt bei der Umsetzung unserer DevOps-Umstellung. Dieser Fokus auf den Arbeitsfluss ist das Herzstück der Anwendung des DevOps-Dreiecks - Tools, Architektur und Menschen -, um eine schnellere und zuverlässigere Bereitstellung zu erreichen.
Als wir Fortschritte bei der Verbesserung der Testbarkeit durch die zunehmende Abdeckung von Unit-Tests und Testautomatisierung machten, stellten wir fest, dass sich die Codequalität zwar verbesserte, der Engpass aber immer noch in der Scrum-Testphase lag. Trotz der Fortschritte bei der Testautomatisierung stapelte sich die Arbeit immer noch, und der Engpass verlagerte sich von der Entwicklung zum Testen auf Systemebene. Die Key Performance Indicators (KPIs) zeigten, dass der Arbeitsfortschritt pro Team während der Entwicklung abnahm, aber der Code blieb immer noch am Übergangspunkt zum Systemtest stecken. Diese Verzögerung hinderte us letztendlich daran, einen reibungslosen Ablauf zu erreichen.
Die Hauptursache: Verzweigungsstrategie und verzögerte Zusammenführungen
Die Analyse ergab, dass die Ursache für den Rückstand in unserer Verzweigungsstrategie lag. Entwickler und Tester erstellten Funktionszweige vom Hauptzweig aus, wenn sie mit neuen Funktionen begannen. Während sich der Code entwickelte, schoben die Ingenieure ihre Änderungen in entfernte Funktionszweige, um ihre Arbeit mit anderen zusammenzuführen. Dieser Code wurde jedoch nicht häufig genug in den Hauptzweig zurückgeführt.
Die CI/CD-Pipelines waren auf dem Hauptzweig eingerichtet, führten automatisierte Tests durch und stellten in der Cloud bereit, gefolgt von Regressionstests. Da jedoch die neuesten Änderungen nicht regelmäßig in den Hauptzweig übertragen wurden, liefen die Pipeline-Ausführungen auf veraltetem Code, was sie redundant und ineffektiv machte.
Die Lösung: Kurzlebige Feature-Zweige
Um dieses Problem zu lösen, wurde uns klar, dass eine Feinabstimmung der Verzweigungsstrategie notwendig war. Es gibt zwar Vor- und Nachteile verschiedener Verzweigungsstrategien, aber wir haben uns entschieden, mit der Strategie der Feature-Zweige fortzufahren, allerdings mit einer wichtigen Anpassung: kurzlebige Feature-Zweige, die häufiger wieder in den Hauptzweig zusammengeführt werden.
Die Strategie der kurzlebigen Funktionszweige bietet mehrere Vorteile, wobei der wichtigste Vorteil in der Verbesserung des Arbeitsflusses und der Beseitigung von Engpässen im Entwicklungszyklus liegt. Kürzere Verzweigungen sorgen dafür, dass die Zusammenführung von Code einfacher, schneller und weniger fehleranfällig ist. Dieser Ansatz ermöglicht auch ein schnelleres Feedback, was die Gesamtqualität und Geschwindigkeit des Entwicklungsprozesses verbessert.
Kontinuierliche Bereitstellung: Die Pipeline-Herausforderung
Die Einrichtung robuster kontinuierlicher Bereitstellungspipelines ist eine komplexe Aufgabe, die einen gezielten, schrittweisen Ansatz erfordert. Unserer Erfahrung nach empfiehlt es sich, ein eigenes Plattformteam mit der Einrichtung und Pflege dieser Pipelines zu betrauen, anstatt jedes Scrum-Team einzeln daran arbeiten zu lassen. Auch wenn die Verantwortung für die Continuous-Delivery-Pipelines letztendlich bei den Scrum-Teams liegen muss, ist die anfängliche Aufgabe der Einrichtung dieser Pipelines durch ein dediziertes Plattformteam sehr hilfreich.
Plattform-Team: Reduzierung der kognitiven Belastung und Ermöglichung von Konzentration
Um uns bei der Strukturierung unseres Plattformteams zu inspirieren, haben wir uns an Team Topologies von Matthew Skelton und Manuel Pais orientiert. In dem Buch wird betont, wie wichtig es ist, ein eigenes Plattformteam zu haben, das für die Einrichtung und Verwaltung der Infrastruktur - inunserem Fall der CD-Pipelines - verantwortlich ist. Diese Struktur ermöglicht es den Scrum-Teams, sich auf die Entwicklung von Funktionen zu konzentrieren, während sie von einer stabilen und standardisierten Pipeline-Einrichtung profitieren.
Wie es im Buch heißt:
"Das Plattformteam ist für den Aufbau und die Pflege der internen Plattform verantwortlich, die von den an den Datenströmen orientierten Teams zur Erbringung ihrer Leistungen genutzt wird. Der Zweck der Plattform ist es, die kognitive Belastung für die auf den Strom ausgerichteten Teams zu reduzieren, damit sie sich auf die Wertschöpfung konzentrieren können."
Indem wir die Verantwortung für die Pipelines zentralisierten, konnten wir eine gemeinsame Plattform schaffen, auf die sich die nach Streams ausgerichteten Teams verlassen konnten. Auf diese Weise konnten us die kognitive Belastung der Entwicklungsteams reduzieren, sodass sie sich auf die Wertschöpfung konzentrieren konnten, anstatt sich mit Infrastrukturfragen zu beschäftigen.
Weiterentwicklung der Plattform für kontinuierliche Verbesserung
Bei einem Plattformteam geht es nicht nur darum, die Pipelines einzurichten, sondern auch darum, die gemeinsame Infrastruktur und die Tools im Laufe der Zeit weiterzuentwickeln. Ein dediziertes Plattformteam ist am besten in der Lage, die Continuous-Delivery-Pipeline schrittweise zu verbessern und sicherzustellen, dass sie auf die Bedürfnisse der Teams abgestimmt ist und sich anpasst, wenn wir skalieren und wachsen. Durch diese kontinuierliche Weiterentwicklung wird sichergestellt, dass die Plattform zuverlässig, skalierbar und effizientbleibt undunsere Teams ihr Bestes geben können.
Nächstes Thema: Automatisierung und Feedback
Nachdem die Verzweigungen gestrafft wurden und die Bereitstellungen reibungslos verlaufen, wenden wir uns der letzten Grenze auf unserer DevOps-Reise zu: Automatisierung und Feedback. Im nächsten und letzten Kapitel werden wir untersuchen, wie das Schließen des Kreislaufs mit automatisierten Erkenntnissen und schnellem Feedback die Arbeitsweise unserer Teams verändert hat.
Bleiben Sie dran!
