Die Softwareentwicklung im Jahr 2020 ist ein sich schnell veränderndes Umfeld. Es wird von Tag zu Tag deutlicher, dass unsere Organisationen, wenn sie diese Zeit der politischen und wirtschaftlichen Unsicherheit überleben wollen, in der Lage sein müssen, sich schnell und anpassungsfähig zu bewegen. Aber wie kann man die Sicherheit bei der Geschwindigkeit kontrollieren? Wenn Ihr Ziel darin besteht, von einem Softwarebereitstellungszyklus, der mit vielen Leitplanken und seltenen Releases aufgebaut wurde, zu einer moderneren Methodik überzugehen, die Reaktionsfähigkeit durch häufige Releases unterstützt, um Ihren Kunden so schnell und sicher wie möglich einen Mehrwert zu bieten, dann kommt es sehr darauf an, wen Sie mit Entscheidungen zum Änderungsmanagement betrauen.

Traditionell werden diese Entscheidungen in vielen Unternehmen zentral von einem Änderungsmanager getroffen, der regelmäßige Sitzungen des Änderungsbeirats (CAB) abhält. Das CAB besteht aus Vertretern verschiedener Funktionen innerhalb und außerhalb der IT-Abteilung des Unternehmens, die die Aufgabe haben, vorgeschlagene Änderungen zu prüfen und den Change Manager bei der Bewertung, Priorisierung und Planung von Änderungen zu unterstützen. Es handelt sich dabei um eine Gruppe, die nicht direkt an der Gestaltung oder Umsetzung der vorgeschlagenen Änderung beteiligt ist, weshalb der von ihr durchgeführte Prozess als „externe“ Überprüfung bezeichnet wird.

Aber wer sollte dafür zuständig sein? Um sowohl die Geschwindigkeit und Sicherheit als auch die geschäftlichen Auswirkungen bestmöglich zu unterstützen, sollten Ihre Entwicklungsteams und Ihre Kunden die Entscheidungsfindung vorantreiben. Aus technischer Sicht wissen Ihre Entwickler besser als jeder Änderungsbeirat, was in einer Version enthalten ist, ob Abhängigkeiten bestehen und ob sie getestet wurde. Aus geschäftlicher Sicht ist es an der Zeit zu erkennen, dass der Kunde der letzte Schiedsrichter darüber ist, was funktioniert und was nicht, und nicht irgendein leitender Manager und ganz sicher nicht Ihr Änderungsbeirat.

Ein Änderungsbeirat ist vielleicht langsamer, aber zumindest sicherer, nicht wahr?

Der Änderungsbeirat (und vieles von dem, was Sie in ITIL finden), mag wie ein vernünftiger Weg erscheinen, das Risiko zu verringern und die Strenge zu erhöhen, besonders in sich langsam bewegenden, komplexen Umgebungen. Wenn Sie nur alle 30 oder 90 Tage die Möglichkeit haben, die Produktion zu ändern, scheint es eine gute Möglichkeit zu sein, das Risiko zu minimieren, indem Sie die Dinge mit Quality Gates und Genehmigungen des Managements aus den Releases heraushalten. Niemand würde bestreiten, dass dies ein langsamerer Prozess ist (der die Zeit zwischen dem Schreiben des Codes durch einen Entwickler und der Inbetriebnahme um Wochen oder Monate verlängern kann), aber es ist sicherer, oder?

Genau genommen, nein. Ist es nicht.

Eine mehrjährige Studie in einer Vielzahl von Branchen und Umgebungen ergab, dass ein CAB oder ein ähnliches „externes Genehmigungsverfahren“ schlechter abschneidet als gar kein Genehmigungsverfahren. Hier ist, was die Hauptautorin Dr. Nicole Fosgren zu den Ergebnissen zu sagen hatte:

Wir fanden heraus, dass externe Genehmigungen negativ mit der Vorlaufzeit, der Einsatzhäufigkeit und der Wiederherstellungszeit korreliert waren und keine Korrelation mit der Fehlerquote bei Änderungen aufwiesen. Kurz gesagt, die Genehmigung durch ein externes Gremium (z. B. einen Manager oder ein CAB) trägt einfach nicht dazu bei, die Stabilität von Produktionssystemen zu erhöhen, gemessen an der Zeit bis zur Wiederherstellung des Betriebs und der Ausfallrate von Änderungen. Sie verlangsamt die Dinge jedoch mit Sicherheit. Es ist sogar schlimmer, als wenn es überhaupt kein Genehmigungsverfahren für Änderungen gäbe.

Was ist besser als gar kein Änderungsmanagement?

Dr. Fosgren und ihr Team schlagen zwar kein Genehmigungsverfahren vor, aber wenn man bedenkt, wie schlecht CABs in der Praxis abschneiden, sollten wir überdenken, welche Art von Verfahren tatsächlich für Sicherheit sorgt.

Hier ein weiteres Zitat aus der Accelerate-Studie:

Unsere Empfehlung auf der Grundlage dieser Ergebnisse ist die Verwendung eines leichtgewichtigen Änderungsgenehmigungsprozesses auf der Grundlage von Peer-Reviews, wie z. B. Pair Programming oder Code-Reviews innerhalb des Teams, kombiniert mit einer Deployment-Pipeline zur Erkennung und Zurückweisung schlechter Änderungen. Dieser Prozess kann für alle Arten von Änderungen verwendet werden, einschließlich Code-, Infrastruktur- und Datenbankänderungen.

Peer Code Reviews kombiniert mit What Now?

Als ich diese Empfehlung im März 2018 las, hatte ich kein Problem, mir die erste Hälfte vorzustellen: Peer Code Reviews und wöchentliche Teamdemos waren bei BlazeMeter bereits die Norm. Die zweite Hälfte? Nicht so sehr! Wir waren eine „moderne“ Cloud-native SaaS-App, aber ich hatte noch nie etwas von „einer Deployment-Pipeline gehört, die schlechte Änderungen erkennt und zurückweist.“

Um das Risiko während der Releases zu managen, verwendeten wir damals eine Kombination aus Blue/Green Deployments und Canary Releases. Die Plattform übernahm das „Pushen“, aber nicht das „Erkennen“ oder „Zurückweisen“ – das war Sache unserer besten und klügsten SREs, die den Zustand von Dutzenden von Dingen manuell überprüften, bevor wir auf 100 % der Benutzer hochfuhren. Bei der Lektüre von „detect and reject bad changes“ erschien nur das Bild eines schwarzen Kastens auf einem Whiteboard mit der Aufschrift „magic happens here“. Ich erinnerte mich an mein Filmstudium an der Universität, wo ich lernte, was „deus ex machina“ bedeutet.

Erkennen und Zurückweisen: Examples Are Out There If You Look

In zwei Jahren kann sich eine Menge ändern. Seit ich bei Split als CD-Evangelist tätig bin, habe ich Lukas Vermeer dabei zugesehen, wie die Deployment-Pipeline von Booking.com eine schlechte Änderung innerhalb einer einzigen Sekunde erkennen und rückgängig machen kann. Ich habe Sonali Sheel von Walmart Labs zugehört, wie sie ihre Expo-Plattform nutzen, um ein Rollout auf halbem Weg zu stoppen, bevor es ihren Schlüsselkennzahlen schadet – etwas, das sie „Test to Launch“ nennen.

Die Split Feature Delivery Platform wurde von Menschen mit ähnlichen Visionen von modernem Change Management auf der Grundlage ihrer Erfahrungen bei LinkedIn, Salesforce.com und Yahoo entwickelt. Die Gründer holten sich Ratschläge von Leuten, die die Komplexität, Geschwindigkeit und den Umfang ähnlicher Systeme bei Amazon und Microsoft in Angriff genommen hatten.

Als ich von Split hörte und die Beispiele entdeckte, die sie vermarkteten, ergriff ich die Chance, mich ihnen anzuschließen. Der Aufbau einer solchen Plattform im eigenen Haus war etwas, für das nur wenige Giganten die Zeit und die Ressourcen hatten. Wenn die gleiche Art von feinkörniger Aufdeckung und automatischer Erkennung von Auswirkungen als SaaS verfügbar wäre, dann könnte die wirkungsorientierte Softwarebereitstellung für jedes Team zugänglich gemacht werden, nicht nur für die Einhorn-Startups.

Das ist erstaunlich, aber es wird hier nicht funktionieren

Eine lustige Sache passierte immer wieder, wenn ich zu Tech-Konferenzen reiste und Vorträge über die frühen Pioniere hielt, die diese Plattformen im eigenen Haus aufgebaut hatten. Die Zuhörer reagierten erst mit Erstaunen und dann mit Resignation. „Das ist ziemlich cool, aber wir sind nicht Booking.com, LinkedIn oder Facebook. Wir können das in unserer Umgebung nicht machen.“

In meinem Bemühen, „anbieterneutral“ zu sein, indem ich die Besonderheiten der Implementierung von Split vermied, hatte ich praktisch das unscharfe Bild einer schwarzen Box mit der Aufschrift „Hier passiert Magie“ neu gezeichnet.

Was wäre, wenn es nicht so schwer wäre?

Wenn Sie noch nie eine Plattform gesehen haben, die eine feinkörnige Kontrolle der Exposition und einen rigorosen automatischen Mechanismus zur Erkennung und Zurückweisung von schlechten Änderungen in Ihrer Umgebung bietet, können Sie nicht dafür verantwortlich gemacht werden, dass Sie es für Science Fiction halten.

Es stellt sich heraus, dass es hier nur vier Hauptprobleme zu lösen gibt:

1. Entkoppeln Sie die Bereitstellung von der Veröffentlichung, so dass der Code bis zur Produktion gepusht, aber an der Ausführung gehindert werden kann, bis er fertig ist. Dies erleichtert eine echte kontinuierliche Integration, kleine Losgrößen, inkrementelle Entwicklung von Funktionen und Verzweigungen durch Abstraktion, die allesamt entscheidend für eine kontinuierliche Bereitstellung sind, bei der ein fließender Ablauf die Norm ist.
2. Selektive Freigabe des neuen Codes, beginnend mit einem kleinen internen Publikum und nach außen arbeitend. Dies erleichtert das Testen in der Produktion, Dogfooding, Early-Access-Programme und das Stapeln von Änderungen für änderungsunwillige Kunden.
3. Erfassen Sie System- und Benutzerverhaltensdaten und gleichen Sie sie mit den Expositionsdaten ab, die angeben, wer zu den einzelnen Benutzerkohorten gehört und wer nicht. Ziel ist es, den Zuordnungsprozess (Abgleich von „Wer hat was bekommen?“ mit „Dann ist das passiert“) automatisch und kontinuierlich zu gestalten.
4. Vergleichen Sie die Muster der Metriken zwischen den eingeschlossenen und den ausgeschlossenen Personen in jeder Kohorte, um signifikante Unterschiede zu identifizieren (und optional darauf hinzuweisen). Sie haben dieses Muster vielleicht schon einmal im Zusammenhang mit „A/B-Tests“ gesehen, bei denen typischerweise die Auswirkungen von Änderungen auf eine Konversionsmetrik verfolgt werden, aber hier geht es um die umfassende Verfolgung der Auswirkungen aller technischen Arbeiten und die ständige Beobachtung der Auswirkungen auf alle unternehmenswichtigen Metriken, unabhängig davon, ob Auswirkungen auf diese Metriken erwartet werden oder nicht.

Progressive Lieferung: Eine leicht zu etablierende Grundlage

Die Entkopplung von Deployment und Release und die selektive Freigabe von neuem Code sind als Progressive Delivery bekannt geworden, ein Begriff, der von RedMonk-Analyst James Governor geprägt wurde. Mehrere kommerzielle Anbieter von Feature Flags bieten diese Funktionen bereits an, und es zeichnet sich ein Konsens darüber ab, dass sich Feature Flags in die Liste der Entwickler-Tools eingereiht haben, bei denen es sinnvoller ist, sie zu kaufen als sie selbst zu entwickeln und zu pflegen.

Feature Flags sind eine wichtige Grundlage für das Erreichen eines reibungslosen Ablaufs, aber sie allein beschleunigen die Erkennung von Auswirkungen nicht. Die meisten Feature-Flag-Implementierungen erleichtern den Datenfluss, zeigen aber nicht an, ob alles in Ordnung ist oder ob Sie sinnvolle Ergebnisse erzielen.

Vorwarnung: Datenwissenschaftler skalieren nicht

Das System- und Benutzerverhalten zu erfassen und automatisch mit den exponierten Kohorten abzugleichen, ist bei allen außer den ausgefeiltesten internen Systemen selten. Die meisten Teams, die dies versuchen, führen eine Menge manueller und Ad-hoc-Data-Science-Arbeiten durch. Da sie eher durch personelle Ressourcen als durch Rechnerkapazitäten eingeschränkt sind, sind sie gezwungen, auszuwählen, wann und wo sie ihre Aufmerksamkeit einsetzen.

Die kognitive Belastung ist nicht Ihr Freund, wenn Sie einen reibungslosen Ablauf anstreben. Das Design von Split verlangt von den Teams nicht einmal, dass sie auswählen, welche Ereignisse mit jedem Rollout von Feature-Flags verknüpft werden sollen; alle aufgenommenen Ereignisse werden, sobald sie mit organisatorischen Metriken verknüpft sind, kontinuierlich den On- und Off-Kohorten jedes Rollouts zugeordnet, ohne dass ein Eingriff erforderlich ist. Split erleichtert auch die Identifizierung und Aufnahme von Ereignisdaten durch die Integration mit Segment, Sentry, mParticle und Google Analytics.

Semper Fi für Continuous-Delivery-Pipelines

Der rigorose Vergleich von Metrikmustern zwischen den in jeder Kohorte eingeschlossenen und nicht eingeschlossenen Personen zur automatischen Ermittlung signifikanter Unterschiede ist in der Praxis noch seltener als die Attribution. Das ist genau das Problem, das die Module Monitor und Experimentation von Split lösen. Monitor konzentriert sich darauf, die Auswirkungen auf die Metriken während der Einführung zu erkennen und zu melden (auch bekannt als „Begrenzung des Radius von Zwischenfällen“), während Experimentation, ähnlich wie A/B-Tests, eine kontinuierliche Quelle unvoreingenommener Daten bereitstellen soll, die nicht von der Verfügbarkeit eines Analysten abhängig sind, um zu zeigen, ob jede Funktion die gewünschte Wirkung erzielt hat oder nicht.

Besser zusammen: Peer Review, Progressive Delivery und automatisierte Entscheidungsfindung

Warum streben wir nach Flow? Es geht nicht um den Output. Es geht um das Ergebnis. Wir streben einen reibungslosen Ablauf an, damit wir die Rückkopplungsschleife von Idee -> Umsetzung -> Beobachtung mit weniger Reibung und in kürzerer Zeit wiederholen können. Unabhängig davon, ob Sie es „wirkungsorientierte Entwicklung“ oder „kundenorientierte Entwicklung“ nennen, geht dieser Ansatz für ein schnelleres Vorankommen mit einem größeren (und schnelleren) Bewusstsein für die Ergebnisse weit über die „Bereitstellungspipeline zur Erkennung und Zurückweisung schlechter Änderungen“ hinaus, die das DORA-Team uns in Verbindung mit Peer-Review-Verfahren empfohlen hat. Ja, wir können automatisch schlechte Änderungen erkennen und zurückweisen, aber noch wichtiger ist, dass wir einen wiederholbaren Prozess für die Triangulation in Richtung sinnvoller Geschäftsergebnisse aufbauen können.

Erfahren Sie mehr über das gemeinsame Erreichen von Change Management und Flow in Continuous Delivery

• Schauen Sie sich ein vierminütiges Video über die Definition von Continuous Delivery an, um zu sehen, warum eine kleine Batch-Größe für das Erreichen eines konsistenten Flow entscheidend ist.
• Holen Sie sich im O’Reilly-E-Book „Continuous Delivery in the Wild“ Tipps von mehreren Teams, die täglich in Produktion gehen, ab
• Schauen Sie sich ein ausführliches Video mit Craig Sebenik (LinkedIn, Crunchbase, Matterport) zu den Vorteilen der Umstellung auf trunk-basierte Entwicklung an.

Suchen Sie nach weiteren großartigen Inhalten zum Erzielen sinnvoller Ergebnisse mit Feature Delivery in großem Maßstab? Setzen Sie ein Lesezeichen für den Split-Blog, besuchen Sie uns auf YouTube, oder folgen Sie uns auf Twitter @splitsoftware.