Dies ist einer von zwei PagerDuty Beiträgen zum Thema „Continuous“. Schaut euch auch unseren ersten Beitrag an: Sind Sie bereit für Continuous Deployment?

Dauerhafte Überlastung

Wer die Diskussionen um moderne Softwareentwicklung verfolgt, hat manchmal das Gefühl, mit einem Zauberstab der Kontinuitätstechnologie erschlagen zu werden. Kontinuierliche Integration, Kontinuierliche Auslieferung, Kontinuierliche Bereitstellung Kontinuierliche Dokumentation usw. Die Idee ist so einfach, dass sie fast schon frustrierend ist: Schnell sein. Doch die Vorteile von Schnelligkeit gehen weit über mehr Builds für Ihre Nutzerbasis hinaus. Der größte Wert liegt vielleicht langfristig darin, dass Sie die Anwendung kontinuierlich und ohne Angst vor Fehlern testen können, weil Sie sie genauso schnell wieder reparieren können.

Was bringt Ihnen Geschwindigkeit langfristig? Können Sie über einen Zeitraum von drei Monaten mehr über Ihre Pipeline sagen als „Wir hatten mehr Builds“? Mehr Releases sind das eine. Aber eine Delivery-Chain, die Innovationen nicht unterstützt, ist nichts weiter als ein Mittel zum Zweck, um von A nach B zu gelangen. Um in einer DevOps-orientierten Organisation echten Erfolg zu demonstrieren, müssen Sie nachweisen können, dass sich auch Ihre Softwarequalität und Funktionalität verbessern – das heißt, all die interessanten Funktionen, die bisher im Backlog schlummerten, finden endlich ihren Weg nach oben.

Warum kontinuierlich?

Continuous ermöglicht es uns, unsere Anwendungen bedenkenlos zu testen – denn wir wissen, dass wir Probleme schnell erkennen und in einem neuen Build beheben können. Teams können nun Funktionen implementieren, die sie schon lange einführen wollten, aber aufgrund des wahrgenommenen Risikos bisher vermieden haben.

„Break/Fail Fast“ bedeutet im Grunde, dass man die Funktionalität opportunistisch nutzen kann. Dies ist womöglich der einzige Weg, um Funktionen zu entwickeln, die nahezu in Echtzeit auf Benutzeranforderungen reagieren, oder um zu erfahren, wie sich neue Funktionen auf die Anwendung und deren Akzeptanz auswirken. Ohne „Fail Fast“ sind Anwendungen – unabhängig von der Kürze der Sprints – möglicherweise zu rein linearen Releases verdammt. Sie können in dieselbe Falle tappen, die wir alle nur allzu gut kennen: Stagnation. Das bedeutet, dass die Entwicklung neuer Funktionen zugunsten minimaler Änderungen an bestehenden Funktionen vernachlässigt wird. In diesem Fall veraltet die Anwendung und lässt sich nur noch durch grundlegende Überarbeitungen, Refactoring oder komplett neue Anwendungen retten. Das ist alles andere als kontinuierlich – oder zumindest nicht nachhaltig kontinuierlich.

Kanarienvogel-Releases

Die extremste Form des schnellen Scheiterns und Behebens sind sogenannte Canary-Releases. Dabei werden eine oder mehrere neue Versionen der Anwendung parallel zur bestehenden Produktionsversion veröffentlicht. Sobald die Releases abgeschlossen sind, wird der gesamte Datenverkehr oder ein Teil davon von der Produktionsumgebung auf die neuen Release-Umgebungen umgeleitet. Der Zweck dieser Umleitung besteht darin, A/B-Tests mit leicht abgewandelten Versionen der Releases durchzuführen.

Sollte bei einer Canary-Version etwas schiefgehen, werden Sie dank eines zuverlässigen Benachrichtigungssystems umgehend informiert. Anschließend können Sie den Datenverkehr wieder auf die Produktionsversion umleiten. Dies kann zwar kurzzeitig zu geringfügigen Beeinträchtigungen Ihrer Nutzer führen, die Reaktion erfolgt jedoch so schnell, dass es wie eine Störung wirkt. Neue Funktionen können innerhalb weniger Tage entwickelt werden.

Da Sie mehr über die neue Funktionalität erfahren haben, können Sie sie entweder verwerfen oder innerhalb dieser Canary-Version korrigieren und anschließend erneut testen. Dies ist ein echtes iteratives Modell. Und es kann nicht nur als eine Iteration, sondern auch als mehrere parallel laufende Iterationen eingerichtet werden.

Dieses Modell würde als Extremfall der kontinuierlichen Bereitstellung gelten, allerdings ohne die automatisierten Funktions- und Systemtests vor der Veröffentlichung. Diese Prozesse können zu zeitaufwendig sein, um das Konzept zu unterstützen. Es setzt einige Dinge voraus. Die wichtigste ist, dass Ihre Anwendung eine ausreichend große Nutzerbasis und ein entsprechendes Nutzervolumen aufweist, um schnelle Tests neuer Funktionen zu ermöglichen.

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

Die Werkzeuge, um es zu schaffen

Natürlich erfordert eine solch fortschrittliche Betrachtungsweise von Releases und Anwendungsarchitekturen leistungsstarke Werkzeuge. Die drei wichtigsten Werkzeuge für schnelles Scheitern sind folgende:

1. Release-Automatisierung: Ihr Tool zur Release-Automatisierung muss mehrere Releases gleichzeitig verarbeiten können. Das können zwar 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 schwerwiegenden Problemen führen kann. Und der zusätzliche Aufwand rechtfertigt den Prozess möglicherweise nicht.
2. On-Demand-Cloud-Umgebungen: Die dafür benötigte Infrastruktur zeichnet sich nicht durch hohe Leistung, sondern durch Flexibilität aus. Platform as a Service (PaaS) ist die geeignetste Infrastrukturform für Canary-Releases, da PaaS auf einen Ressourcenpool und nicht auf einzelne VMs zugreift. Dies beschleunigt die Bereitstellung und vereinfacht die Verwaltung, da keine Orchestrierung etc. erforderlich ist. Die meisten PaaS-Umgebungen unterstützen zudem einen einfacheren Traffic-Swap. Bei Infrastructure as a Service (IaaS) muss dies über DNS oder Load Balancer gesteuert werden, was einen zusätzlichen Schritt bedeutet. Dennoch spricht nichts dagegen, IaaS von Breakfast-Prozessen auszuschließen, insbesondere bei Nutzung von Container-Technologien wie Docker, die die Implementierung nahezu so einfach wie bei PaaS gestalten. Ob IaaS oder PaaS – Entwickler müssen beliebig viele Umgebungen bedarfsgerecht erstellen und wieder entfernen können. Ist der Zugriff auf Umgebungen beschränkt, lassen sich weder Parallelität erreichen noch Probleme mit einer neuen, aktualisierten Version beheben. Die von mir vorgeschlagenen Prozesse erfordern Full-Stack-Bereitstellungen, daher ist die Bereitstellung in bestehenden Umgebungen keine Option. Bei einem so schnellen Freigabe- und Wiederherstellungsprozess ist es sehr einfach, Variablen anzusammeln, die dauerhafte Umgebungen verunreinigen würden.
3. Warnung: Die Protokollierung Ihrer Umgebungen ist wichtig, insbesondere für historische Daten. Bei Canary-Releases reichen historische Daten jedoch nicht aus. Reaktionen auf Probleme mit jedem Build müssen schnell erfolgen, und die Lebensdauer einer Iteration ist sehr kurz. Daher benötigen Sie eine leistungsstarke Alarmierungsplattform, die Sie umgehend benachrichtigt. Diese Plattform muss jedoch auch intelligent sein. Aufgrund der Häufigkeit und Anzahl paralleler Releases kann eine Informationsflut schnell zum Problem werden; die Reaktion auf jedes Problem erfordert daher einen aufwendigen Filterprozess.

Es ist nicht alles Technologie

Die Konzepte, schneller zu veröffentlichen, Fehler schneller zu beheben und Probleme schneller zu lösen, sind nicht komplex. Ihre Implementierung in bestehenden Umgebungen kann jedoch schwierig sein. Und genau hier weiß jeder erfahrene Entwickler, Betriebs- und QA-Mitarbeiter, dass man nicht einfach den Schalter für die Canary-Version umlegen kann.

Die Implementierung ist ein Prozess, der oben beschriebene Prozess hingegen ein Ziel. Ein Vorteil des bereits etablierten Continuous-Integration-Verfahrens ist, dass sich das experimentelle Fehler- und Rücksetzverfahren auch in Integrationsumgebungen implementieren lässt. Dort betrifft dies ausschließlich das interne Team. In diesem Fall ist vor allem die Qualitätssicherung betroffen, da sie für das Testen der Releases direkt nach deren Erstellung verantwortlich ist. Die größte organisatorische Veränderung findet daher dort statt. (Die Auswirkungen sind jedoch deutlich geringer als bei einer teamweiten Implementierung in der Produktion.)

Im Wesentlichen stehen die Werkzeuge zur Verfügung, um schneller zu entwickeln, Fehler schneller zu erkennen und schneller zu beheben – ein Prozess, der nicht nur die Anzahl der Builds pro Jahr erhöht, sondern auch die Innovationskraft steigert und so zu neueren Funktionen und höherer Qualität führt. Da die Werkzeuge bereits vorhanden sind, liegt es nun am Team, einen Weg von den bestehenden Release-Prozessen zu den neuen Prozessen zu finden.

Dies ist einer von zwei PagerDuty Beiträgen zum Thema „Continuous“. Schaut euch auch unseren ersten Beitrag an: Sind Sie bereit für Continuous Deployment?