Der Weg zur progressiven Auslieferung

Die schnelle und effiziente Bereitstellung eines Softwaresystems für die Kunden ist von entscheidender Bedeutung, wenn ein Unternehmen eine unauslöschliche Präsenz auf dem Markt etablieren will. Ein kontinuierlicher Bereitstellungsprozess ohne Unterbrechungen macht den Unterschied. Die Unternehmen, die eine Spitzenposition in der Rangliste der verteilten Systeme einnehmen, führen Tausende von Bereitstellungen an einem Tag durch, ohne dass es zu Ausfällen kommt. Netflix und Expedia sind zwei solche Elite-Performer auf dem Markt. 

Was bringt die wenigen Unternehmen dazu, im Spiel voranzukommen? Zweifellos unterscheidet sich der Prozess der kontinuierlichen Bereitstellung von Organisation zu Organisation. Die besseren Performer befolgen eine Reihe von Praktiken, um ihren Continuous-Delivery-Zyklus (CD) intakt zu halten. Welche Experimente können mit den CD-Prozessen durchgeführt werden, um den maximalen Output zu erzielen? 

James Governor, der Gründer von RedMonk, brachte auf der QCon London (2019) einen neuen Begriff namens Progressive Delivery ein, der die Stärke und Flexibilität eines Systems durch zahlreiche kreative Experimente gewährleistet. 

Lassen Sie uns tiefer eintauchen und erforschen, woher der Begriff Progressive Delivery stammt, was er bedeutet und wie Sie ihn in Ihrem Unternehmen einführen können. Aber zuerst die Geschichte.

Progressive Delivery gewährleistet die Stärke und Flexibilität eines Systems durch zahlreiche kreative Experimente

Evolution der progressiven Bereitstellung

Es gab eine Entwicklung von der Wasserfall-Methode zur progressiven Bereitstellung. Werfen wir einen Blick darauf, wie eine Reihe von Ereignissen den Weg für die progressive Bereitstellung geebnet hat.

Hintergrund

Der Softwareentwicklungsprozess hat sich zusammen mit der Entwicklung der Programmiersprachen entwickelt. Diese Veränderungen vollzogen sich schrittweise mit den Veränderungen, die in der Softwarebereitstellungsmechanik stattfanden. Früher wurden physische Hardwaregeräte, wie z. B. Compact Discs (CDs), gekauft, um neue Software in die Hände zu bekommen. Um diesem Bereitstellungsmodell Rechnung zu tragen, wurde die Softwareentwicklung so konzipiert, dass sie lange Zyklen berücksichtigt, die auf die Hardware-Designs, die Fertigung und die Validierungsintervalle abgestimmt sind. Das Wasserfallmodell begleitete diesen stufenweisen Prozess sehr gut.

Darüber hinaus führte die Entkopplung der Software von der Hardware zu einer umfassenden Verlagerung des Denkens über die Softwarebereitstellung, um die besten Softwarelösungen anzubieten. Diese Überlegung führt zu der Erkenntnis, dass sich Entwicklungszyklen schneller bewegen können als Hardwarezyklen. Diese Philosophie wurde in das Wasserfall-Bereitstellungsmodell integriert, um durch Betatests in der Validierungsphase Feedback zu erhalten. Das grundlegende Ziel war es, den Kundennutzen zu erhöhen. Dies schränkte jedoch die Änderungen ein, da der Zyklus erst mit der Validierungsphase begann.

Die Einführung von Agile 

Das Feedback und die Einbeziehung von Änderungen führten zu der grundlegendsten Prämisse der Agile- und Scrum-Bereitstellungsmodelle. Beide Modelle basierten auf der Idee, eine Reihe von Aktionen oder Plänen zu haben und diese dann in kleine, veränderbare Aufgaben oder Stories zu unterteilen, um das vorgeschlagene Ziel zu erreichen. Die geringfügigen Korrekturen während der Entwicklung einer kompletten Software waren der Vorteil, den das agile und Scrum-Bereitstellungsmodell mit sich brachte. In der Zwischenzeit wurde eine der beiden Optionen vom Wasserfallmodell gewählt: Entweder man bleibt beim Plan und wartet auf den nächsten Zyklus oder man gibt Arbeiten auf, die nicht mehr relevant sind.

Auch die Industrie begann sich zu entwickeln, und die Softwarebereitstellungsmodelle verlagerten sich von verpackter Software zu Software as a Service (SaaS). Die Verlagerung der Anwendung in die Cloud veränderte die Dynamik der Softwarebereitstellung. 

Meistens wurde die physische Bereitstellung eingestellt, was die Machbarkeit der Software erhöhte und Updates jederzeit und überall vorgenommen werden konnten. Die Bereitstellung der Updates durch die Entwicklungsteams und deren sofortiger Konsum durch die Verbraucher rationalisierten das Continuous-Delivery-Modell. Sofortige Updates bedeuten jedoch auch sofortige Sicherheitsrisiken. Darüber hinaus dauerte das Finden von Fehlern immer länger als das Beheben von Fehlern.

‘Flag’ the Code

Die Migration zu einem Continuous-Delivery-Modell erforderte eine Infrastruktur, die das Risiko der Auslieferung von gefährlichem Code reduzieren konnte. ‘Feature Flagging’ kam zu Hilfe, indem es die Code-Bereitstellung von der eigentlichen Feature-Freigabe trennte. 

Dann kam es zu einer großen architektonischen Veränderung in der Industrie. Das Aufkommen von Microservices mit global verteilten Apps und Data Science hielt Einzug in den Application-Delivery-Prozess. Diese veränderten die Art und Weise, wie die Teams Software ausliefern, erneut. Die Änderungen oder Aktualisierungen wurden zunächst an den jeweiligen Personenkreis verteilt und deren Auswirkungen beobachtet. Vor der Einführung der Aktualisierungen oder Änderungen waren einige Überlegungen oder Änderungen erforderlich. In jedem Fall begannen die Entwicklungs- und Betriebsteams, sich bei den Data-Science-Teams zu erkundigen, wie diese teilweisen Rollouts aufgenommen und angenommen wurden.

Der Bereich des Explosionsradius

Progressive Delivery wurde mit der Vorstellung konzipiert, dass die Freigabe von Features oder Updates so gesteuert wird, dass sie die Auswirkungen von Änderungen steuert. Nehmen wir an, die neue Code-Freigabe ist das Epizentrum. Jede neue Abteilung, die exponiert wird, stellt den zunehmenden Explosionsradius dar, der sich von diesem anfänglichen Einschlag aus ausbreitet.

Es ist ein System erforderlich, um die Trennung der Code-Bereitstellung von den Feature-Releases zu verwalten und die Freigabe wie ein Ventil oder ein Tor zu steuern, das langsam geöffnet und geschlossen werden kann. Darüber hinaus werden Kontrollpunkte benötigt, um die Feedback-Daten (Ereignisse) darüber zu erhalten, wie verschiedene Funktionen aufgerufen und genutzt werden. Progressive Delivery hat sich als ein kultivierter Ansatz für die Teams herauskristallisiert, die die Continuous-Delivery-Pipeline verfolgen. Sie führte sie dazu, die Vorteile von Kosten, Tools und Continuous-Delivery-Mechanismen zu nutzen. 

Was ist Progressive Delivery?

Progressive Delivery ist die Technik, Änderungen zuerst an kleine, risikoarme Zielgruppen auszuliefern und sie dann auf größere und risikoreichere Zielgruppen auszuweiten. Zum Beispiel werden die Änderungen zuerst an 1 % der Benutzer ausgerollt und dann schrittweise an mehr Benutzer (z. B. 5 % oder 7 %) freigegeben, bevor die vollständige Auslieferung erfolgt.

Umgebungen und Benutzer sind die beiden entsprechenden Faktoren der progressiven Bereitstellung. Im Falle von Umgebungen kann ein Benutzer progressiv in Umgebungen bereitstellen, indem er Canary Builds oder Blue-Green-Deployments verwendet, um die Exposition zu begrenzen, wenn neuer Code bereitgestellt wird. Wenn dies für die Benutzer erfolgt, begrenzt die progressive Bereitstellung die Exposition der Änderungen für die Benutzer. 

In jeder Phase einer progressiven Bereitstellung werden die Metriken verwaltet und der Zustand der Anwendung gemessen. Wenn etwas schief geht, wird die Anwendung automatisch in ihren vorherigen stabilen Zustand zurückversetzt.

Elemente der progressiven Bereitstellung

James Governor schlug die vier Bausteine der progressiven Bereitstellung vor:

• Benutzersegmentierung
• Traffic-Management
• Observability
• Automatisierung

Vorteile der progressiven Bereitstellung

IT-Experten, die den Weg der progressiven Bereitstellung wählen, profitieren von den folgenden wesentlichen Vorteilen. 

• Die Möglichkeit, die Qualität der Funktionen zu kontrollieren, während sie verteilt werden.
   
• Die Fähigkeit, für Ausfälle oder Probleme zu planen, da nur eine kleine Anzahl von Benutzern betroffen ist, wenn die Funktionen nicht korrekt funktionieren.
   
• Sie erleichtert das Sammeln von Feedback von einer Gruppe von erfahrenen Benutzern, um die Änderungen zu überarbeiten, bevor sie an den Kunden verteilt werden. 
   
• Progressive Delivery ermöglicht es den Entwicklungsteams, dem Entwicklungsprozess mehr Wert zu verleihen und weniger Zeit mit dem Management der Risiken zu verbringen.
   
• Die Non-Engineering-Teams, wie z. B. Marketing oder Vertrieb, können die Funktionen für die Benutzer auf der Grundlage separater Business-Timelines freigeben.

Schwachstellen der progressiven Bereitstellung

Um den Prozess der progressiven Bereitstellung nahtlos zu gestalten, sollten Sie immer ein Auge auf die unten genannten Punkte haben. Diese werden als Googles goldene Signale bezeichnet.

• Latenz: Die Zeit, die eine Anwendung benötigt, um eine Anfrage zu bearbeiten.
   
• Traffic: Er kann durch die Überwachung der HTTP-Anfragen pro Sekunde berechnet werden.
   
• Fehler: Die Rate der fehlgeschlagenen Anfragen, die von einer Anwendung oder einer Funktion gestellt werden. 
   
• Sättigung: Der Zustand, in dem ein System seine volle Auslastung erreicht, d. h. die Messung der Last in der Anwendung oder dem System. 

Ansätze zur Einführung von Progressive Delivery in einen Anwendungsentwicklungsprozess

Die progressive Bereitstellung kann nicht als Hau-Ruck-Aktion durchgeführt werden. Es wird eine Reihe von Praktiken befolgt, um eine progressive Bereitstellung in einer Anwendungsentwicklungsumgebung zu erreichen. Nachfolgend finden Sie eine Liste solcher Methoden: 

• Canary Testing: Wenn eine Änderung für eine kleine Anzahl von Benutzern freigegeben wird, ist ein kleiner Prozentsatz der Benutzer betroffen, wenn ein Fehler freigegeben wird. Canary-Tests sind die minimalen Tests, die die schnelle Überprüfung der Dinge durchführen, um zu wissen, ob alles, wovon ein Benutzer abhängig ist, bereit ist oder nicht. 
   
• Blue-Green Deployments: Bei der Blue-Green-Bereitstellung wird der neue Dienst oder ein Update in einer (blauen) Produktionsumgebung ausgerollt und dann in die andere (grüne) verschoben.  Dies reduziert die Ausfallzeiten und das Risiko, indem die beiden identischen Produktionsumgebungen betrieben werden. Aber zu einem Zeitpunkt ist nur eine der beiden Umgebungen live. Die Live-Umgebung bedient den Produktions-Traffic und ermöglicht es dem Benutzer, die Dinge in der Produktion zu testen, indem er schnell auf die andere zurückgreift, wenn etwas in der Live-Umgebung schief geht. 

• A/B Testing: A/B-Tests ermöglichen das Testen von Variablen an zwei verschiedenen Datengruppen auf der Benutzeroberfläche und zeigen dann, welche besser abschneidet. Dies ist effizient, um die Änderung der Benutzerfreundlichkeit zu testen, alles, was die Konversion beeinflussen kann.
   
• Feature Flags: Auch als Feature Toggles bezeichnet, ermöglicht es das Ausblenden, Aktivieren oder Deaktivieren einer kleinen Funktion zur Laufzeit, versteckt vor der Benutzeroberfläche.

  

• Service Mesh: Wenn ein Service Mesh zwischen den Containern und Diensten platziert wird, merkt er sich, was zuletzt funktioniert hat. Dies hilft, einen Aufruf erneut zu versuchen, wenn er fehlschlägt, oder auf die letzte verfügbare Antwort zurückzugreifen. Darüber hinaus wird auch das Canary-Routing zu einem bestimmten Benutzerbereich ermöglicht und ein Failover mit der Möglichkeit durchgeführt, Dienste mit erweitertem Service-Routing und Traffic-Shifting zu orchestrieren.

  

• Observability: Observability umfasst die Verfolgung, Protokollierung und Metrikenpflege, die es Entwicklern ermöglicht, neue Dienste mit einer starken Sichtweise darauf zu erstellen, wie die Verwaltung in der Produktion erfolgen wird.
   
• Chaos Engineering: Es ist eine Kunst, einen Fehler zu übernehmen, indem man definiert, was ein normaler Zustand für ein bestimmtes verteiltes System ist, und dann auf irgendeine Weise den Problembereich oder das Problem durch tatsächliche Widerstandstests löst.

Tools zur Durchführung von Progressive Delivery

Um die progressive Bereitstellung zu vereinfachen, wird die folgende Toolausstattung empfohlen:

• WeaveWorks: Es ist ein Kubernetes-Operator, der die Promotion von Canary-Deployments mithilfe von Routing für ein Traffic-Shifting-Tool automatisiert.
   
• SwitchIO: SwitchIO ist ein schnelles asynchrones Steuerungssystem, das das Verständnis von Fehlermustern in Clustern erleichtert.
   
• Petri: Eine Product Experiment Infrastructure (Petri) ist ein umfassendes Experimentiersystem von Wix, das A/B-Tests und Feature Toggles verwendet.
   
• LaunchDarkly: Das Tool wird für das Feature-Management mit automatisierten Feature Toggles verwendet, die von den Benutzer-Personas abhängen.

Abschließende Bemerkung

Zusammenfassend lässt sich sagen, dass Progressive Delivery als ein Prozess definiert werden kann, der die Erfahrung von Benutzern und Entwicklern in Einklang bringt. Progressive Delivery wird üblicherweise als der nächste Schritt der Continuous Integration und Continuous Delivery bezeichnet und treibt Änderungen iterativ in die Produktion.

Was ist Ihre Meinung dazu? Teilen Sie Ihre Ansichten auf unseren Social-Media-Kanälen: Facebook, LinkedIn und Twitter.