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

In Kapitel 5: Verzweigung und kontinuierliche Bereitstellung haben wir untersucht, wie kurzlebige Branches und eine zentralisierte Plattform für die kontinuierliche Bereitstellung (CD) uns geholfen haben, die Bereitstellung zu beschleunigen und Integrationskonflikte zu verringern. Diese Änderungen haben den Code-Fluss in die Produktion drastisch verbessert – um den DevOps-Feedback-Loop jedoch wirklich zu vollenden, benötigten 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 uns die kontinuierliche Bereitstellung geholfen hat, Releases schneller zu veröffentlichen, dann haben uns Automatisierung und Feedback dabei geholfen, schneller zu lernen – und uns so mit Zuversicht kontinuierlich zu verbessern.

Warum Automatisierung und Feedback wichtig sind

Bei jeder DevOps-Transformation ist Geschwindigkeit ohne Sicherheit der beste Weg zum 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 zur Stärkung der Teams und für fundierte Entscheidungen.

Automatisierungs- und Feedback-Systeme bieten Teams:

  • Frühzeitige Erkennung von Problemen, noch bevor sie die Produktion erreichen
  • Sicherheit bei Änderungen durch wiederholbare, zuverlässige Validierung
  • Aussagekräftige Kennzahlen zum Verständnis des Systemstatus und der Auswirkungen auf die Anwender

Das macht den Unterschied zwischen Blindflug und dem Flug mit einem Dashboard.

Nachdem wir die Entwicklungsgeschwindigkeit verbessert hatten, lag unser nächster Fokus darauf, Engpässe im Feedback-Loop zu identifizieren, sobald das Entwicklungsteam die Arbeit als „erledigt“ markierte. Das Hauptmaß für den Arbeitsfluss war hierbei, wie schnell die fertiggestellte Arbeit in der Produktion bereitgestellt werden konnte.

Die Durchlaufzeit für Änderungen (Lead Time for Change) und die Bereitstellungshäufigkeit (Deployment Frequency) sind wichtige Kennzahlen, um zu messen, wie effizient Arbeit durch das System fließt. In unserem Fall staute sich die Arbeit in der System-QA-Phase (SQA), was zu einem Engpass bei der Bereitstellungsreife führte.

Der System-QA-Engpass

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

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

Diese Aufgaben müssen in kontrollierten, von der Entwicklung getrennten Umgebungen durchgeführt werden, um die Einhaltung der Vorschriften zu gewährleisten. 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 bis zur Bereitstellungsreife der abgeschlossenen Arbeit zunahm, da immer mehr Aufgaben darauf warteten, dass die SQA mit den Tests beginnen konnte. Gemäß unserem grundlegenden Ansatz zur Verbesserung des Arbeitsflusses mussten wir dieses Problem lösen, bevor weitere DevOps-Optimierungen einen echten Nutzen zeigen konnten.

Wichtige Herausforderungen beim Arbeitsfluss von der Entwicklung zur SQA

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

  1. Die Verzögerung beim Starten 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 wurde. Dies bestimmt sowohl, wann die Tests beginnen können, als auch, wie lange ihre Durchführung dauert. Das Beste, was die SQA in diesem Modell tun kann, ist, Testskripte im Voraus vorzubereiten und auf die Erfüllung der Definition of Done (DoD) durch das Entwicklungsteam zu warten, bevor die Tests ausgeführt werden.

Automatisierung der SQA: Ein Wandel in der Teststrategie

Der einzige Weg, diesen Ablauf zu verbessern, besteht in einem massiven Fokus auf Automatisierung. Dies betrifft jedoch nicht nur die Automatisierung der Testausführung, sondern erfordert einen grundlegenden Wandel in der Herangehensweise an das Testen. Dazu gehören:

  • Die Neudefinition und Neuausrichtung der Ziele der System-QA.
  • Die Neubewertung der Durchführung von Validierungen, um sowohl Geschwindigkeits- als auch regulatorische Anforderungen zu erfüllen.
  • Die Neugestaltung der Werkzeuge und Frameworks, die für eine effektive Unterstützung der Automatisierung erforderlich sind.

Einer der wichtigsten Mentalitätswechsel bestand darin, vom Testen zur Bestätigung, dass die entwickelte Software funktioniert → zum Testen als Leitfaden für die Entwicklung überzugehen.

Dies bedeutete, Testskripte zu erstellen, zu automatisieren und in einer Umgebung auszuführen, in der Entwicklungscode regelmäßig eingepflegt wird, noch bevor die Feature-DoD erreicht ist. Hier zeigen Testfehler keinen Mängel an, sondern bieten stattdessen frühzeitig Aufschluss darüber, welche Teile der Funktionalität noch nicht implementiert oder voll funktionsfähig sind.

Mit Continuous-Delivery-Pipelines und einer optimierten Branching-Strategie, bei der Feature-Branches häufig in den Main-Branch zusammengeführt und in der Cloud bereitgestellt werden, haben wir eine dedizierte Umgebung eingerichtet, in der diese automatisierten Systemtests kontinuierlich ausgeführt werden können.

Schnelleres Feedback durch automatisierte Tests

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

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

  • Abkehr von UI-basierter Automatisierung → API-Tests wurden zur Priorität.
  • Umstellung auf Behavior-Driven Development (BDD) → Erstellung von Testskripten parallel zu User Stories, damit diese in die Akzeptanzkriterien einfließen.

Zwar befindet sich die vollständige Einführung von BDD ab Beginn der User-Story-Erstellung noch in der Umsetzung, doch haben wir die Zusammenarbeit zwischen SQA- und Entwicklungsteams verbessert und beide Seiten frühzeitig im Prozess aufeinander abgestimmt.

Abstimmung von SQA und Entwicklung: Der Einfluss von Team Topologies

Um dies zu erreichen, haben wir den Ansatz spezialisierter Teams aus Team Topologies angewendet und das SQA-Team als unterstützendes Team eingerichtet. SQA-Teammitglieder agieren nicht mehr als separate, nachgelagerte Testinstanz, sondern arbeiten eng mit der Entwicklung zusammen, um sicherzustellen, daß die Erstellung von Automatisierungstests früh beginnt und kontinuierlich parallel zur Code-Entwicklung läuft.

Eine wichtige Voraussetzung für diesen Ansatz ist eine Cloud-based Testumgebung, in der Systemtests durchgeführt werden können, bevor es in kontrollierte Umgebungen geht. Dies ist zwar mit zusätzlichen Infrastrukturkosten verbunden, erhöht jedoch den Arbeitsfluss von der Entwicklung zur SQA erheblich, so dass die Bereitstellung viel schneller erfolgen kann.

Fazit

Diese Verbesserung unterstützt ein zentrales DevOps-Prinzip: Transformationen anzugehen, indem Werkzeuge, Architektur und menschliche Kompetenzen berücksichtigt und gleichzeitig der Arbeitsfluss optimiert wird. Durch die Automatisierung der System-QA, die frühere Integration von Tests in den Zyklus und eine effektivere Teamausrichtung haben wir den Engpass zwischen Entwicklung und Systemvalidierung deutlich verringert, die Feedback-Schleifen beschleunigt und Bereitstellungen reibungsloser gestaltet.

Abschluss der Reihe

Zum Abschluss unserer Serie DevOps for the Win blicken wir auf den Weg von Tool-Chaos und manuellen Prozessen hin zu einem vernetzten, automatisierten und handlungsfähigen Unternehmen zurück. Von der Definition unseres DevOps-Dreiecks in Kapitel 1 bis hin zum Aufbau eines feedbackbasierten Lernens in Kapitel 6 baute jedes Kapitel auf dem vorherigen auf, um einen sinnvollen Wandel voranzutreiben.

Hier ist eine kurze Zusammenfassung unserer Reihe:

Diese Transformation läuft kontinuierlich – aber mit dem Fundament, das wir geschaffen haben, sind wir besser denn je gerüstet, schneller, sicherer und smarter einen Mehrwert zu liefern.

Vielen Dank, dass Sie diesen Weg mit uns gegangen sind. Wir hoffen, unsere Geschichte inspiriert Sie bei Ihrer eigenen DevOps-Entwicklung.

Bleiben Sie neugierig. Arbeiten Sie iterativ. Und vor allem: Bleiben Sie vernetzt.

Freyr-Blog abonnieren