Automatisierung und Feedback: Schließen des DevOps-Kreislaufs
4 Minuten lesen

Unter Kapitel 5: Verzweigungen und kontinuierliches Deploymenthaben wir untersucht, wie kurzlebige Verzweigungen und eine zentralisierte Continuous Deployment (CD)-Plattform us geholfen haben, die Bereitstellung zu beschleunigen und die Reibung bei der Integration zu verringern. Diese Änderungen verbesserten den Codefluss in die Produktion dramatisch, aber um die DevOps-Feedback-Schleife wirklich zu vervollständigen, brauchten wir mehr.

Kapitel 6, der letzte Teil unserer Serie DevOps for the Win, befasst sich mit der letzten, aber entscheidenden Säule unserer Transformation: Automatisierung und Feedback. Wenn us die kontinuierliche Bereitstellung geholfen hat, schneller zu veröffentlichen, dann haben us Automatisierung und Feedback geholfen, schneller zu lernen und us mit Zuversicht kontinuierlich zu verbessern.

Warum Automatisierung und Feedback wichtig sind

Bei jeder DevOps-Umstellung ist Geschwindigkeit ohne Sicherheit ein Rezept für eine Katastrophe. Mit zunehmender Bereitstellungshäufigkeit wurde der Bedarf an automatisierten Prüfungen und Echtzeit-Feedback immer wichtiger - nicht nur für die Qualitätssicherung, sondern auch für die Befähigung des Teams und die Entscheidungsfindung.

Automatisierung und Rückmeldesysteme ermöglichen Teams:

  • Frühzeitige Erkennung von Problemen, bevor sie reach Produktion reach
  • Vertrauen in Veränderungen durch wiederholbare, zuverlässige Validierung
  • Aufschlussreiche Metriken zum Verständnis des Systemzustands und der Auswirkungen auf die Benutzer

Das ist der Unterschied zwischen einem Blindflug und einem Flug mit einem Armaturenbrett.

Nachdem wir die Entwicklungsgeschwindigkeit verbessert hatten, konzentrierten wir uns als Nächstes auf die Ermittlung von Engpässen in der Feedback-Schleife, sobald das Entwicklungsteam die Arbeit als "erledigt" markiert hatte. Hier war das wichtigste Maß für den Fluss, wie schnell die abgeschlossene Arbeit in die Produktion überführt werden konnte.

Die Vorlaufzeit für Änderungen und die Bereitstellungshäufigkeit sind wichtige Messgrößen dafür, wie effizient die Arbeit durch das System läuft. In unserem Fall stapelte sich die Arbeit in der Phase QA (SQA), was zu einem Engpass bei der Bereitschaft zur Bereitstellung führte.

Der Engpass bei QA

In den meisten Bereichen, so auch in unserem, schreiben die gesetzlichen Vorschriften eine Reihe von Validierungsaktivitäten vor, um die Softwarequalität zu gewährleisten. Dies beinhaltet:

  • Integrationsprüfung
  • Testen auf Systemebene
  • Nicht-funktionale Tests (z. B. Netzwerküberprüfung, Leistungstests)
  • Validierungsartefakte → Systemtestberichte, IQ (Installationsqualifizierung), OQ (Betriebsqualifizierung) und PQ (Leistungsqualifizierung)

Diese Aufgaben müssen in kontrollierten Umgebungen, getrennt von der Entwicklung, durchgeführt werden, um die Einhaltung der Vorschriften zu gewährleisten. Aus diesem Grund arbeitet das QA unabhängig, und die Tests können erst nach Abschluss der Arbeit des Entwicklungsteams beginnen.

Unsere Dashboards zeigten, dass die Zeit, die benötigt wurde, um abgeschlossene Arbeiten in den Status der Produktionsreife zu überführen, immer länger wurde und mehr Arbeiten darauf warteten, dass die SQA mit dem Testen begann. Nach unserem grundlegenden Ansatz zur Verbesserung des Arbeitsflusses war dies ein Problem, das wir angehen mussten, bevor weitere DevOps-Optimierungen einen echten Nutzen bringen konnten.

Die wichtigsten Herausforderungen im Fluss von der Entwicklung zur SQA

Bei der Verbesserung des Arbeitsflusses von der Entwicklung zur QA gab es zwei große Herausforderungen:

  1. Die Verzögerung beim Start der 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 eingesetzt wurde. Dies bestimmt, wann die Tests beginnen können und wie lange sie dauern. Das Beste, was die SQA in diesem Modell tun kann, ist, Testskripte im Voraus vorzubereiten und zu warten, bis das Entwicklungsteam die Definition of Done (DoD) erreicht hat, bevor es die Tests ausführt.

SQA automatisieren: Eine Verschiebung der Teststrategie

Die einzige Möglichkeit, diesen Fluss zu verbessern, besteht darin, sich massiv auf die Automatisierung zu konzentrieren. Dabei geht es jedoch nicht nur um die Automatisierung der Testdurchführung, sondern auch um eine grundlegende Veränderung der Art und Weise, wie das Testen angegangen wird. Dies beinhaltet:

  • Neudefinition und Neuausrichtung der Ziele der QA.
  • Neubewertung der Art und Weise, wie die Validierung durchgeführt wird, um sowohl die Geschwindigkeits- als auch die gesetzlichen Anforderungen zu erfüllen.
  • Neukonzipierung der Tools und Frameworks, die zur effektiven Unterstützung der Automatisierung erforderlich sind.

Eine der wichtigsten Veränderungen in der Denkweise war der Wechsel vom Testen zur Bestätigung, dass die entwickelte Software funktioniert → zum Testen als Leitfaden für die Entwicklung.

Dies bedeutete, dass Testskripte erstellt, automatisiert und in einer Umgebung ausgeführt werden mussten, in der der Entwicklungscode regelmäßig veröffentlicht wird, noch bevor der DoD erreicht ist. In diesem Fall deuten Testfehler nicht auf einen Defekt hin, sondern geben frühzeitig Aufschluss darüber, welche Teile der Funktionalität noch nicht implementiert oder voll funktionsfähig sind.

Mit kontinuierlichen Bereitstellungspipelines und einer verfeinerten Verzweigungsstrategie, bei der Funktionszweige häufig in den Hauptzweig zusammengeführt und in der Cloud bereitgestellt werden, richteten wir eine spezielle Umgebung ein, in der diese automatisierten Systemtests kontinuierlich ausgeführt werden konnten.

Schnelleres Feedback mit automatisierten Tests

Dank dieses Ansatzes konnte die QA früher mit der Validierung beginnen, was die Tests beschleunigte und dem Entwicklungsteam schnelleres Feedback lieferte. Anstatt zu warten, bis eine Funktion als fertig markiert ist, laufen die Tests jetzt parallel zur Entwicklung und geben den Teams in Echtzeit Aufschluss darüber, was funktioniert und was noch fertiggestellt werden muss.

Gleichzeitig erforderte die Automatisierung von Testfällen ein Umdenken bei den Teststrategien.

  • Abkehr von der UI-basierten Automatisierung → API-Tests wurden zur Priorität.
  • Umstellung auf verhaltensgesteuerte Entwicklung (BDD) → Erstellung von Testskripten zusammen mit User Stories, die in die Akzeptanzkriterien aufgenommen werden.

Auch wenn die vollständige Einführung von BDD ab dem Beginn der Erstellung der Benutzergeschichten noch nicht abgeschlossen ist, haben wir die Zusammenarbeit zwischen den SQA- und den Entwicklungsteams verbessert und sie schon früh im Prozess aufeinander abgestimmt.

SQA und Entwicklung aufeinander abstimmen: Der Einfluss von Team-Topologien

Um dies zu erreichen, wendeten wir den Ansatz der spezialisierten Teams von Team Topologies an, indem wir das SQA-Team als ein unterstützendes Team einrichteten. Anstatt eine separate, nachgelagerte Testfunktion zu sein, wurden die Mitglieder des SQA-Teams eng mit der Entwicklung abgestimmt, um sicherzustellen, dass die Erstellung von Automatisierungstests frühzeitig beginnt und kontinuierlich mit der Entwicklung des Codes einhergeht.

Eine wichtige Voraussetzung für diesen Ansatz ist eine cloud-based Testumgebung, in der Tests auf Systemebene durchgeführt werden, bevor sie in kontrollierte Umgebungen verlagert werden. Dies bringt zwar zusätzliche Infrastrukturkosten mit sich, erhöht aber den Arbeitsfluss von der Entwicklung zur SQA erheblich und macht sie viel schneller einsatzbereit.

Schlussfolgerung

Diese Verbesserung unterstreicht ein zentrales DevOps-Prinzip - die Transformation unter Berücksichtigung der Kompetenzen von Tools, Architektur und Mitarbeitern anzugehen und sich dabei auf den Ablauf zu konzentrieren. Durch die Automatisierung der QA, die Integration von Tests zu einem früheren Zeitpunkt im Zyklus und die effektivere Abstimmung der Teams konnten wir den Engpass zwischen Entwicklung und Systemvalidierung deutlich verringern, die Feedbackschleifen beschleunigen und die Bereitstellung reibungsloser gestalten.

Abschluss der Serie

Zum Abschluss unserer Reihe "DevOps for the Win" reflektieren wir über den Weg vom Tooling-Chaos und manuellen Prozessen hin zu einer stärker vernetzten, automatisierten und befähigten Organisation. Von der Definition unseres DevOps-Dreiecks in Kapitel 1 bis zur Einführung von Feedback-gesteuertem Lernen in Kapitel 6 baute jedes Kapitel auf dem letzten auf, um eine sinnvolle Transformation voranzutreiben.

Hier ist eine kurze Zusammenfassung unserer Serie:

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

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

Bleiben Sie neugierig. Bleiben Sie iterativ. Und vor allem: Bleiben Sie in Verbindung.

Freyr Blog abonnieren