Die ersten Schritte unserer DevOps-Transformation

Im zweiten Kapitel dieser Serie - DevOps for the Win - untersuchen wir die entscheidenden ersten Schritte einer DevOps-Umstellung. Die ersten Schritte bei einer Transformation sind oft die schwierigsten. Bei DevOps ist die Identifizierung der richtigen ersten Schritte - die sowohl wirkungsvoll als auch realisierbar sind - der Schlüssel zu sinnvollem Fortschritt.

Viele Unternehmen begehen den Fehler, blindlings Best Practices zu implementieren, ohne ihre spezifischen Einschränkungen zu berücksichtigen, was häufig zu Frustration und Misserfolgsmüdigkeit führt. Stattdessen ist ein strategischerer Ansatz erforderlich - einer, der Engpässe identifiziert und systematisch beseitigt.

Wie lassen sich die ersten Schritte erkennen?

Ein wirkungsvolles Prinzip, um herauszufinden, wo man ansetzen sollte, stammt aus der Forschung, die vor 30 Jahren in The Goal: A Process of Ongoing Improvement von Eliyahu M. Goldratt veröffentlicht wurde. Die Idee ist einfach: den primären Engpass identifizieren - den begrenzenden Faktor, der die Systemleistung einschränkt. In unserem Fall wurde dies deutlich, als wir sahen, wie sich die Arbeit im Entwicklungsteam stapelte. Aufgaben wurden begonnen, aber nicht abgeschlossen, und der Arbeitsrückstand wuchs ständig.

Um die Ursachen aufzudecken, organisierten wir intensive Gespräche mit Entwicklungsteams, technischen Leitern und Produktmanagern. Bei diesen Gesprächen traten mehrere zentrale Probleme zutage:

• Die Teams übernahmen neue Aufgaben, bevor sie die bestehenden abschlossen.
• Es gab keine klaren Kriterien für den Abschluss von Aufgaben - was die Entwickler als "erledigt" betrachteten, unterschied sich oft von den Erwartungen der Beteiligten.
• Es gab keine objektiven Qualitätsmaßnahmen, bevor die Arbeit als abgeschlossen markiert wurde, was zu Mängeln und Nacharbeit führte.
• Häufige Versetzungen störten die Stabilität des Teams und führten zu Ineffizienzen.

Aufbau von stabilen Teams

Eine der ersten Korrekturmaßnahmen war die Umstrukturierung von Teams, um Konsistenz und Fokus zu gewährleisten. Anstatt Gruppen von Einzelpersonen als Ad-hoc-Taskforces zu behandeln, bildeten wir stabile, langlebige Teams mit klar definierten Verantwortlichkeiten.

Die Einrichtung einiger Teams, z. B. von Entwicklungsteams, war relativ einfach. Die Organisation von Support-Teams - wie Infrastruktur, Projektmanagement, Produktmanagement und Geschäftsanalyse - erwies sich jedoch als schwieriger. Wir haben mehrere Iterationen durchlaufen, um die richtigen Kombinationen zu finden.

Wir folgen dem Prinzip des Team-First-Denkens, das in den Team Topologies von Matthew Skelton und Manuel Pais beschrieben wird:

• Es wurden kleine, autonome Teams (4-7 Mitglieder) gebildet, um fundiertes Fachwissen und Verantwortlichkeit zu fördern.
• Eliminierung von teamübergreifenden Abhängigkeiten, indem sichergestellt wurde, dass die einzelnen Mitarbeiter vollständig einem einzigen Team zugewiesen wurden.
• Verbesserung der Teamstrukturen, insbesondere für Supportfunktionen wie Infrastruktur und Produktmanagement, um den Arbeitsfluss zu optimieren.

Nutzung von Tools für Sichtbarkeit und Management

Sobald die Teams strukturiert waren, wechselten wir zu Azure DevOps für das Backlog- und Arbeitsmanagement. Eine einheitliche Plattform ermöglicht:

• Bessere Arbeitstransparenz , damit die Teams den Fortschritt transparent verfolgen können.
• Standardisierte Definitionen von "erledigt", um die Erwartungen über alle Funktionen hinweg anzugleichen.
• Verbessertes Backlog-Management, Reduzierung des Umfangs und der Priorisierungskonflikte.

Durchsetzung objektiver Qualitätsmetriken

Um das Problem der unklaren Qualitätsmaßstäbe vor der Kennzeichnung von Aufgaben als "testbereit" zu lösen, haben wir ein statisches Code-Analyse-Tool integriert, das objektive Einblicke in den Code bietet:

• Code-Abdeckung
• Sicherheitsschwachstellen
• Code Gerüche

Außerdem haben wir unsere Definition von "Erledigt" dahingehend erweitert, dass Qualitätsprüfungen ein obligatorischer Schritt sind, bevor Arbeitsaufgaben als erledigt markiert werden.

Verwaltung unfertiger Erzeugnisse (WIP)

Eine der wirkungsvollsten Änderungen war die Überwachung und Begrenzung der laufenden Arbeiten (Work in Progress, WIP). Ein hoher WIP-Wert deutete auf Engpässe hin, sodass us proaktiv Bereiche angehen us , in denen die Arbeit ins Stocken geraten war.

Dieser systematische Ansatz, der sich auf die Ziel- und Teamtopologie stützt, legte den Grundstein für eine kontinuierliche Verbesserung, die Verringerung von Abhängigkeiten und die Verbesserung der Verantwortlichkeit.

Auf unserem Weg zur DevOps-Transformation war eine der wichtigsten Erkenntnisse, dass sich nach den anfänglichen Verbesserungen die größte Einschränkung für den Arbeitsfluss auf das Software-Design verlagerte – insbesondere auf die Testbarkeit unseres Codes. Nachdem wir die anfänglichen Engpässe durch eine Verbesserung der Teamzusammensetzung, die Definition einer „Definition of Done“ und die Implementierung einer Codeanalyse beseitigt hatten, stellten wir fest, dass sich die Arbeit während der Testphase stapelte. Der von den Scrum-Teams entwickelte Code wartete oft darauf, von den QA innerhalb derselben Scrum-Teams getestet zu werden.

Den nächsten Engpass angehen: Die Testlücke

Nachdem die anfänglichen Engpässe beseitigt waren, tauchte ein neues Problem auf: Verzögerungen bei den Tests. Während die Entwicklungsaufgaben effizient voranschritten, wurden die Tests zu einem Hindernis, das eine schnellere Veröffentlichung verhinderte. Bei der Untersuchung fanden wir die wichtigsten Herausforderungen, die den Prozess verlangsamten:

• Vertrauen in manuelle Tests: Die meisten Tests wurden manuell durchgeführt, was zu langsamen Feedbackschleifen und einer verzögerten Fehlererkennung führte.
• UI-Abhängigkeit beim Testen: Da die UI-Komponenten in der Regel zuletzt fertig gestellt wurden, konnte mit den Tests erst spät im Entwicklungszyklus begonnen werden.
• Mangel an proaktiver Automatisierung: Automatisierte Tests, wie z. B. Selenium-basierte UI-Tests, wurden erst nach manuellen Tests geschrieben, was ihre Effektivität bei der Validierung in einem frühen Stadium einschränkte.

Umstellung auf Test-First-Ansätze

Um diesen Engpass zu beseitigen, gaben wir Unit-Tests und API-Tests den Vorrang vor UI-Tests. Diese Umstellung erforderte grundlegende Änderungen in der Entwicklungsmentalität und im Softwaredesign:

Verbesserungen der API-Tests

Um API-Tests effizient zu gestalten:

1. Klar definierte APIs: APIs einfach, gut dokumentiert und frühzeitig in der Entwicklungsphase verfügbar sein, damit Tester proaktiv Testfälle erstellen konnten.
2. Vermeidung der Datenbank als Integrationspunkt:
   • Die Verwendung von Datenbanken als Integrationspunkt zwischen den Teams führte zu Abhängigkeiten, die das Testen verlangsamten.
   • Die Erstellung von Testfällen erforderte die Einrichtung von Datenbanken mit komplexen Daten, was die Einrichtungszeit erhöhte und die Möglichkeit, mehrere Szenarien zu testen, einschränkte.
   • Durch die Umstellung auf eine API-basierte Integration (in erster Linie REST über HTTP und neuerdings GraphQL) konnten wir die durch Datenbankabhängigkeiten verursachten Verzögerungen und Komplexitäten erheblich reduzieren.

Diese Umstellung ermöglichte schnellere Fortschritte bei der Automatisierung von Testfällen für APIs und zeigte, dass die Konzentration auf API-first-Designs sowohl die Testbarkeit als auch die Effizienz verbesserte.

Stärkung der Unit-Test-Praktiken

Unit-Tests stellten eine größere Herausforderung dar:

• Schneller Fortschritt, dann Abdeckungs-Theater: Anfangs erreichten wir eine hohe Codeabdeckung, aber Codeüberprüfungen zeigten, dass viele Unit-Tests oberflächlich waren und nur geschrieben wurden, um die Abdeckungsziele zu erreichen. Diese Tests überprüften keine sinnvollen Funktionen, deckten keine Fehlerszenarien ab und validierten keine Randfälle.
• Änderung der Mentalität: Die Entwickler mussten den Wert von Unit-Tests verstehen - nicht nur zur Verbesserung der Codequalität, sondern auch zur Beschleunigung der Entwicklung durch frühzeitiges Erkennen von Problemen.

Herausforderungen beim Schreiben von testbarem Code

Das größte Hindernis für effektive Unit-Tests war der Mangel an Testbarkeit in der Codebasis selbst. Zu den wichtigsten Problemen gehörten:

• Große, monolithische Funktionen.
• Eng gekoppelte Komponenten.
• Schlechte Trennung der Anliegen.
• Unzureichende Abstraktion.

Diese Probleme machten es schwierig, einzelne Einheiten zu isolieren und effektiv zu testen. Um dieses Problem zu lösen, haben wir:

1. Bereitgestellte Leitlinien: Wir haben bewährte Praktiken ausgetauscht:
   • Auswahl von Funktionen für Unit-Tests.
   • Refactoring von Code zur Verbesserung der Testbarkeit.
   • Entwurf und Verwendung von Mocks zur Erleichterung von Tests.
2. Konzentration auf inkrementelle Verbesserungen: Die Entwickler wurden ermutigt, kleine, sinnvolle Änderungen vorzunehmen, um die Testbarkeit im Laufe der Zeit zu verbessern.

Fortschritte, Herausforderungen und der Weg in die Zukunft

Bei älteren Produkten war die Verbesserung der Testbarkeit aufgrund architektonischer Zwänge ein langsamer Prozess. Diese Maßnahmen zielten jedoch nicht nur auf die Verbesserung der aktuellen Codebasis ab - sie waren eine Investition in die Zukunft:

• Die Entwickler haben sich bessere Gewohnheiten angewöhnt und die Testbarkeit in neue Codebasen eingebettet.
• Die Teams wurden selbstständiger und reduzierten ihre Abhängigkeit von externen QA .
• Das Unternehmen vermied es, Fehler aus der Vergangenheit zu wiederholen und stellte sicher, dass künftige Produkte einfacher zu pflegen und weiterzuentwickeln sind.

Die wichtigste Erkenntnis? Bei DevOps geht es nicht um die Implementierung von Tools oder Checklisten. Es geht um die kontinuierliche Verbesserung des Arbeitsflusses, eine Einschränkung nach der anderen.

Im nächsten Kapitel dieser Reihe werden wir uns mit dem Thema "Designing for Testability" beschäftigen. Wir werden tiefer in die Frage eintauchen, wie durch die Verbesserung des Softwaredesigns Einschränkungen beim Testen beseitigt werden können, wodurch schnellere Feedbackschleifen und eine höhere Softwarequalität ermöglicht werden - zuerst in den Teamstrukturen, dann im Workflow-Management und schließlich in der Testbarkeit - wir legen die Grundlage für eine nachhaltige DevOps-Transformation.