Table of Content
Agile Frameworks haben die Softwarebereitstellung drastisch verändert. Heutzutage setzen immer mehr Unternehmen klar definierte Frameworks wie Scrum oder Kanban ein. Die Kunden erwarten daher, dass neue Funktionen schneller und ohne Einbußen bei Qualität und Sicherheit zur Verfügung stehen. Eine Release-Pipeline beinhaltet die Implementierung von Continuous Integration- und Continuous Delivery-Verfahren. Da die Stakeholder Funktionen zunehmend schneller, häufiger und kontrollierter benötigen, ist die Risikobewertung einer Pipeline heute ein „Muss“ in Technologieunternehmen.
Release-Pipeline-Szenario
Um die Bedeutung der Risikobewertung zu verstehen, lassen Sie uns ein realistisches Szenario betrachten. Stellen Sie sich eine Funktion für einen Webshop-Finder vor, die von einem Entwicklungsteam entwickelt, auf dem QS-Server getestet und sogar vom Auftraggeber im User Acceptance Testing (UAT) getestet wurde.
| Warum ist UAT-Testing wichtig? |
Da alle Testphasen gut verlaufen waren, erhielt das Team grünes Licht für das Deployment. Aber dann wurde während der von der Qualitätssicherung durchgeführten Smoketests festgestellt, dass der Finder nicht richtig funktionierte. Der Server gab beim Senden des Formulars einen HTTP 500-Fehler zurück. Als die technische Leitung dann versuchte, das Deployment zurückzurollen, versagte die Pipeline für das Zurückrollen und lieferte Fehler beim Versuch, das letzte releaste Code-Tag zu erstellen.
Ein Entwicklungsteam war beauftragt worden, auf der Hauptseite einer Website, die Kampagnen für Prepaid-Handys unterstützte, einen Shop-Finder zu bauen. Grundsätzlich wünschte sich der Kunde, dass die Nutzer ihren nächstgelegenen Laden leicht finden und neue Geräte kaufen können. Die Anforderung bestand aus einer Datenbankverbindung, etwas Backend-Code und natürlich Frontend-Code. Das Team entschied sich, für jede Umgebung eine andere Datenbank zu haben. Wie gesagt, nach dem Build wurden die Tests durchgeführt, und alle Parteien gaben ihr „Go“.
Nachdem der Release-Branch erstellt und nach Master integriert wurde, erfolgte am nächsten Tag um 13.00 Uhr das Deployment in die Produktion durch den technischen Leiter. Hier tauchten die Probleme mit dem Finder und der Rollback-Pipeline während der Smoketests auf.
Selbstverständlich waren alle in Panik, und der Auftraggeber war nicht begeistert. Das Endergebnis dieses unglücklichen Szenarios war, dass das Team den Master-Branch „hart“ zurücksetzen und ein weiteres Deployment durchführen musste, damit die Anwendung wieder normal lief. Alles in allem war das Problem für die Endanwender 30 Minuten lang wahrnehmbar.
| 8 KPIs für stressfreies Testen |
Release-Pipeline-Risikoanalyse
This block renders a quote for the post drawn from the post's custom fields. Modify the quote below the content editor in the Quote fields.
Builds ohne Tests
Alle Branches müssen durch Continuous Integration validiert werden. Eine Pipeline ohne Continuous Integration ist keine wirkliche Release-Pipeline. Qualitätssicherung und Entwickler sollten immer zusammenarbeiten, um sicherzustellen, dass jedes Artefakt korrekt getestet wird, sei es durch automatisierte oder manuelle Überprüfungen.
Komplexe Pipelines
Komplexe Konfigurationen sind schwieriger zu pflegen. DevOps-Teams sollten das KISS-Prinzip so weit wie möglich anwenden, damit jedes Teammitglied leicht verstehen kann, wie der gesamte Prozess funktioniert, und sich gegenseitig vertreten kann, wenn Mitglieder im Urlaub sind, krank, etc. Mit nur einer Person, die die Pipeline kennt, ist das Projekt viel weniger zuverlässig, da es zu sehr von dieser Person abhängig ist.
Nicht in einer Pre-Produktionsumgebung testen
Von Entwicklern vorgenommene Änderungen sollten niemals produktiv gesetzt werden, ohne vorher in eine Pre-Produktionsumgebung zu gehen. Diese Umgebung hat in der Regel die gleiche Konfiguration wie in der Produktion, so dass sich das Entwicklungsteam und die Auftraggeber ein Bild davon machen können, wie die Funktion funktionieren wird, sobald sie in die Produktion geht. DevOps sollte sicherstellen, dass es immer sowohl eine Staging- als auch eine UAT-Umgebung gibt. Es ist äußerst wichtig, dass Auftraggeber die Funktionen vor dem Produktivstart überprüfen, damit sie verifizieren können, ob die entwickelten Funktionen auf die geschäftlichen Anforderungen abgestimmt sind.
Verwendung der falschen Tools
Architekten und DevOps sollten immer Pipeline-Technologien verwenden, die näher am Software-Stack liegen. Wenn ein Produkt auf einem Linux-Server installiert ist, sollte natürlich keine Windows BAT-Datei in der Konfiguration verwendet werden. Um dieses Risiko zu minimieren, müssen Release-Manager, IT-Manager und Architekten ein Projekt vollständig verstehen und die Tools auswählen, die am besten zu ihm passen.
Menschliches Eingreifen
IT-Manager sollten sich auf die Automatisierung ihrer Release-Pipelines konzentrieren. Je mehr Sie menschliche Eingriffe vermeiden, desto vorhersehbarer werden die Releases sein. Hier ist DevOps-Disziplin entscheidend. Es geht darum, Pipelines mit Qualität, Belastbarkeit und Schnelligkeit zu erstellen.
| Panaya Release Dynamix |
Fehlender Konsens
Governance-Richtlinien definieren normalerweise die Art und Weise, wie ein Team neue Funktionen bereitstellen sollte: Wann wäre der beste Zeitpunkt für das Deployment, wer ist für das Deployment verantwortlich usw. Heutzutage ist es sehr merkwürdig, wenn nur eine Person für die Auslösung des Deployments zuständig ist, aber es kann vorkommen, dass ein Teammitglied die Pipeline auf eigene Faust startet. Dies ist sehr gefährlich, da die Kapazität einer Person möglicherweise nicht ausreicht, um im Falle eines Fehlschlags ein Rollback durchzuführen. Um ein solches Risiko zu minimieren, sollten die Teammitglieder geschult werden, die richtigen Berechtigungen müssen in der Konfiguration der Pipeline festgelegt werden und, was am wichtigsten ist, die Manager müssen eine korrekte Kommunikation innerhalb des Teams erreichen.
Release des falschen Builds
Die Teams müssen sich der Branch- und Versionierungsstrategien bewusst sein, um die Pipeline korrekt zu konfigurieren. Stellen Sie sich vor, Sie haben einen Build deployt, der einen Bug behoben haben sollte, und der Auftraggeber erkennt dann, dass der Bug noch immer im Produktivbetrieb ist. Entwickler müssen sicherstellen, dass sich alle an die Vereinbarungen halten und die Richtigkeit der Pipeline regelmäßig überprüfen. Richtlinien in der Governance-Dokumentation können helfen, dieses Szenario zu vermeiden.
Einbinden von experimentellen Funktionen
Aufgrund mangelnder Wachsamkeit und einer schwachen Pipelinekonfiguration können neue experimentelle Funktionen in die Produktion gelangen, die die Vorhaben eines Auftraggebers enthüllen und damit möglicherweise auch zu finanziellen Verlusten für ihn führen. Manager und Entwickler müssen die Konfigurations- und Versionierungsstrategie der Pipeline kennen, damit sie wissen, welche Branches deployt werden sollen und welche nicht. Eine weitere Strategie besteht darin, die Branches, in denen Entwickler arbeiten können, einzuschränken, so dass z. B. nur der Master-Branch in die Produktivumgebung deployt werden kann.
Ausfallzeiten
In welchem Zustand sollte die Anwendung sein, während ein neuer Build deployt wird? Wird der Auftraggeber zufrieden sein, wenn die Anwendung ausfällt, während das Release-Team ein neues Deployment auslöst? Offensichtlich ist die Antwort auf diese zweite Frage ein klares „Nein“. Die Entwicklungs- und DevOps-Teams müssen eine Strategie verfolgen, um dafür zu sorgen, dass die Anwendung nicht ausfällt. Und dies sollte auch in der Governance-Dokumentation definiert werden.
Überstürzte Delivery
Ein Team kann leicht unter immensen Druck geraten, eine Funktion oder eine Fehlerbehebung schnell zu releasen. Dies bedeutet, dass jedes Mitglied anfälliger für Fehler ist. Überstürzt auszuliefern ist immer riskant, aber heute im Business eine Realität. Deshalb brauchen Teams eine Checkliste für das Release von neuem Code, um es sicher durchzuführen und menschliches Versagen zu vermeiden.
Langwierige Rollbacks
Wenn eine Funktion mit einem Bug releast wird, muss sie so schnell wie möglich aus der Produktion entfernt werden. Je länger der Bug in der Produktion lebt, desto mehr Kunden verlieren das Vertrauen in das Unternehmen. Release-Manager sollten immer darauf drängen, die Rollback-Prozeduren und ihre Performance zu testen, um sie so schnell und reibungslos wie möglich zu gestalten.
Späte Lockdowns
Sobald die Pipeline validiert ist, sollte nicht mehr jeder in der Lage sein, sie zu modifizieren. Es müssen eingeschränkte Zugriffsrechte eingerichtet werden, sobald eine Pipeline funktioniert, und DevOps muss die Zugriffsrechte regelmäßig überprüfen und testen.
Risiken erfolgreich erkennen und bewältigen
Software-Releases haben sich in Richtung agiler Frameworks entwickelt. Und doch bringt diese Evolution neue Risiken mit sich. Aber wie können Unternehmen die mit einem Pipeline-Release verbundenen Risiken richtig analysieren, verwalten, mindern und beseitigen? Teams, die einen durchgängigen Entwicklungs- und Bereitstellungsprozess betreiben, benötigen heute ein Drittanbieter-Tool, um Risiken frühzeitig zu erkennen und während der gesamten Pipeline zu managen. Sie benötigen die Fähigkeit, die Auswirkungen neuer Funktionen und Änderungen an der Software auf die Geschäftsprozesse ihres Unternehmens zu analysieren, um aufzuzeigen, wo Risiken bestehen, und gleichzeitig instabilen Code zu eliminieren sowie viele der oben beschriebenen Risiken zu beseitigen.
Drittanbieter-Tools, wie Panayas Release Dynamix [RDx] bieten die Mittel zur Bewertung, Erkennung und Bewältigung von Risiken. Damit sorgen sie für eine stabile, risikofreie Release-Pipeline und einen erfolgreichen Deployment-Prozess. Dazu gehört auch die Visualisierung des Umfangs von Releases über mehrere Projektwellen hinweg, einschließlich wertvoller Impact-Analysen und Überprüfungsdaten zur Codequalität, die RDx zudem zur automatischen Erstellung von Testplänen verwendet. Das risikobasierte Testen von RDx ist ein leistungsstarkes Instrument, um die erkannten Risiken zu adressieren und sicherzustellen, dass diese Risiken durch Tests abgedeckt sind. Darüber hinaus stellt RDx risikorelevante Daten für alle Beteiligten übersichtlich dar, einschließlich aktueller Risikostufen, Entwicklungsstatus, Codequalität, Testplanung und -durchführung, Fehlerbehebung und allgemeiner Anforderungserfüllung.
Die Implementierung von Continuous Integration und Continuous Delivery Verfahren in Release-Pipelines kann eine Herausforderung sein. Aber mit den richtigen Tools können Unternehmen schnelle, sichere und qualitativ hochwertige Pipelines erreichen, die sie benötigen, um erfolgreich zu sein.