Stage ist der Schritt im SAFe for DevOps Health Radar, in dem wir die finale Validierung vor dem Produktionsgang durchführen. In der Staging-Umgebung führen wir User Acceptance Tests durch, zeigen System Demos für unsere Stakeholder und verifizieren, dass alles wirklich produktionsbereit ist. In diesem Video erkläre ich, was der Stage-Schritt umfasst und warum er für eine zuverlässige Delivery Pipeline unverzichtbar ist.
Der Weg zum Stage#
Bevor wir zum Stage-Schritt gelangen, haben wir die gesamte vorgelagerte Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Diese Ideen werden in Epics mit einem klaren Hypothesis Statement überführt. Wir forschen gemeinsam, um Kundenbedürfnisse zu identifizieren und Marktforschung durchzuführen. Wir entwerfen die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen. Dann synthetisieren wir, indem wir das Epic in Features herunterbrechen, die wir auf eine Roadmap und in unser Backlog aufnehmen.
Von dort aus entwickeln wir User Stories, committen Quellcode, reintegrieren unsere Änderungen, bauen ein deploybare Artefakt und führen statische Codeanalyse sowie Unit Tests aus. Das deploybare Artefakt wird dann in eine Testumgebung deployed, wo wir Integrationstests und End-to-End-Tests durchführen. Danach sind wir bereit für die Staging-Umgebung.
Was passiert im Stage#
In der Staging-Umgebung führen wir die finale Validierung durch, um festzustellen, ob wir produktionsbereit sind. Die zentrale Aktivität ist das User Acceptance Testing (UAT). Dies ist die Gelegenheit für das Business, das Ergebnis zu prüfen und zu bestätigen, dass es ihren Erwartungen entspricht.
Eine Staging-Umgebung ist per Definition eine Eins-zu-eins-Kopie der Produktionsumgebung. Während wir bereits im Test-Schritt besprochen haben, dass Testumgebungen so nah wie möglich an der Produktion sein sollten, brauchen wir im Stage wirklich diese Übereinstimmung. Nur mit einer produktionsgleichen Umgebung können wir zuverlässig End-to-End-Tests und User Acceptance Testing durchführen.
Blue-Green Deployments#
Um Stakeholdern kontinuierliches Testen in einer Staging-Umgebung zu ermöglichen, können wir Blue-Green Deployments einsetzen. Dieser Ansatz verwendet zwei produktionsgleiche Umgebungen. Eine Umgebung ist live, die andere ist idle. Vor beiden Umgebungen sitzt ein Load Balancer, der zwischen ihnen wechseln kann.
Wenn wir eine neue Version unserer Software haben, deployen wir sie in die idle Umgebung. Sobald das Deployment abgeschlossen ist, schalten wir den Load Balancer auf die neue Umgebung um. Alle Nutzer arbeiten dann mit der neuen Version auf der nun aktiven Umgebung. Die andere Umgebung wird idle und steht für das nächste Deployment bereit.
Der grosse Vorteil dieses Ansatzes ist zweifach. Erstens: Wenn es ein Problem mit der neuen Version gibt, können wir es in der idle Umgebung untersuchen, ohne die Nutzer der aktiven Umgebung zu beeinträchtigen. Zweitens: Wenn wir nach dem Umschalten ein Problem entdecken, können wir schnell zur vorherigen Version zurückwechseln.
System Demos#
Die Staging-Umgebung ist auch der Ort, an dem wir System Demos durchführen. Alle zwei Wochen integrieren wir mit dem Rest der Software und zeigen unseren Stakeholdern, was wir während des Sprints erreicht haben. Stakeholder können uns Feedback geben und entscheiden, ob das Ergebnis bereit für die Produktion ist oder Nacharbeit benötigt.
Diese regelmässige Feedbackschleife ist eine Kernpraktik in SAFe und stellt sicher, dass das Entwicklungsteam mit den Geschäftserwartungen im Einklang bleibt.
Das Ergebnis des Stage-Schritts#
Das Ergebnis des Stage-Schritts umfasst drei Dinge:
- Ein produktionsbereites Artefakt. Das deploybare Artefakt wurde validiert und ist bereit für das Produktions-Deployment.
- Testnachweis. Dies ist besonders wichtig, wenn Regulierungen dokumentierte Testnachweise erfordern.
- Stakeholder-Feedback. Gesammelt durch die System Demo und das User Acceptance Testing in der Staging-Umgebung.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Stage-Schritt:
- Sit: Keine Staging-Umgebung vorhanden, oder eine Testumgebung wird für das Staging verwendet.
- Crawl: Features werden manuell einmal pro PI oder alle drei Monate in eine Staging-Umgebung deployed.
- Walk: Features werden einmal pro Monat in eine Staging-Umgebung deployed und dem Product Management demonstriert.
- Run: Features und Infrastruktur werden automatisch jede Iteration oder jeden Sprint in eine Staging-Umgebung deployed und vom Product Management akzeptiert.
- Fly: Stories, Änderungen und Infrastruktur werden automatisch in eine Staging-Umgebung deployed, validiert und gehen sofort weiter zum Deployment.
Kernaussagen#
- Stage ist das finale Validierungstor. Es stellt sicher, dass alles produktionsbereit ist, bevor die Software in die Produktion geht.
- Die Staging-Umgebung muss der Produktion entsprechen. Sie ist eine Eins-zu-eins-Kopie der Produktionsumgebung, nicht nur eine Annäherung.
- User Acceptance Testing ist die zentrale Aktivität. Das Business validiert, dass die Software ihren Erwartungen entspricht.
- Blue-Green Deployments ermöglichen kontinuierliches Testen. Zwei produktionsgleiche Umgebungen mit einem Load Balancer erlauben nahtloses Umschalten und schnelle Rollbacks.
- System Demos liefern Stakeholder-Feedback. Jeden Sprint prüfen Stakeholder den Fortschritt und geben ihre Freigabe oder fordern Nacharbeit an.
- So viel wie möglich automatisieren. Im besten Fall sind das Deployment auf Stage, automatisierte Tests und die Übernahme in die Produktion vollständig automatisiert.