Dies ist einer von zwei PagerDuty Beiträgen zu Continuous. Sehen Sie sich unseren ersten an: Sind Sie bereit für Continuous Deployment?

Dauerhafte Überlastung

Wenn Sie sich die modernen Gespräche über Softwarebereitstellung genau ansehen, haben Sie manchmal das Gefühl, als ob Ihnen ein Zauberstab über den Kopf geschlagen würde. Continuous Integration, Continuous Delivery, Kontinuierliche Bereitstellung , kontinuierliche Dokumentation usw. Die Idee ist so einfach, dass es frustrierend ist: Gehen Sie schnell vor. Aber die Vorteile des schnellen Vorgehens gehen weit über mehr Builds für Ihre Benutzerbasis hinaus. Der größte Nutzen liegt vielleicht langfristig und darin verborgen, dass Sie die Anwendung ohne Angst kontinuierlich beschädigen können, weil Sie sie auch kontinuierlich reparieren können.

Was bringt Ihnen Geschwindigkeit auf lange Sicht? Können Sie über einen Zeitraum von drei Monaten mehr über Ihre Pipeline sagen als „Wir hatten mehr Builds“? Mehr Releases sind eine Sache. Aber eine Lieferkette, die keine Innovation unterstützt, ist nichts weiter als ein Weg, um von Punkt A nach Punkt B zu gelangen. Um in einer DevOps-gesteuerten Organisation echten Erfolg zu demonstrieren, müssen Sie zeigen können, dass sich auch die Qualität und Funktionalität Ihrer Software verbessert – was bedeutet, dass all die coolen Funktionen, die in Ihrem Backlog vergraben sind, schließlich an die Oberfläche gelangen.

Warum kontinuierlich?

Was Continuous uns bietet, ist die Möglichkeit, unsere Anwendungen mit Zuversicht zu unterbrechen – weil wir wissen, dass wir schnell auf etwaige Probleme aufmerksam werden und zu einem neuen Build iterieren können, um sie zu beheben. Teams können jetzt eine Funktion implementieren, die sie unbedingt implementieren wollten, aber aufgrund des wahrgenommenen Risikos vermieden haben.

Was „Break/Fail Fast“ wirklich bedeutet, ist, dass Sie Ihre Funktionalität opportunistisch gestalten können. Dies ist möglicherweise die einzige Möglichkeit, Funktionen zu erstellen, die nahezu in Echtzeit auf Benutzeranforderungen reagieren, oder um zu erfahren, wie sich neue Funktionen auf die Anwendung und die Akzeptanz auswirken. Ohne „Fail Fast“ sind Anwendungen möglicherweise zu rein linearen Releases verdammt, egal wie kurz Ihre Sprints sind. Und sie können in dieselbe Falle tappen, die wir alle nur zu gut kennen – Stagnation, auch bekannt als die letztendliche Verlangsamung neuer Funktionen zugunsten sehr kleiner Änderungen an vorhandenen Funktionen. Wenn dies geschieht, wird Ihre Anwendung veraltet und kann nur durch umfassende Umschreibungen, Refactoring oder ganz neue Anwendungen behoben werden. Dies ist überhaupt nicht kontinuierlich oder zumindest nicht dauerhaft kontinuierlich.

Canary-Veröffentlichungen

Das Extrem von „Fail Fast“ und „Fix Fast“ sind sogenannte Canary Releases. In einem Canary Release haben Sie eine oder mehrere neue Versionen der Anwendung parallel zur bestehenden Produktionsversion. Sobald die Version(en) abgeschlossen sind, leiten Sie den gesamten oder Teilsegmente des Datenverkehrs von der Produktion in die neuen Release-Umgebungen um. Der Zweck der Teilsegmente besteht darin, A/B-Tests an geringfügigen Variationen der Versionen durchzuführen.

Wenn bei einer Canary-Version etwas schief geht, werden Sie dank eines robusten Warnmechanismus schnell darüber informiert. Anschließend können Sie den Datenverkehr wieder in die Produktion zurückführen. Die Maßnahme kann sich geringfügig negativ auf Ihre Benutzer auswirken, die Reaktion erfolgt jedoch so schnell, dass es wie eine Störung aussieht. Neue Funktionen könnten innerhalb von Tagen entwickelt werden.

Da Sie nun mehr über die neue Funktionalität erfahren haben, können Sie sie entweder löschen oder innerhalb dieser Canary-Version beheben und schnell erneut testen. Dies ist wirklich ein iteratives Modell. Und es kann nicht nur als eine Iteration, sondern als mehrere parallel laufende Iterationen eingerichtet werden.

Dieses Modell würde auch als Extrem der kontinuierlichen Bereitstellung angesehen werden, allerdings ohne einige der automatisierten Funktions- und Systemtests vor der Veröffentlichung. Diese Prozesse können zu langwierig sein, um das Konzept zu unterstützen. Es setzt einige Dinge voraus. Das Wichtigste ist, dass Ihre Anwendung über eine ausreichend große Benutzerbasis und ein ausreichend großes Volumen verfügt, um schnelle Tests neuer Funktionen zu unterstützen.

Ich habe noch nicht herausgefunden, wie dies mit einer stark verteilten Microservices-Anwendung funktionieren kann, aber ich bin sicher, dass es möglich ist, wenn Sie Folgendes haben:

Die richtigen Werkzeuge, um es zu erledigen

Natürlich erfordert eine so fortschrittliche Betrachtungsweise von Releases und Anwendungsarchitekturen hervorragende Tools für die Umsetzung. Und die drei wichtigsten Tools für schnelles Fail sind die folgenden:

1. Release-Automatisierung: Ihr Tool zur Release-Automatisierung muss in der Lage sein, mehrere Releases gleichzeitig zu verarbeiten. Das können sie alle, aber das meine ich nicht. Die Unterstützung mehrerer paralleler Releases erfordert ein sehr gutes Statusmanagement und Dashboards zur Visualisierung der Releases. Ohne diese Transparenz ist es sehr schwierig zu wissen, welche Releases sich wo befinden und wann sie zurückgesetzt werden, was zu ernsthaften Problemen führen kann. Und der zusätzliche Aufwand macht den Prozess möglicherweise nicht lohnenswert.
2. On-Demand-Cloud-Umgebungen: Bei der Infrastruktur, die dies unterstützt, geht es nicht um Leistung, sondern um Flexibilität. Platform as a Service (PaaS) ist die am besten geeignete Infrastrukturform zur Unterstützung von Canary-Releases, da Sie bei PaaS auf einen Ressourcenpool und nicht auf tatsächliche VMs zugreifen. Dies beschleunigt die Bereitstellung und ist auch einfacher zu verwalten, da Sie sich nicht um Orchestrierung usw. kümmern müssen. Die meisten PaaS-Umgebungen unterstützen auch einen einfacheren Datenverkehr-Austausch. Bei Infrastructure as Service (IaaS) müssen Sie dies über Ihren DNS oder Load Balancer steuern, was wahrscheinlich ein zusätzlicher Schritt ist. Es gibt jedoch keinen Grund, IaaS von Break-Fast-Prozessen auszuschließen, insbesondere wenn Sie Containertechnologie wie Docker nutzen, die es fast so einfach macht wie PaaS. Bei IaaS oder PaaS müssen die Entwickler in der Lage sein, so viele Umgebungen wie gewünscht hoch- und herunterzufahren und dies bei Bedarf zu tun. Wenn der Zugriff auf Umgebungen eingeschränkt ist, gibt es keine Möglichkeit, Parallelität zu erreichen oder auf Probleme mit einer neuen, aktualisierten Version zu reagieren. Die Prozesse, die ich vorschlage, erfordern Full-Stack-Bereitstellungen, daher ist die Bereitstellung in vorhandenen Umgebungen ebenfalls keine Option. Bei einem so schnellen Freigabe- und Rücknahmeprozess können sich sehr leicht Variablen ansammeln, die persistente Umgebungen kontaminieren würden.
3. Alarmierung: Das Protokollieren Ihrer Umgebungen ist eine Sache. Es ist wichtig, Protokollierung zu implementieren, aber hauptsächlich für historische Daten. Bei Canary-Releases sind historische Daten jedoch zu spät. Die Reaktionen auf das, was mit jedem Build passiert, müssen schnell erfolgen, und die Lebensdauer einer Iteration ist sehr kurz. Sie benötigen daher eine sehr leistungsstarke Warnplattform, die Ihnen Warnmeldungen senden kann, sobald diese auftreten. Die Warnplattform muss jedoch auch intelligent sein. Aufgrund der Häufigkeit und Anzahl paralleler Releases können zu viele Informationen leicht zu einem Problem werden. Daher erfordert die Reaktion auf jedes Problem einen langwierigen Filterprozess.

Es ist nicht alles Technologie

Die Konzepte für schnellere Veröffentlichungen, schnellere Fehlersuche und schnellere Behebung von Problemen sind nicht komplex. Aber ihre Implementierung in bestehende Umgebungen kann komplex sein. Und hier weiß jeder erfahrene Entwickler, Betriebs- und Qualitätssicherungsmitarbeiter, dass man nicht einfach den Schalter für die Canary-Release umlegen kann.

Die Implementierung ist ein Weg, aber der oben beschriebene Prozess ist ein Ziel. Und das Schöne an dem bereits beliebten Prozess der kontinuierlichen Integration ist, dass der experimentelle Fail-and-Revert-Prozess in Integrationsumgebungen implementiert werden kann. Dort wirkt sich dies nur auf Ihr internes Team aus. In diesem Fall wird die Auswirkung hauptsächlich die Qualitätssicherung betreffen, da diese für das Testen von Releases verantwortlich ist, sobald diese erstellt werden. Daher besteht dort die größte organisatorische Veränderung. (Immer noch weitaus weniger als bei einer teamweiten und produktiven Implementierung.)

Unterm Strich stehen die Tools zur Verfügung, um schneller zu bauen, schneller zu scheitern und schneller zu reparieren – ein Prozess, der nicht nur die Anzahl der Builds erhöht, die Sie pro Jahr erstellen, sondern auch die Innovation, die stattfinden kann, um neuere Funktionen und Qualität zu produzieren. Da die Tools bereits vorhanden sind, liegt die Last beim Team, einen Weg von den bestehenden Release-Prozessen zu neuen Prozessen zu finden.

Dies ist einer von zwei PagerDuty Beiträgen zu Continuous. Sehen Sie sich unseren ersten an: Sind Sie bereit für Continuous Deployment?