Schneller mit kontinuierlicher Lieferung

Vor über 10 Jahren haben wir bei Amazon ein Projekt durchgeführt, um zu verstehen, wie schnell unsere Teams Ideen in hochwertige Produktionssysteme verwandeln. Dies hat uns dazu veranlasst, unseren Softwaredurchsatz zu messen, um die Ausführungsgeschwindigkeit zu verbessern. Wir stellten fest, dass es vom Einchecken des Codes bis zur Produktion durchschnittlich 16 Tage dauerte. Bei Amazon begannen die Teams mit einer Idee und brauchten dann in der Regel anderthalb Tage, um Code zu schreiben, um die Idee zum Leben zu erwecken. Wir haben weniger als eine Stunde gebraucht, um den neuen Code zu erstellen und bereitzustellen. Den Rest der Zeit, fast 14 Tage, haben wir darauf gewartet, dass die Teammitglieder einen Build starten, Bereitstellungen durchführen und Tests durchführen. Am Ende des Projekts empfahlen wir, unsere Post-Check-in-Prozesse zu automatisieren, um die Ausführungsgeschwindigkeit zu verbessern. Ziel war es, Verzögerungen zu vermeiden und die Qualität zu erhalten oder sogar zu verbessern.

Kern dieser Empfehlung war ein kontinuierliches Verbesserungsprogramm, um die Ausführungsgeschwindigkeit zu erhöhen. Wir haben unsere Entscheidung, unsere Ausführungsgeschwindigkeit zu verbessern, auf das Führungsprinzip des Beharrens auf den höchsten Standards gestützt. Bei diesem Prinzip geht es darum, unablässig hohe Standards zu setzen, die Messlatte immer höher zu legen und qualitativ hochwertige Produkte, Dienstleistungen und Prozesse bereitzustellen. Unsere Führungsprinzipien beschreiben, wie Amazon Geschäfte tätigt, wie Führungskräfte führen und wie wir den Kunden im Mittelpunkt unserer Entscheidungen halten.

Amazon hatte bereits Tools für die Softwareentwicklung entwickelt, um unsere Softwareentwickler produktiver zu machen. Wir haben unser eigenes zentralisiertes und gehostetes Build-System, Brazil, erstellt, das eine Reihe von Befehlen auf einem Server ausführt, um ein Artefakt zu generieren, das bereitgestellt werden kann. Zu diesem Zeitpunkt hörte Brasilien nicht auf Quellcode-Änderungen. Eine Person musste einen Build initiieren. Wir hatten auch unser eigenes Bereitstellungssystem, Apollo, für das ein Build-Artefakt hochgeladen werden musste, um eine Bereitstellung zu initiieren. Angespornt durch das Interesse an einer kontinuierlichen Lieferung in der Branche, haben wir unser eigenes System, Pipelines, gebaut, um den Software-Lieferprozess zwischen Brasilien und Apollo zu automatisieren.

Unsere Freigabeprozesse, einschließlich unserer Pipelines und Bereitstellungssysteme, müssen so ausgelegt sein, dass diese Fehler so schnell wie möglich erkannt werden und sich nicht auf unsere Kunden auswirken. Wir müssen sicherstellen, dass unsere Freigabeprozesse korrekt konfiguriert sind und dass unser Build-Artefakt wie vorgesehen funktioniert.

Bereitstellungshygiene: Die grundlegendste Form von Bereitstellungstests stellt sicher, dass das neu bereitgestellte Artefakt gestartet werden und auf die Arbeit reagieren kann. Im Rahmen des Workflows nach der Bereitstellung führen wir schnelle Überprüfungen durch, um sicherzustellen, dass das neu implementierte Artefakt gestartet wurde und den Datenverkehr bedient. Beispielsweise verwenden wir Lifecycle-Ereignis-Hooks in der AWS CodeDeploy AppSpec-Datei, um einfache Skripts zum Stoppen, Starten und Überprüfen der Bereitstellung auszulösen. Wir überprüfen auch, ob wir über genügend Kapazität verfügen, um den Kundenverkehr zu bedienen. Wir haben Techniken wie ein Minimum an gesunden Hosts in CodeDeploy entwickelt, um sicherzustellen, dass wir immer über genügend Kapazität verfügen, um unsere Kunden zu bedienen. Wenn die Implementierungsengine einen Fehler erkennt, sollte sie die Änderung zurücksetzen, um die Zeit zu minimieren, in der Kunden einen Fehler bemerken.

Testen vor der Produktion: Eine der Best Practices von Amazon ist die Automatisierung von Unit-, Integrations- und Pre-Production-Tests und das Hinzufügen dieser Tests in unsere Pipeline. Wir bestehen darauf, Last- und Sicherheitstests durchzuführen, um diese Tests in unsere Pipelines aufzunehmen. Mit Unit-Tests sind alle Tests gemeint, die Sie möglicherweise auf Ihrem Build-Computer ausführen möchten, einschließlich Stilprüfungen, Codeabdeckung, Codekomplexität und mehr. Unter Integrationstests verstehen wir alle Off-Box-Tests wie Fehlerinjektion, automatisierte Browsertests und dergleichen. Es gibt viele großartige Artikel zu Unit- und Integrationstests, daher werde ich hier nicht näher darauf eingehen.

Mit unseren Unit- und Integrationstests möchten wir sicherstellen, dass das Verhalten unserer Build-Artefakte funktionell korrekt ist. Je mehr Validierungen wir durchführen, desto geringer ist das Risiko, dass ein Defekt unseren Kunden angezeigt wird. Um die Zeit zu verkürzen, die erforderlich ist, um ein Produkt in die Hände unserer Kunden zu bekommen, versuchen wir, einen Defekt so früh wie möglich im Freigabeprozess zu erkennen. Im Allgemeinen bedeutet dies, dass Sie bei kleineren und schnelleren Tests bei Problemen mit Ihren Änderungen schneller eine Rückmeldung erhalten.

Bei Amazon verwenden wir auch eine Technik, die wir Tests vor der Produktion nennen. Eine Vorproduktionsumgebung ist der letzte Ort, an dem Tests durchgeführt werden, bevor wir unsere Änderungen in der Produktion implementieren. Bei einem Umgebungstest vor der Produktion wird die Produktionskonfiguration des Systems verwendet, sodass sie genau wie ein Produktionssystem funktioniert. Dieser Ansatz hat zwei Vorteile. Zunächst testen Vorproduktionsumgebungen die Produktionskonfiguration, um sicherzustellen, dass der Dienst eine ordnungsgemäße Verbindung zu allen Produktionsressourcen, einschließlich Produktionsdatenspeichern, herstellen kann. Zweitens wird sichergestellt, dass das System korrekt mit den APIs der Produktionsservices interagiert, von denen es abhängt. Vorproduktionsumgebungen werden nur von dem Team verwendet, das diesen Service besitzt, und es wird kein Datenverkehr von Kunden gesendet. Das Ausführen von Tests vor der Produktion erhöht unser Vertrauen, dass derselbe Code und dieselbe Konfiguration in der Produktion funktionieren.

Validierung in der Produktion: Ein Code-Release an Kunden erfolgt nicht auf einmal, sondern in Schritten. Die Gefahr möglicher Auswirkungen von Mängeln bei allen Kunden gleichzeitig ist zu groß. Stattdessen stellen wir Zellen bereit - eine völlig unabhängige Instanz eines Dienstes. Wenn wir Änderungen an unseren ersten Kunden in unserer ersten Zelle vornehmen, sind wir äußerst vorsichtig. Wir lassen nur eine kleine Anzahl von Kunden die neue Änderung sehen und sammeln Feedback, ob der neue Code funktioniert. Wir überwachen die Anzahl der Fehler, die unsere Services nach einem kanarischen Einsatz verursachen. Wenn die Fehlerrate steigt, wird die Änderung automatisch zurückgesetzt. Beispielsweise können wir auf 3.000 positive Datenpunkte ohne negative Datenpunkte warten, bevor wir mit der Bereitstellung fortfahren.

Eine Komplikation kann entstehen, wenn Ihre automatisierten Tests einen Anwendungsfall verpassen. Wir bemühen uns, alle Fehler mit unseren strukturierten und wiederholbaren Tests, ob automatisiert oder manuell, abzufangen. Aber auch wenn wir uns anstrengen, kann ein Defekt durchrutschen. Um unsere Tests zu testen, lassen wir die neue Änderung in der Produktion für einen festen Zeitraum, um zu sehen, ob ein Nicht-Teammitglied ein Problem findet. Wir haben viel Zeit damit verbracht, zu überlegen, ob wir Änderungen nur in der Produktion lassen oder wie lange wir nach einer kanarischen Bereitstellung warten sollen, bevor wir sie für den Rest der Bereitstellungsgruppe bereitstellen. Viele unserer Teams haben beschlossen, zusätzlich zur Erfassung positiver Datenpunkte eine bestimmte Zeitspanne abzuwarten, bevor sie unsere Bereitstellungsroutine durchlaufen. Die Wartezeit einer Pipeline hängt stark vom Team ab. Einige Teams warten Stunden, andere Minuten. Je höher die Auswirkung und je länger die Zeit zur Behebung des Problems ist, desto langsamer ist der Freigabeprozess.

Nachdem wir das Vertrauen in die erste Zelle gewonnen haben, werden wir den neuen Code mehr und mehr Kunden zur Verfügung stellen, bis er vollständig freigegeben ist. Genau wie beim kanarischen Einsatz warten wir, bis wir das Vertrauen in den Einsatz in der ersten neuen Zelle haben, bevor wir mit der nächsten Zelle fortfahren. Je mehr Vertrauen wir in das Build-Artefakt gewinnen, desto weniger Zeit wird für die Überprüfung der Codeänderung aufgewendet. Dies führt zu einem Muster, bei dem wir versuchen, so schnell wie möglich vom Check-in zu unserem ersten Produktionskunden zu gelangen. Nachdem wir jedoch in der Produktion sind, geben wir den neuen Code langsam an die Kunden weiter, um zusätzliches Vertrauen zu gewinnen, während wir den Rest unserer Bereitstellungen schrittweise beschleunigen.

Um sicherzustellen, dass unsere Produktionssysteme weiterhin Kundenanforderungen erfüllen, generieren wir synthetischen Datenverkehr auf unseren Systemen. Wir möchten schnelles Feedback, wenn unser Service nicht ordnungsgemäß funktioniert. Daher führen wir unsere synthetischen Tests mindestens jede Minute durch. Wir entwerfen synthetische Tests, um sicherzustellen, dass unsere laufenden Prozesse fehlerfrei sind und alle Abhängigkeiten getestet werden. Dazu gehört häufig das Testen aller öffentlich zugänglichen APIs.

Kontrollieren, wann Software veröffentlicht wird: Um die Sicherheit unserer Softwareversionen zu kontrollieren, haben wir Mechanismen entwickelt, mit denen wir die Geschwindigkeit steuern können, mit der sich Änderungen durch unsere Pipeline bewegen. Wir verwenden Metriken, Zeitfenster und Sicherheitsprüfungen, um zu steuern, wann unsere Software freigegeben wird.

Pipelines können konfiguriert werden, um eine Bereitstellung zu verhindern, wenn ein Alarm aufgrund einer Änderung der Metriken ausgelöst wird. Wir verwenden Metriken, und wir haben Alarme bezüglich des Zustands unserer Systeme, des Zustands unserer Zellen, der Availability Zones und Regionen und fast alles, was Ihnen sonst noch einfällt. Wir konfigurieren unsere Pipelines so, dass die Bereitstellung von Code gestoppt wird, wenn eine wichtige Metrik einen Alarm ausgelöst hat. Manchmal muss ein Team jedoch einen Fix bereitstellen, damit der Alarm des Systems behoben wird. In diesem Szenario können Teams die Alarme außer Kraft setzen, um zu verhindern, dass Änderungen über eine Pipeline übertragen werden.

Unsere Pipelines können ein Zeitfenster festlegen, in dem Änderungen in einer Pipeline vorgenommen werden können. Teams können ihre eigenen Zeitfenster finden, um einzuschränken, wann Änderungen Kunden erreichen. AWS-Teams ziehen es vor, Software freizugeben, wenn es viele Leute gibt, die schnell auf ein Problem reagieren und es abschwächen können, das durch eine Bereitstellung verursacht wird. Um dies zu verwirklichen, legen die Teams ihre Zeitfenster im Allgemeinen so fest, dass sie nur während der Geschäftszeiten bereitgestellt werden. Andere Teams bei Amazon ziehen es vor, Software freizugeben, wenn der Kundenverkehr gering ist. Diese Zeitfenster können bei Bedarf überschrieben werden.

Wir haben auch die Möglichkeit, eine Pipeline basierend auf dem Inhalt des Build-Artefakts anzuhalten. Beispielsweise können wir ein Build-Artefakt blockieren, das ein bekanntermaßen fehlerhaftes Paket oder eine bestimmte Git-Referenz enthält. Wir haben diese Funktion verwendet, als wir festgestellt haben, dass eine Änderung an einem Paket eine Leistungsregression enthält. Wenn wir das Paket nur aus unserem Paket-Repository entfernen würden, würden Pipelines, die das fehlerhafte Paket bereits enthalten, diese fehlerhafte Änderung weiterhin für Kunden bereitstellen.

Wir haben festgestellt, dass die Teams die Automatisierung sehr zu schätzen wissen. Wir sind alle hochmotiviert, Funktionen für Kunden zu entwickeln und freizugeben, die ihr Leben verbessern, und eine kontinuierliche Lieferung macht dies nachhaltig. Wir haben gesehen, dass die Automatisierung den Ingenieuren Zeit zurückgibt, indem sie frustrierende, fehleranfällige und mühsame manuelle Arbeit beseitigt. Wir haben gezeigt, dass sich eine kontinuierliche Bereitstellung positiv auf die Qualität auswirkt. Wir haben festgestellt, dass Teams durch die Automatisierung häufig Änderungen vornehmen können, um Regressionen leichter identifizieren zu können.

Wenn Systeme neu sind, ist die zu testende Oberfläche für die meisten Teammitglieder verständlich, was einige manuelle Tests nachvollziehbar macht. Wenn jedoch die Systeme komplexer werden und sich die Teammitglieder ändern, steigt der Wert der Automatisierung. Wir automatisieren gerne unsere Systeme, damit wir uns auf die Steigerung des Kundennutzens konzentrieren können, anstatt den Prozess der Herausgabe dieser Änderungen an die Kunden von Hand zu steuern.

Seit vielen Jahren führt Amazon kontinuierliche Verbesserungsprogramme durch, die sich auf die Geschwindigkeit, mit der wir Software für Kunden veröffentlichen, und die Sicherheit dieser Releases konzentrieren. Wir haben nicht mit allen Risikoprüfungen und Tests begonnen, über die ich in diesem Artikel geschrieben habe. Im Laufe der Zeit haben wir Wege gefunden, um Risiken zu identifizieren und zu mindern.

Die Programme zur kontinuierlichen Verbesserung werden von Führungskräften auf verschiedenen Ebenen der Organisation durchgeführt. Auf diese Weise kann jeder Unternehmensleiter seinen Software-Release-Prozess an die Risiken und Auswirkungen auf sein Unternehmen anpassen. Einige unserer kontinuierlichen Verbesserungsprogramme werden in großen Teilen von Amazon ausgeführt, und manchmal führen Führungskräfte kleinerer Organisationen ihre eigenen Programme aus. Wir wissen, dass es immer Ausnahmen von der Regel gibt. Unsere Systeme verfügen über Opt-out-Mechanismen, damit Teams, die eine dauerhafte oder vorübergehende Ausnahme benötigen, nicht verlangsamt werden. Letztendlich besitzen unsere Teams das Verhalten ihrer Software und sind dafür verantwortlich, angemessen in ihren Software-Release-Prozess zu investieren.

Wir begannen damit, zu ermitteln, wo unser Schmerz war, ihn anzugehen und zu iterieren. Um diese Arbeit nachhaltig zu gestalten, mussten wir sie schrittweise durchführen und die Verbesserungen im Laufe der Zeit feiern. Als Amazon zum ersten Mal Pipelines einsetzte, waren sich viele Teams nicht sicher, ob eine kontinuierliche Bereitstellung funktionieren würde. Um die Teams zum Laufen zu bringen, haben wir sie ermutigt, ihren aktuellen Veröffentlichungsprozess, manuelle Schritte und alles in einer Pipeline zu kodieren. Für viele Teams fungierte ihre Pipeline als visuelle Schnittstelle zu ihrem Veröffentlichungsprozess, ohne dass Build-Artefakte durch einen Veröffentlichungsprozess automatisch gefördert wurden. Mit zunehmendem Vertrauen schalteten sie die Automatisierung in verschiedenen Phasen ihrer Pipeline schrittweise ein, bis sie keinen Schritt ihrer Pipeline mehr manuell auslösen mussten.

Schneller Vorlauf bis heute. Amazon ist jetzt an dem Punkt angelangt, an dem Teams beim Schreiben von neuem Code eine vollständige Automatisierung anstreben. Automatisierung ist für uns die einzige Möglichkeit, unser Geschäft weiter auszubauen.