Methodik zur Bereitstellung von Projekten, die in Slack verwendet wird.

Die Veröffentlichung eines neuen Projekt-Release in die Produktionsumgebung erfordert ein sorgfältiges Gleichgewicht zwischen der Bereitgeschwindigkeit und der Zuverlässigkeit der Lösung. Bei Slack schätzt man schnelle Iterationen, kurze Feedbackzyklen und eine zügige Reaktion auf Nutzeranfragen. Außerdem gibt es im Unternehmen Hunderte von Programmierern, die bestrebt sind, möglichst produktiv zu arbeiten.

Die Autoren des Materials, dessen Übersetzung wir heute veröffentlichen, sagen, dass ein Unternehmen, das sich solchen Werten verschrieben hat und gleichzeitig wächst, kontinuierlich seine Bereitstellungssysteme verbessern muss. Unternehmen sollten Kraft in die Transparenz und Zuverlässigkeit ihrer Arbeitsprozesse investieren, damit diese Prozesse dem Umfang des Projekts entsprechen. Hier wird von den Arbeitsprozessen gesprochen, die sich bei Slack entwickelt haben, und von einigen Lösungen, die das Unternehmen zur bestehenden Bereitstellungssystematik geführt haben.

Wie die Prozesse der Projektbereitstellung heute funktionieren

Jeder PR (Pull-Request) bei Slack muss unbedingt einer Code-Überprüfung unterzogen werden und alle Tests erfolgreich bestehen. Erst nachdem diese Bedingungen erfüllt sind, kann der Programmierer seinen Code mit dem Master-Branch des Projekts zusammenführen. Das Deployment dieses Codes erfolgt jedoch nur während der Arbeitszeiten nach nordamerikanischer Zeit. Dadurch sind wir, da unsere Mitarbeiter an ihren Arbeitsplätzen sind, vollständig bereit, unerwartete Probleme zu lösen.

Jeden Tag führen wir etwa 12 geplante Deployments durch. Während jedes Deployments ist der Programmierer, der als Hauptverantwortlicher für das Deployment bestimmt ist, für die Veröffentlichung einer neuen Build in die Produktionsumgebung zuständig. Dies ist ein mehrstufiger Prozess, der eine reibungslose Veröffentlichung der Build in den Betriebsmodus gewährleistet. Durch diesen Ansatz können wir Fehler entdecken, bevor sie alle unsere Nutzer betreffen. Wenn es zu viele Fehler gibt, kann die Bereitstellung der Build zurückgesetzt werden. Sollte jedoch ein spezifisches Problem nach dem Release entdeckt werden, kann dafür leicht ein Patch veröffentlicht werden.

Die Benutzeroberfläche des Checkpoint-Systems, das bei Slack für die Projektbereitstellung verwendet wird

Der Prozess der Bereitstellung eines neuen Releases in der Produktionsumgebung lässt sich in vier Schritte unterteilen.

▍1. Erstellung eines Release-Zweigs

Jedes Release beginnt mit einem neuen Release-Zweig, der einen Punkt in unserer Git-Geschichte darstellt. Dies ermöglicht es, dem Release Tags zuzuweisen und bietet einen Ort, an dem zeitnahe Korrekturen für Fehler vorgenommen werden können, die während der Vorbereitung des Releases für den Produktionsbetrieb gefunden wurden.

▍2. Bereitstellung in einer Zwischenumgebung

Der nächste Schritt besteht darin, den Build auf den Staging-Servern bereitzustellen und automatisierte Tests zur allgemeinen Funktionsfähigkeit des Projekts (Smoke-Test) durchzuführen. Die Zwischenumgebung ist eine Produktionsumgebung, in die kein externer Verkehr gelangt. In dieser Umgebung führen wir zusätzliche manuelle Tests durch. Dies gibt uns zusätzliche Sicherheit, dass das geänderte Projekt korrekt funktioniert. Allein automatisierte Tests reichen nicht aus, um eine solche Sicherheit zu erlangen.

▍3. Bereitstellung in Dogfood- und Canary-Umgebungen

Die Bereitstellung in der Produktion beginnt mit der Dogfood-Umgebung, die aus einer Gruppe von Hosts besteht, die unsere internen Slack Arbeitsbereiche bedienen. Da wir äußerst aktive Slack-Nutzer sind, hat dieser Ansatz geholfen, viele Fehler in frühen Phasen der Bereitstellung zu entdecken. Nachdem wir sichergestellt haben, dass die Grundfunktionalität des Systems nicht beeinträchtigt wurde, wird der Build in der Canary-Umgebung bereitgestellt. Diese besteht aus Systemen, die etwa 2 % des Produktionsverkehrs erhalten.

▍4. Stufenweise Bereitstellung in der Produktion

Wenn die Überwachungswerte des neuen Releases stabil sind und wir nach der Bereitstellung des Projekts in der Canary-Umgebung keine Beschwerden erhalten haben, fahren wir mit der schrittweisen Umstellung der Produktionsserver auf das neue Release fort. Der Bereitstellungsprozess ist in die folgenden Phasen unterteilt: 10 %, 25 %, 50 %, 75 % und 100 %. Dadurch können wir den Produktionsverkehr langsam an das neue Release des Systems übergeben. Dabei haben wir Zeit, die Situation zu analysieren, falls Anomalien auftreten.

▍Was tun, wenn während der Bereitstellung etwas schiefgeht?

Das Ändern des Codes ist immer mit Risiken verbunden. Doch wir bewältigen dies dank gut vorbereiteter "Deploy-Manager", die den Prozess der Einführung neuer Releases in die Produktion leiten, die Überwachungskennzahlen im Blick behalten und die Arbeit der Programmierer, die den Code veröffentlichen, koordinieren.

Wenn tatsächlich etwas schiefgeht, versuchen wir, das Problem so früh wie möglich zu entdecken. Wir untersuchen das Problem, finden den PR, der die Fehler verursacht, rollen ihn zurück, analysieren gründlich und erstellen einen neuen Build. Leider bleibt das Problem manchmal unentdeckt, bis das Projekt in die Produktion geht. In einem solchen Fall ist es am wichtigsten, den Betrieb des Dienstes wiederherzustellen. Daher rollen wir sofort auf den vorherigen stabilen Build zurück, bevor wir mit der Problemuntersuchung beginnen.

Baukästen für das Deployment-System

Betrachten wir die Technologien, die unserer Projektdistributionssystem zugrunde liegen.

▍Schnelle Deployments

Der oben beschriebene Arbeitsprozess mag im Rückblick offensichtlich erscheinen. Aber unser Deploymentsystem wurde nicht von heute auf morgen so.

Als das Unternehmen viel kleiner war, konnte unsere gesamte Anwendung auf 10 Amazon EC2-Instanzen laufen. Ein Deployment des Projekts bedeutete in dieser Situation, rsync für die schnelle Synchronisierung aller Server anzuwenden. Früher war der neue Code nur einen Schritt von der Produktion entfernt, dargestellt durch eine Entwicklungsumgebung. Builds wurden in dieser Umgebung erstellt und getestet und gingen dann direkt in die Produktion. Es war sehr einfach, sich in einem solchen System zurechtzufinden; es ermöglichte jedem Programmierer, jederzeit den von ihm geschriebenen Code zu deployen.

Mit dem Wachstum unserer Kundenanzahl wuchs auch die Infrastruktur, die für den Betrieb des Projekts erforderlich war. Bald, angesichts des fortwährenden Wachstums des Systems, konnte unser Deploymentsmodell, das auf dem Versand neuen Codes an die Server basierte, seiner Aufgabe nicht mehr gerecht werden. Besonders die Hinzufügung jedes neuen Servers erhöhte die Zeit, die für das Deployment benötigt wurde. Selbst Strategien, die auf paralleler Anwendung von rsync basieren, haben bestimmte Einschränkungen.

Letztendlich haben wir dieses Problem gelöst, indem wir auf ein vollständig paralleles Deployment-System umgestiegen sind, das nicht wie das alte System strukturiert ist. Genauer gesagt, nun haben wir den Code nicht mehr auf die Server übertragen, indem wir ein Synchronisierungsskript verwendet haben. Jetzt hat jeder Server selbständig die neue Version geladen, indem er durch die Beobachtung der Schlüsseländerung in Consul informiert wurde, dass dies notwendig war. Die Server luden den Code parallel. Dies ermöglichte es uns, eine hohe Geschwindigkeit beim Deployment aufrechtzuerhalten, selbst in einer ständig wachsenden Systemumgebung.

1. Produktionsserver beobachten den Consul-Schlüssel. 2. Der Schlüssel ändert sich, was den Servern mitteilt, dass sie mit dem Laden des neuen Codes beginnen müssen. 3. Die Server laden Tarball-Dateien mit dem Anwendungs-Code herunter.

▍Atomare Deployments

Eine weitere Lösung, die uns geholfen hat, ein mehrstufiges Deployment-System zu erreichen, war das atomare Deployment.

Vor der Verwendung atomarer Deployments konnte jedes Deployment zu einer Vielzahl von Fehlermeldungen führen. Der Grund dafür war, dass der Prozess des Kopierens neuer Dateien auf die Produktionsserver nicht atomar war. Dies führte zu einem kurzen Zeitfenster, in dem der Code, der neue Funktionen aufrief, verfügbar war, bevor diese Funktionen selbst verfügbar wurden. Wenn dieser Code aufgerufen wurde, führte dies zu internen Fehlern. Dies äußerte sich in fehlgeschlagenen API-Anfragen und "kaputten" Webseiten.

Das Team, das sich mit diesem Problem beschäftigte, löste es, indem es das Konzept von "heißen" (hot) und "kalten" (cold) Verzeichnissen einführte. Der Code im "heißen" Verzeichnis ist für die Verarbeitung des Produktionsverkehrs verantwortlich. In den "kalten" Verzeichnissen wird der Code während des Betriebs des Systems nur für die Nutzung vorbereitet. Während des Deployments wird der neue Code in ein unbenutztes "kaltes" Verzeichnis kopiert. Dann, sobald auf dem Server keine aktiven Prozesse mehr laufen, erfolgt ein sofortiger Wechsel der Verzeichnisse.

1. Entpacken des Anwendungs-Codes in das "kalte" Verzeichnis. 2. Umschalten auf das "kalte" Verzeichnis, das "heiß" wird (atomare Operation).

Ergebnisse: Verschiebung des Fokus auf Zuverlässigkeit.

Im Jahr 2018 erreichte das Projekt Ausmaße, bei denen die sehr schnelle Bereitstellung die Stabilität des Produkts zu schädigen begann. Wir hatten ein ziemlich fortschrittliches Bereitstellungssystem, in das wir viel Aufwand und Zeit investiert hatten. Wir mussten lediglich die Prozesse der Bereitstellungsorganisation umstrukturieren und verbessern. Wir hatten uns zu einem ziemlich großen Unternehmen entwickelt, dessen Entwicklungen weltweit für die Bereitstellung einer unterbrechungsfreien Kommunikation und zur Lösung wichtiger Aufgaben eingesetzt wurden. Daher lag unser Fokus auf der Zuverlässigkeit.

Wir mussten den Prozess der Bereitstellung neuer Slack-Versionen sicherer gestalten. Diese Notwendigkeit führte uns zur Verbesserung unseres Bereitstellungssystems. Tatsächlich haben wir oben dieses verbesserte System diskutiert. Im Inneren des Systems nutzen wir weiterhin Technologien für schnelle und atomare Bereitstellungen. Was sich geändert hat, ist die Art und Weise, wie die Bereitstellung tatsächlich erfolgt. Unser neues System ist für die schrittweise Bereitstellung neuen Codes auf verschiedenen Ebenen in unterschiedlichen Umgebungen konzipiert. Jetzt verwenden wir anspruchsvollere Hilfsmittel und Monitoring-Tools als zuvor. Dies ermöglicht es uns, Fehler zu erkennen und zu beheben, lange bevor sie die Chance haben, den Endbenutzer zu erreichen.

Aber wir haben nicht vor, auf dem Erreichten auszuruhen. Wir verbessern dieses System ständig, indem wir anspruchsvollere Hilfsmittel und Automatisierungstools einsetzen.

Liebe Leser! Wie ist der Prozess der Bereitstellung neuer Projektversionen dort, wo Sie arbeiten?

Quelle: habr.com