🔎 👩🏽 👪 Von Slack verwendete Projektbereitstellungsmethode 🏄 👮 🧖

Der Abschluss einer neuen Projektversion in der Produktion erfordert ein sorgfältiges Gleichgewicht zwischen der Bereitstellungsgeschwindigkeit und der Zuverlässigkeit der Lösung. Slack schätzt schnelle Iterationen, kurze Rückkopplungsschleifen und die Reaktion auf Benutzeranforderungen. Darüber hinaus hat das Unternehmen Hunderte von Programmierern, die nach höchstmöglicher Produktivität streben.

Die Autoren des Materials, dessen Übersetzung wir heute veröffentlichen, sagen, dass ein Unternehmen, das sich an solche Werte halten und gleichzeitig wachsen möchte, sein Projektbereitstellungssystem ständig verbessern sollte. Das Unternehmen muss in die Transparenz und Zuverlässigkeit der Arbeitsprozesse investieren, um sicherzustellen, dass diese Prozesse dem Umfang des Projekts entsprechen. Hier werden wir über die Arbeitsprozesse sprechen, die in Slack entwickelt wurden, und über einige der Lösungen, die das Unternehmen dazu veranlasst haben, das heute vorhandene Projektbereitstellungssystem zu verwenden.

Wie Projektbereitstellungsprozesse heute funktionieren

Jede PR (Pull Request) in Slack muss einer Codeüberprüfung unterzogen werden und alle Tests erfolgreich bestehen. Erst wenn diese Bedingungen erfüllt sind, kann ein Programmierer seinen Code mit dem Hauptzweig des Projekts zusammenführen. Die Bereitstellung eines solchen Codes erfolgt jedoch nur während der Geschäftszeiten gemäß der nordamerikanischen Zeit. Infolgedessen sind wir aufgrund der Tatsache, dass unsere Mitarbeiter bei der Arbeit sind, voll und ganz darauf vorbereitet, unerwartete Probleme zu lösen.

Jeden Tag führen wir ungefähr 12 geplante Bereitstellungen durch. Während jeder Bereitstellung ist der Programmierer, der als Hauptbereitstellung festgelegt ist, dafür verantwortlich, die neue Baugruppe in die Produktion zu bringen. Dies ist ein mehrstufiger Prozess, der einen reibungslosen Abschluss der Baugruppe im Arbeitsmodus ermöglicht. Dank dieses Ansatzes können wir Fehler erkennen, bevor sie alle unsere Benutzer betreffen. Wenn zu viele Fehler vorliegen, kann die Bereitstellung der Assembly zurückgesetzt werden. Wenn nach der Veröffentlichung ein bestimmtes Problem festgestellt wird, kann ein Fix für dieses Problem problemlos freigegeben werden.

Die Schnittstelle des Checkpoint-Systems, die von Slack zum Bereitstellen von Projekten verwendet wird.

Der Prozess zum Bereitstellen einer neuen Version in der Produktion kann in vier Schritten dargestellt werden.

▍1. Erstellen eines Release-Zweigs

Jede Veröffentlichung beginnt mit einem neuen Veröffentlichungszweig ab dem Moment in unserer Git-Geschichte. Auf diese Weise können Sie der Version Tags zuweisen und betriebliche Korrekturen für Fehler vornehmen, die bei der Vorbereitung der Version für die Freigabe in der Produktion festgestellt wurden.

▍2. Zwischenbereitstellung

Der nächste Schritt besteht darin, die Assembly auf Staging-Servern bereitzustellen und einen automatischen Test für die Gesamtleistung des Projekts durchzuführen (Rauchtest). Eine Zwischenumgebung ist eine Produktionsumgebung, in die der externe Verkehr nicht fällt. In dieser Umgebung führen wir zusätzliche manuelle Tests durch. Dies gibt uns zusätzliches Vertrauen, dass das geänderte Projekt ordnungsgemäß funktioniert. Automatisierte Tests allein reichen nicht aus, um dieses Vertrauen zu gewinnen.

▍3. Einsatz in Hundefutter und kanarischen Umgebungen

Die Bereitstellung in der Produktion beginnt mit einer Hundefutterumgebung, die durch eine Reihe von Hosts repräsentiert wird, die unsere internen Slack-Arbeitsbereiche bedienen. Da wir sehr aktive Benutzer von Slack sind, hat die Verwendung dieses Ansatzes dazu beigetragen, viele Fehler in den frühen Phasen der Bereitstellung zu erkennen. Nachdem wir sichergestellt haben, dass die Grundfunktionalität des Systems nicht beeinträchtigt wird, wird die Baugruppe in einer kanarischen Umgebung bereitgestellt. Es ist ein System, das ungefähr 2% des Produktionsverkehrs empfängt.

▍4. Allmählicher Abschluss in der Produktion

Wenn sich die Überwachungsindikatoren der neuen Version als stabil herausstellen und wir nach der Bereitstellung des Projekts in der kanarischen Umgebung keine Beschwerden erhalten haben, setzen wir die schrittweise Übertragung von Produktionsservern auf die neue Version fort. Der Bereitstellungsprozess ist in die folgenden Phasen unterteilt: 10%, 25%, 50%, 75% und 100%. Infolgedessen können wir den Produktionsverkehr langsam auf eine neue Systemversion übertragen. Gleichzeitig haben wir Zeit, die Situation zu untersuchen, falls einige Anomalien aufgedeckt werden.

▍Was passiert, wenn während des Einsatzes ein Fehler aufgetreten ist?

Änderungen am Code sind immer ein Risiko. Dies können wir jedoch dank unserer gut ausgebildeten „Deployment Manager“ bewältigen, die den Prozess der Einführung einer neuen Version in die Produktion verwalten, die Überwachungsleistung überwachen und die Arbeit der Programmierer koordinieren, die Code veröffentlichen.

Für den Fall, dass wirklich etwas schief gelaufen ist, versuchen wir, das Problem so früh wie möglich zu erkennen. Wir untersuchen das Problem, finden die PR, die die Fehler verursacht, rollen sie zurück, analysieren sie sorgfältig und erstellen eine neue Baugruppe. Es stimmt, manchmal bleibt das Problem unbemerkt, bevor das Projekt in Produktion geht. In einer solchen Situation ist es am wichtigsten, den Dienst wiederherzustellen. Bevor wir mit der Untersuchung des Problems beginnen, kehren wir daher sofort zur vorherigen Arbeitsbaugruppe zurück.

Bereitstellungsbausteine

Berücksichtigen Sie die Technologien, die unserem Projektbereitstellungssystem zugrunde liegen.

▍Schnelle Bereitstellungen

Der oben beschriebene Workflow scheint im Nachhinein völlig offensichtlich zu sein. Unser Bereitstellungssystem ist jedoch nicht sofort so weit gekommen.

Wenn das Unternehmen erheblich kleiner war, konnte unsere gesamte Anwendung auf 10 Amazon EC2-Instanzen ausgeführt werden. Das Bereitstellen eines Projekts in dieser Situation bedeutete die Verwendung von rsync, um alle Server schnell zu synchronisieren. Zuvor war der neue Code nur durch einen Schritt von der Produktion getrennt, dargestellt durch eine Zwischenumgebung. Baugruppen wurden in einer solchen Umgebung erstellt und getestet und gingen dann direkt in die Produktion. Das Verständnis eines solchen Systems war sehr einfach und ermöglichte es jedem Programmierer, den von ihm geschriebenen Code jederzeit bereitzustellen.

Mit der Anzahl unserer Kunden wuchs auch die Größe der Infrastruktur, die für den Betrieb des Projekts erforderlich ist. Angesichts des stetigen Wachstums des Systems konnte unser Bereitstellungsmodell, das auf dem Senden von neuem Code an die Server basiert, seine Aufgabe bald nicht mehr erfüllen. Das Hinzufügen jedes neuen Servers bedeutete nämlich eine Verlängerung der Zeit, die zum Abschließen der Bereitstellung erforderlich war. Selbst Strategien, die auf der parallelen Verwendung von rsync basieren, weisen bestimmte Einschränkungen auf.

Infolgedessen haben wir dieses Problem gelöst, indem wir auf ein vollständig paralleles Bereitstellungssystem umgestellt haben, das nicht wie das alte System angeordnet war. Jetzt haben wir den Code nicht mit dem Synchronisationsskript an die Server gesendet. Jetzt lud jeder Server unabhängig eine neue Assembly herunter und erfuhr, dass dies dank der Beobachtung der Konsul-Schlüsseländerung erforderlich war. Die Server haben den Code parallel heruntergeladen. Dies ermöglichte es uns, auch in einer Umgebung mit konstantem Systemwachstum eine hohe Bereitstellungsgeschwindigkeit aufrechtzuerhalten.

1. Produktionsserver überwachen den Konsulschlüssel. 2. Der Schlüssel ändert sich. Dies teilt den Servern mit, dass sie mit dem Herunterladen von neuem Code beginnen müssen. 3. Server laden Tarball-Dateien mit Anwendungscode hoch

▍Atomische Bereitstellungen

Eine andere Lösung, die uns zu einem mehrstufigen Bereitstellungssystem verhalf, war die atomare Bereitstellung.

Vor der Verwendung von atomaren Bereitstellungen kann jede Bereitstellung zu einer großen Anzahl von Fehlermeldungen führen. Tatsache ist, dass das Kopieren neuer Dateien auf Produktionsserver nicht atomar war. Dies führte zu einer kurzen Zeitspanne, in der der Code, in dem die neuen Funktionen aufgerufen wurden, verfügbar war, bevor die Funktionen selbst verfügbar wurden. Wenn ein solcher Code aufgerufen wurde, wurden interne Fehler zurückgegeben. Dies manifestierte sich in erfolglosen API-Anforderungen und in fehlerhaften Webseiten.

Das Team, das sich mit diesem Problem befasste, löste es, indem es das Konzept der Verzeichnisse „heiß“ (heiß) und „kalt“ (kalt) einführte. Der Code im "heißen" Verzeichnis ist für die Verarbeitung des Produktionsverkehrs verantwortlich. Und in den "kalten" Verzeichnissen wird der Code, während das System ausgeführt wird, nur für die Verwendung vorbereitet. Während der Bereitstellung wird der neue Code in das nicht verwendete "kalte" Verzeichnis kopiert. Wenn dann keine aktiven Prozesse auf dem Server vorhanden sind, werden die Verzeichnisse sofort gewechselt.

1. Entpacken Sie den Anwendungscode in ein "kaltes" Verzeichnis. 2. Umschalten des Systems in ein "kaltes" Verzeichnis, das "heiß" wird (atomare Operation)

Fazit: Eine Verlagerung des Schwerpunkts auf Zuverlässigkeit

Im Jahr 2018 wuchs das Projekt in einem solchen Ausmaß, dass eine sehr schnelle Bereitstellung die Stabilität des Produkts beeinträchtigte. Wir hatten ein sehr fortschrittliches Bereitstellungssystem, in das wir viel Zeit und Mühe investiert haben. Wir mussten nur die Bereitstellungsorganisationsprozesse umstrukturieren und verbessern. Wir sind zu einem ziemlich großen Unternehmen geworden, dessen Entwicklung weltweit genutzt wurde, um eine unterbrechungsfreie Kommunikation zu organisieren und wichtige Probleme zu lösen. Daher lag der Schwerpunkt unserer Aufmerksamkeit auf Zuverlässigkeit.

Wir mussten den Prozess der Bereitstellung neuer Slack-Versionen sicherer machen. Dieser Bedarf führte dazu, dass wir unser Bereitstellungssystem verbesserten. Tatsächlich haben wir oben dieses verbesserte System diskutiert. Im Darm des Systems setzen wir weiterhin Technologien für einen schnellen und atomaren Einsatz ein. Die genaue Ausführung der Bereitstellung wurde geändert. Unser neues System wurde entwickelt, um schrittweise neuen Code auf verschiedenen Ebenen in verschiedenen Umgebungen bereitzustellen. Jetzt verwenden wir fortschrittlichere Hilfstools und Tools zur Überwachung des Systems als zuvor. Dies gibt uns die Möglichkeit, Fehler zu erkennen und zu beseitigen, lange bevor sie den Endbenutzer erreichen können.

Aber wir werden hier nicht aufhören. Wir verbessern dieses System ständig mit fortschrittlicheren Hilfswerkzeugen und Automatisierungswerkzeugen.

Liebe Leser! Wie ist der Prozess der Bereitstellung neuer Projektversionen bei Ihnen?

Von Slack verwendete Projektbereitstellungsmethode