Automatisierung und Feedback: Den DevOps-Kreislauf schließen
4 Min. Lesezeit

In Kapitel 5: Branching und Continuous Deployment haben wir untersucht, wie kurzlebige Branches und eine zentralisierte Continuous-Deployment-Plattform (CD) uns dabei halfen, die Bereitstellung zu beschleunigen und Integrationsprobleme zu reduzieren. Diese Änderungen verbesserten den Codefluss in die Produktion erheblich – doch um den DevOps-Feedback-Kreislauf wirklich zu schließen, brauchten wir mehr.

Kapitel 6, der letzte Teil unserer Reihe DevOps for the Win, widmet sich der letzten, aber entscheidenden Säule unserer Transformation: Automatisierung und Feedback. Wenn Continuous Deployment uns half, schneller zu veröffentlichen, dann halfen uns Automatisierung und Feedback, schneller zu lernen, wodurch wir uns kontinuierlich und mit Zuversicht verbessern konnten.

Warum Automatisierung und Feedback wichtig sind

Bei jeder DevOps-Transformation ist Geschwindigkeit ohne Sicherheit ein Rezept für das Scheitern. Mit zunehmender Bereitstellungshäufigkeit wurde der Bedarf an automatisierten Prüfungen und Echtzeit-Feedback entscheidend – nicht nur für die Qualitätssicherung, sondern auch für die Stärkung der Teams und die Entscheidungsfindung.

Automatisierungs- und Feedbacksysteme bieten Teams:

  • Frühes Erkennen von Problemen, bevor sie in die Produktion gelangen
  • Vertrauen in Änderungen durch wiederholbare, zuverlässige Validierung
  • Aufschlussreiche Metriken zum Verständnis der Systemintegrität und der Auswirkungen auf Benutzer

Es ist der Unterschied zwischen Blindflug und Fliegen mit einem Dashboard.

Nachdem wir die Entwicklungsgeschwindigkeit verbessert hatten, lag unser nächster Fokus darauf, Engpässe in der Feedbackschleife zu identifizieren, sobald das Entwicklungsteam die Arbeit als „erledigt“ markiert hatte. Dabei war das Hauptmaß für den Arbeitsfluss, wie schnell abgeschlossene Arbeiten in die Produktion überführt werden konnten.

Die Durchlaufzeit für Änderungen und die Bereitstellungshäufigkeit sind Schlüsselkennzahlen, um zu messen, wie effizient Arbeit durch das System fließt. In unserem Fall staute sich die Arbeit in der System-QA-Phase (SQA) und verursachte einen Engpass bei der Bereitstellungsbereitschaft.

Der System-QA-Engpass

In den meisten Bereichen, einschließlich unserem, schreiben regulatorische Anforderungen eine Reihe von Validierungsaktivitäten vor, um die Softwarequalität sicherzustellen. Dazu gehören:

  • Integrationstests
  • Systemtests
  • Nicht-funktionale Tests (z. B. Netzwerkprüfung, Leistungstests)
  • Validierungsartefakte → Systemtestberichte, IQ (Installationsqualifizierung), OQ (Funktionsqualifizierung) und PQ (Leistungsqualifizierung)

Diese Aufgaben müssen in kontrollierten Umgebungen, getrennt von der Entwicklung, durchgeführt werden, um die Einhaltung der Vorschriften sicherzustellen. Aus diesem Grund arbeitet das System-QA-Team unabhängig, und Tests können erst beginnen, nachdem das Entwicklungsteam seine Arbeit abgeschlossen hat.

Unsere Dashboards zeigten, dass die Zeit, die benötigt wurde, um abgeschlossene Arbeiten in den produktionsbereiten Status zu überführen, zunahm, wobei immer mehr Arbeit darauf wartete, dass die SQA mit den Tests begann. Gemäß unserem grundlegenden Ansatz zur Verbesserung des Arbeitsflusses war dies ein Problem, das wir angehen mussten, bevor weitere DevOps-Optimierungen einen echten Mehrwert zeigen konnten.

Wesentliche Herausforderungen im Arbeitsfluss von der Entwicklung zur SQA

Es gab zwei wesentliche Herausforderungen bei der Verbesserung des Arbeitsflusses von der Entwicklung zur System-QA:

  1. Die Verzögerung beim Start von SQA-Aufgaben
  2. Die Geschwindigkeit, mit der die Systemvalidierung durchgeführt werden konnte

Wenn SQA-Tests hauptsächlich manuell durchgeführt werden, können sie erst beginnen, wenn der Code vollständig entwickelt und in kontrollierten Umgebungen bereitgestellt ist. Dies bestimmt sowohl, wann die Tests beginnen können, als auch, wie lange ihre Durchführung dauern wird. Das Beste, was die SQA in diesem Modell tun kann, ist, Testskripte im Voraus vorzubereiten und darauf zu warten, dass die „Definition of Done“ (DoD) des Entwicklungsteams erreicht wird, bevor die Tests ausgeführt werden.

Automatisierung der SQA: Ein Wandel in der Teststrategie

Der einzige Weg, diesen Ablauf zu verbessern, ist eine massive Konzentration auf die Automatisierung. Dabei geht es jedoch nicht nur um die Automatisierung der Testausführung – es erfordert einen grundlegenden Wandel in der Herangehensweise an Tests. Dazu gehören:

  • Neudefinition und Neuausrichtung der Ziele der System-QA.
  • Neubewertung der Validierungsdurchführung, um sowohl Geschwindigkeits- als auch regulatorische Anforderungen zu erfüllen.
  • Neugestaltung der benötigten Tools und Frameworks, um die Automatisierung effektiv zu unterstützen.

Eine der wichtigsten Umstellungen im Denken war der Übergang vom Testen zur Bestätigung, dass die entwickelte Software funktioniert → zum Testen zur Steuerung der Entwicklung.

Das bedeutete, Testskripte zu erstellen, zu automatisieren und in einer Umgebung auszuführen, in der Entwicklungscode regelmäßig bereitgestellt wird, noch bevor der Feature-DoD (Definition of Done) erreicht ist. Hier weisen Testfehler nicht auf einen Defekt hin, sondern geben frühzeitig Aufschluss darüber, welche Teile der Funktionalität noch nicht implementiert oder vollständig funktionsfähig sind.

Mit etablierten Continuous-Delivery-Pipelines und einer verfeinerten Branching-Strategie, bei der Feature-Branches häufig in den Haupt-Branch zusammengeführt und in die Cloud bereitgestellt werden, haben wir eine dedizierte Umgebung eingerichtet, in der diese automatisierten Systemtests kontinuierlich laufen konnten.

Schnelleres Feedback durch automatisierte Tests

Dieser Ansatz ermöglichte es der System-QA, die Validierung früher zu beginnen, wodurch Tests beschleunigt und dem Entwicklungsteam schnelleres Feedback gegeben werden konnte. Anstatt zu warten, bis ein Feature als abgeschlossen markiert ist, laufen Tests nun parallel zur Entwicklung und geben den Teams Echtzeit-Einblicke darüber, was funktioniert und was noch fertiggestellt werden muss.

Gleichzeitig erforderte die Automatisierung von Testfällen ein Überdenken der Teststrategien.

  • Die Abkehr von der UI-basierten Automatisierung machte API-Tests zur Priorität.
  • Umstellung auf Behavior-Driven Development (BDD) – Erstellung von Testskripten parallel zu User Stories, die in die Akzeptanzkriterien aufgenommen werden sollen.

Auch wenn die vollständige Einführung von BDD von Beginn der User-Story-Erstellung an noch in Arbeit ist, haben wir die Zusammenarbeit zwischen SQA- und Entwicklungsteams verbessert, indem wir sie frühzeitig im Prozess aufeinander abgestimmt haben.

SQA auf die Entwicklung abstimmen: Der Einfluss von Team Topologies

Um dies zu erreichen, haben wir den Spezialistenteam-Ansatz aus Team Topologies angewandt, indem wir das SQA-Team als Enabling-Team aufgestellt haben. Anstatt eine separate, nachgelagerte Testfunktion zu sein, wurden die SQA-Teammitglieder eng mit der Entwicklung abgestimmt, um sicherzustellen, dass die Erstellung von automatisierten Testfällen frühzeitig beginnt und kontinuierlich während der Codeentwicklung erfolgt.

Eine wesentliche Voraussetzung für diesen Ansatz ist eine Cloud-based Testumgebung, um Systemtests durchzuführen, bevor man zu kontrollierten Umgebungen übergeht. Obwohl dies zusätzliche Infrastrukturkosten mit sich bringt, erhöht es den Arbeitsfluss von der Entwicklung zur SQA erheblich, wodurch die Bereitstellung viel schneller erfolgen kann.

Fazit

Diese Verbesserung untermauert ein zentrales DevOps-Prinzip – die Transformation durch Berücksichtigung von Werkzeugen, Architektur und Mitarbeiterkompetenzen anzugehen, während der Fokus auf dem Fluss liegt. Durch die Automatisierung der System-QA, die frühere Integration von Tests in den Zyklus und die effektivere Abstimmung der Teams haben wir den Engpass zwischen Entwicklung und Systemvalidierung erheblich reduziert, wodurch Feedbackschleifen beschleunigt und Bereitstellungen reibungsloser wurden.

Abschluss der Reihe

Zum Abschluss unserer Serie DevOps for the Win blicken wir auf den Weg vom Tooling-Chaos und manuellen Prozessen zu einer vernetzteren, automatisierteren und leistungsfähigeren Organisation zurück. Von der Definition unseres DevOps-Dreiecks in Kapitel 1 bis zur Etablierung feedbackgesteuerten Lernens in Kapitel 6 baute jedes Kapitel auf dem vorherigen auf, um eine bedeutsame Transformation voranzutreiben.

Hier ist eine kurze Zusammenfassung unserer Reihe:

Dieser Wandel ist noch nicht abgeschlossen, aber mit dem Fundament, das wir geschaffen haben, sind wir besser denn je gerüstet, um Werte schneller, sicherer und intelligenter zu liefern.

Vielen Dank, dass Sie uns auf dieser Reise begleitet haben. Wir hoffen, unsere Geschichte inspiriert Ihre eigene DevOps-Entwicklung.

Bleiben Sie neugierig. Bleiben Sie iterativ. Und am wichtigsten: Bleiben Sie in Verbindung.

Abonnieren Sie den Freyr-Blog