Dies ist einer von zwei PagerDuty Beiträgen zu Continuous. Schauen Sie sich unseren zweiten an: Kontinuierlich – Schnell erstellen, unterbrechen und reparieren

Kontinuierliche Bereitstellung vs. kontinuierliche Lieferung

Es besteht eine große Lücke zwischen dem Verständnis moderner Prozesse und Technologien und der tatsächlichen Umsetzung dieser. In der DevOps-Bewegung haben viele der Kernfunktionen breite Akzeptanz gefunden, wie etwa Orchestrierung, Release-Automatisierung und Analytik. Was jedoch nicht so weit verbreitet ist, sind die End-to-End-Prozesse der kontinuierlichen Bereitstellung und Implementierung, bei denen es nicht um Verständnis geht – sie werden durch vorhandene organisatorische Elemente und die praktische Umsetzung bestimmt. Sind Sie bereit für kontinuierliche Bereitstellung und Implementierung?

Es besteht ein Defizit in den Definitionen von kontinuierliche Lieferung Und Kontinuierliche Bereitstellung . Bevor ich also tiefer in das Thema eintauche, muss ich meine Definition geben. Lieferung bedeutet bis zur Veröffentlichung, aber nicht direkt zur Produktion. Es gibt immer noch ein Tor und jemand muss auf die Schaltfläche „Los“ klicken. Bereitstellung bezieht sich darauf, was direkt in die Produktion geht, nachdem alle Tests bestanden wurden. Der Unterschied mag trivial erscheinen, ist es aber nicht. Bereitstellung ermöglicht nicht nur, sondern erfordert auch tägliche Veröffentlichungen. Es impliziert auch einen sehr robusten Rückgängigmachungsmechanismus, der stark auf hervorragende Warn- und Protokollanalysen angewiesen ist.

Der Rest dieses Beitrags befasst sich mit der kontinuierlichen Bereitstellung (ab diesem Punkt als CD bezeichnet).

CD hat zwei Dimensionen, die seine Praktikabilität bestimmen. Die erste bezieht sich direkt auf die Anwendung. Die zweite bezieht sich auf die Umgebung, in der die Prozesse implementiert werden sollen.

Die Anwendung

Was ich Ihnen jetzt sagen werde, sind „Kampfworte“. Es ist (noch) nicht allgemein anerkannt, dass CD von Ihrem Anwendungstyp und Ihrer Architektur abhängt. Sie werden jedoch feststellen, dass die bereits vorhandenen CD-Pipelines viele Ähnlichkeiten in der Art ihrer Anwendung aufweisen. Und die Unternehmen, die CD opportunistisch betrachten, es aber noch nicht implementiert haben, stoßen auf eine Mauer.

Die Aspekte der Anwendungsarchitektur, die CD verhindern, sind:

1. Niedriges Transaktionsvolumen: Wenn Ihre Anwendung nicht genügend Aktivität aufweist, gibt es nicht genügend Aktivität, aus der Sie lernen können. Daher werden die Auswirkungen einer Veröffentlichung nicht innerhalb kurzer Zeit sichtbar. Und das Ergebnis wird nicht statistisch genau sein.
2. Geringe Benutzerbasis: Einer der Vorteile von CD besteht darin, dass Sie neue Funktionen schneller veröffentlichen können, darunter möglicherweise auch Funktionen, die als risikoreich gelten. Dies hat Auswirkungen auf Ihre Benutzerbasis, aber die Idee dahinter ist, dass Sie sich dafür entscheiden, nicht alle Versionen allen Benutzern zur Verfügung zu stellen. Wenn Sie nicht genügend Benutzer haben, können Sie keine Versionen für Untersegmente Ihrer Benutzerbasis erstellen.
3. Keine Full-Stack-Bereitstellungen/-Architektur verwenden : Wenn Sie Ihre Anwendung nicht als gesamten Stack-Rechner, Betriebssystem, Konfiguration und Code bereitstellen, treten Probleme auf. Erstens haben die Entwickler einfach nicht genügend Autonomie bei der Freigabe von Anwendungen, und das allein schränkt die Möglichkeit ein, ohne IT-Hürden in die Produktion zu gehen. Zweitens müssen zuverlässige Releases auf einer neuen Infrastruktur bereitgestellt werden. Dies vermeidet Probleme mit Kontamination, ermöglicht Vorhersehbarkeit und unterstützt auch die Möglichkeit, Anwendungen für Untersegmente der Benutzerbasis freizugeben. Bei Full-Stack-Bereitstellungen ist es so einfach, wie den DNS den Datenverkehr zu unterteilten Bereitstellungen steuern zu lassen. Die Verwendung von Containern macht dies viel einfacher.
4. Keine Nutzung der Servicearchitektur/Microservices: Ich meine damit nicht, dass Ihre Anwendung eine Microservices-Anwendung sein muss. Aber sie muss große Anwendungskomponenten als separate, sich gegenseitig ausschließende Objekte unterscheiden. Das bedeutet, dass Sie einzelne Komponenten bereitstellen können, ohne die gesamte Anwendung zu beeinträchtigen. Der Grund dafür ist, dass die vollständige Veröffentlichung der Anwendung bei CD nicht nur langsam ist, sondern dass die Auswirkungen eines Problems um ein Vielfaches schlimmer sind – und Ihre Reaktionsfähigkeit wird viel länger dauern, weil Sie die gesamte Anwendung nach der Implementierung eines Fixes erneut bereitstellen oder eine frühere Version erneut bereitstellen müssen.

Die Umgebung

Geringe Transaktionszahlen und eine niedrige Benutzerbasis hängen von Ihrem Markt und den Erwartungen Ihrer Benutzer ab. Es sollte Ihnen relativ klar sein, ob Sie diese Zahlen erfüllt haben oder nicht. Über die Eigenschaften Ihrer Anwendung hinaus versuchen die meisten Organisationen, CD in einer bestehenden Lieferkette zu implementieren, was bedeutet, dass es bestehende Prozesse und Personen gibt, mit denen man sich auseinandersetzen muss. Es ist möglich, CD-Prozesse zu implementieren, ohne die bestehende Organisation zu berücksichtigen, aber dies führt normalerweise zu nicht nachhaltigen Umgebungen. Hier sind einige wichtige Elemente, die Sie berücksichtigen sollten:

1. Es sind nicht nur Entwickler: Obwohl viele der Prozesse von Entwicklern vorgegeben werden, sind sie nicht die einzigen Bestandteile. In CD-Pipelines wird viel mehr Aufwand in die Strategie als in die Ausführung gesteckt. QA-Strategien sind entscheidend, um sicherzustellen, dass vor der Veröffentlichung eine angemessene Testabdeckung besteht. Und eine enge Zusammenarbeit zwischen der IT stellt sicher, dass die Warnplattformen, die Sie schnell informieren, wenn ein Problem mit einer Veröffentlichung vorliegt, richtig ausgerichtet und eingerichtet sind. In einigen CD-Umgebungen können Entwickler direkt auf Probleme reagieren.
2. Vergessen Sie nicht die Antwort: Ein unverhältnismäßig großer Teil der Zeit, die für die Planung moderner Softwarebereitstellung aufgewendet wird, wird für die Weiterentwicklung des Codes verwendet. Der Erfolg zukünftiger Iterationen hängt jedoch von einer erfolgreichen Reaktion auf bestehende Iterationen ab. Unternehmen müssen viel Zeit für Rückgängigmachungsprozesse und das System zur Reaktion auf Probleme aufwenden, was sowohl ein organisatorisches Problem (wer ist auf Abruf verfügbar) als auch ein technisches Problem (so wenige Schritte wie möglich erforderlich) ist.

Ein Ansatz, um auf diese beiden Herausforderungen zu reagieren, besteht darin, das nachzuahmen, was die Startups können: die Anwendung vom ersten Tag an mit dem CD-Prozess zu erstellen. Da die meisten Organisationen bereits über vorhandene Anwendungen verfügen, ist dies nicht möglich. Der beste Weg, dies zu tun, besteht darin, parallel eine neue Version der Anwendung zu erstellen und dabei von Anfang an CD zu nutzen. Dies wird einige Zeit dauern, aber wenn Ihre Anwendung mit einer Servicearchitektur und einer starken API-Schicht für das Backend erstellt wurde, sollte dies kein unüberwindbares Problem sein.

Der wahre Erfolg besteht darin, Magie in die Realität umzusetzen. Und viele der Organisationen, die CD erfolgreich implementiert haben, haben zunächst mit Prozessen wie kontinuierlicher Integration begonnen. Sie haben ihren Ansatz, ihre Tools und ihre Teamstruktur so verfeinert, dass sie das Vertrauen hatten, mit CD fortzufahren. Sie haben sich auch auf Ausführung und Nachhaltigkeit konzentriert, nicht nur auf mehr Releases direkt in die Produktion.

Ohne Vertrauen in die Sache wird der Tool-Markt den Weg weisen. Und wenn Ihre Anwendung sich für CD eignet und Sie bereit sind, es richtig zu machen, sind Sie bereit für die kontinuierliche Bereitstellung.

Dies ist einer von zwei PagerDuty Beiträgen zu Continuous. Schauen Sie sich unseren zweiten an: Kontinuierlich – Schnell erstellen, unterbrechen und reparieren