Verify ist ein entscheidender Schritt im SAFe for DevOps Health Radar. Nachdem wir unser Paket in die Produktionsumgebung deployed haben, müssen wir sicherstellen, dass die neue Funktionalität korrekt funktioniert und die Integrität und Robustheit des bestehenden Systems nicht beeinträchtigt. Erst nach dieser Verifikation können wir die neuen Features bedenkenlos für die Endbenutzer freigeben. In diesem Video erkläre ich, was der Verify-Schritt umfasst und wie er sich in die gesamte Continuous Delivery Pipeline einfügt.
Wo Verify in der Pipeline steht#
Bevor wir den Verify-Schritt erreichen, haben wir Continuous Exploration und Continuous Integration durchlaufen. Wir haben gute Ideen vom Kunden und Business in Hypothesenaussagen umgewandelt, gemeinsam geforscht, die Lösung architekturiert und Epics in Features und User Stories heruntergebrochen. Der Code wurde gebaut, getestet und in ein deploybare Artefakt verpackt. Dieses Artefakt wurde zuerst in eine Staging-Umgebung und dann in die Produktionsumgebung deployed.
Jetzt, da der Code in der Produktion mit dem Feature Toggle ausgeschaltet liegt, ist es an der Zeit zu verifizieren, dass alles wie erwartet funktioniert, bevor wir den Feature Toggle einschalten und die Funktionalität für die Nutzer freigeben.
Trennung von Deployment und Release#
Einer der Grundpfeiler von DevOps ist die Trennung von Deployment und Release. Deployment ist das Einbringen des kompilierten Codes in die Produktion mit dem Feature Toggle ausgeschaltet. Release ist das Einschalten des Feature Toggles, damit die neue Funktionalität von den Endbenutzern genutzt werden kann.
Diese Trennung macht den Verify-Schritt erst möglich. Da der Code in der Produktion liegt, aber noch nicht für die Nutzer sichtbar ist, haben wir die Möglichkeit, ihn gründlich in der echten Produktionsumgebung zu testen, ohne ein Risiko für die Endbenutzer einzugehen.
Production Testing#
Die Kernaktivität im Verify-Schritt ist das Production Testing. Wir führen Tests, die wir bereits in niedrigeren Umgebungen ausgeführt haben, erneut in der Produktionsumgebung aus. Dies geschieht durch die Simulation von Endbenutzerverhalten mit synthetischen Transaktionen. Diese synthetischen Transaktionen ermöglichen es uns, zwei Dinge zu verifizieren:
- Die bestehende Funktionalität verhält sich weiterhin wie erwartet.
- Die neue Funktionalität tut, was sie soll, und ist bereit für das Release.
Dieser Ansatz gibt uns die Sicherheit, dass das Deployment keine Regressionen verursacht hat und die neuen Features in der echten Produktionsumgebung korrekt funktionieren.
Build-, Test- und Deployment-Automatisierung#
Um das neue Paket in der Produktion zu verifizieren, benötigen wir eine solide Build-, Test- und Deployment-Automatisierung. Mit dieser Automatisierung können wir bei jedem Commit einen Build auslösen, alle Unit Tests ausführen, Codeanalyse und Security-Checks durchführen und das Paket automatisch in Staging- und Produktionsumgebungen deployen.
Wichtig ist hier die schnelle Feedback-Schleife. Entwickler müssen schnell erfahren, ob ihre Änderungen alle Verifikationsprüfungen bestehen. Je schneller dieses Feedback, desto schneller können Probleme behoben werden.
Testdatenmanagement#
Gutes Testdatenmanagement ist entscheidend für den Verify-Schritt. Wir benötigen einen gut gepflegten Satz synthetischer Testdaten, damit wir unsere Tests zuverlässig ausführen können. Diese Testdaten müssen in der Versionskontrolle gespeichert sein.
Was wir nicht tun wollen, ist Produktionsdaten oder eine anonymisierte Produktionsdatenbank für Tests zu verwenden. Produktionsdaten ändern sich ständig, und diese Änderungen führen zu flaky Tests. Ein flaky Test hat null Wert, weil er das Vertrauen in die Testsuite untergräbt und es unmöglich macht, echte Fehler von Rauschen zu unterscheiden.
Nicht-funktionale Anforderungen#
Bei der Verifikation der Funktionalität in der Produktion müssen wir auch die nicht-funktionalen Anforderungen verifizieren. Das sind Systemeigenschaften wie Sicherheit, Zuverlässigkeit, Performance, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Nicht-funktionale Anforderungen sind eine Randbedingung für das gesamte Backlog. Das bedeutet, dass jede User Story, jedes Feature und jedes Epic diesen Anforderungen entsprechen muss.
Wir verifizieren die nicht-funktionalen Anforderungen zuerst in der Staging-Umgebung, müssen aber auch bestätigen, dass sie in der Produktionsumgebung erfüllt werden. Die Produktionsumgebung kann andere Eigenschaften als Staging aufweisen, weshalb diese Verifikation unerlässlich ist.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Verify-Schritt:
- Sit: Deployments werden in der Produktion nicht verifiziert, bevor sie für Endbenutzer freigegeben werden.
- Crawl: Deployments werden mit manuellen Smoke Tests und User Acceptance Testing (UAT) verifiziert. Deployment-Probleme werden innerhalb eines definierten Triage-Zeitraums behandelt. Probleme werden häufig direkt in der Produktion behoben.
- Walk: Deployments werden vor der Freigabe für Endbenutzer mit manuellen Tests verifiziert. Rollbacks sind schmerzhaft oder unmöglich. Änderungen werden nicht direkt in der Produktion vorgenommen.
- Run: Deployments werden mit automatisierten Production Tests verifiziert. Rollbacks sind schmerzhaft oder unmöglich. Änderungen werden nicht direkt in der Produktion vorgenommen.
- Fly: Automatisierte Production Tests laufen kontinuierlich und speisen Monitoring-Systeme. Fehlgeschlagene Deployments können sofort zurückgerollt oder durch die gesamte Pipeline vorwärts behoben werden.
Kernaussagen#
- Vor dem Release verifizieren. Nach dem Deployment in die Produktion die neue und bestehende Funktionalität testen, bevor der Feature Toggle für Endbenutzer eingeschaltet wird.
- Synthetische Transaktionen verwenden. Endbenutzerverhalten in der Produktion simulieren, um zu bestätigen, dass alles wie erwartet funktioniert, ohne echte Nutzer zu beeinflussen.
- Gute Testdaten pflegen. Synthetische Testdaten in der Versionskontrolle verwenden. Niemals auf Produktionsdaten für Tests zurückgreifen, da sie zu flaky Tests führen.
- Nicht-funktionale Anforderungen verifizieren. Sicherheit, Performance, Zuverlässigkeit und andere Systemeigenschaften müssen in der Produktionsumgebung geprüft werden, nicht nur im Staging.
- Die Verifikation automatisieren. Build-, Test- und Deployment-Automatisierung ist essenziell für schnelles Feedback und zuverlässige Production-Verifikation.
- Deployment von Release trennen. Diese Trennung ist die Grundvoraussetzung für eine sichere Verifikation in der Produktion.