<\/a><\/noindex><\/p>\nWie die Prozesse der Projektbereitstellung heute funktionieren<\/h2>\n \nJeder PR (Pull-Request) bei Slack muss unbedingt einer Code-\u00dcberpr\u00fcfung unterzogen werden und alle Tests erfolgreich bestehen. Erst nachdem diese Bedingungen erf\u00fcllt sind, kann der Programmierer seinen Code mit dem Master-Branch des Projekts zusammenf\u00fchren. Das Deployment dieses Codes erfolgt jedoch nur w\u00e4hrend der Arbeitszeiten nach nordamerikanischer Zeit. Dadurch sind wir, da unsere Mitarbeiter an ihren Arbeitspl\u00e4tzen sind, vollst\u00e4ndig bereit, unerwartete Probleme zu l\u00f6sen.<\/p>\n
Jeden Tag f\u00fchren wir etwa 12 geplante Deployments durch. W\u00e4hrend jedes Deployments ist der Programmierer, der als Hauptverantwortlicher f\u00fcr das Deployment bestimmt ist, f\u00fcr die Ver\u00f6ffentlichung einer neuen Build in die Produktionsumgebung zust\u00e4ndig. Dies ist ein mehrstufiger Prozess, der eine reibungslose Ver\u00f6ffentlichung der Build in den Betriebsmodus gew\u00e4hrleistet. Durch diesen Ansatz k\u00f6nnen wir Fehler entdecken, bevor sie alle unsere Nutzer betreffen. Wenn es zu viele Fehler gibt, kann die Bereitstellung der Build zur\u00fcckgesetzt werden. Sollte jedoch ein spezifisches Problem nach dem Release entdeckt werden, kann daf\u00fcr leicht ein Patch ver\u00f6ffentlicht werden.<\/p>\n
Die Benutzeroberfl\u00e4che des Checkpoint-Systems, das bei Slack f\u00fcr die Projektbereitstellung verwendet wird<\/i><\/p>\n
Der Prozess der Bereitstellung eines neuen Releases in der Produktionsumgebung l\u00e4sst sich in vier Schritte unterteilen.<\/p>\n
\u258d1. Erstellung eines Release-Zweigs<\/h3>\n \nJedes Release beginnt mit einem neuen Release-Zweig, der einen Punkt in unserer Git-Geschichte darstellt. Dies erm\u00f6glicht es, dem Release Tags zuzuweisen und bietet einen Ort, an dem zeitnahe Korrekturen f\u00fcr Fehler vorgenommen werden k\u00f6nnen, die w\u00e4hrend der Vorbereitung des Releases f\u00fcr den Produktionsbetrieb gefunden wurden.<\/p>\n
\u258d2. Bereitstellung in einer Zwischenumgebung<\/h3>\n \nDer n\u00e4chste Schritt besteht darin, den Build auf den Staging-Servern bereitzustellen und automatisierte Tests zur allgemeinen Funktionsf\u00e4higkeit des Projekts (Smoke-Test) durchzuf\u00fchren. Die Zwischenumgebung ist eine Produktionsumgebung, in die kein externer Verkehr gelangt. In dieser Umgebung f\u00fchren wir zus\u00e4tzliche manuelle Tests durch. Dies gibt uns zus\u00e4tzliche Sicherheit, dass das ge\u00e4nderte Projekt korrekt funktioniert. Allein automatisierte Tests reichen nicht aus, um eine solche Sicherheit zu erlangen.<\/p>\n
\u258d3. Bereitstellung in Dogfood- und Canary-Umgebungen<\/h3>\n \nDie Bereitstellung in der Produktion beginnt mit der Dogfood-Umgebung, die aus einer Gruppe von Hosts besteht, die unsere internen Slack Arbeitsbereiche bedienen. Da wir \u00e4u\u00dferst aktive Slack-Nutzer sind, hat dieser Ansatz geholfen, viele Fehler in fr\u00fchen Phasen der Bereitstellung zu entdecken. Nachdem wir sichergestellt haben, dass die Grundfunktionalit\u00e4t des Systems nicht beeintr\u00e4chtigt wurde, wird der Build in der Canary-Umgebung bereitgestellt. Diese besteht aus Systemen, die etwa 2 % des Produktionsverkehrs erhalten.<\/p>\n
\u258d4. Stufenweise Bereitstellung in der Produktion<\/h3>\n \nWenn die \u00dcberwachungswerte 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\u00f6nnen wir den Produktionsverkehr langsam an das neue Release des Systems \u00fcbergeben. Dabei haben wir Zeit, die Situation zu analysieren, falls Anomalien auftreten.<\/p>\n
\u258dWas tun, wenn w\u00e4hrend der Bereitstellung etwas schiefgeht?<\/h3>\n \nDas \u00c4ndern des Codes ist immer mit Risiken verbunden. Doch wir bew\u00e4ltigen dies dank gut vorbereiteter \"Deploy-Manager\", die den Prozess der Einf\u00fchrung neuer Releases in die Produktion leiten, die \u00dcberwachungskennzahlen im Blick behalten und die Arbeit der Programmierer, die den Code ver\u00f6ffentlichen, koordinieren.<\/p>\n
Wenn tats\u00e4chlich etwas schiefgeht, versuchen wir, das Problem so fr\u00fch wie m\u00f6glich zu entdecken. Wir untersuchen das Problem, finden den PR, der die Fehler verursacht, rollen ihn zur\u00fcck, analysieren gr\u00fcndlich 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\u00fcck, bevor wir mit der Problemuntersuchung beginnen.<\/p>\n
Bauk\u00e4sten f\u00fcr das Deployment-System<\/h2>\n \nBetrachten wir die Technologien, die unserer Projektdistributionssystem zugrunde liegen.<\/p>\n
\u258dSchnelle Deployments<\/h3>\n \nDer oben beschriebene Arbeitsprozess mag im R\u00fcckblick offensichtlich erscheinen. Aber unser Deploymentsystem wurde nicht von heute auf morgen so.<\/p>\n
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\u00fcr die schnelle Synchronisierung aller Server anzuwenden. Fr\u00fcher 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\u00f6glichte jedem Programmierer, jederzeit den von ihm geschriebenen Code zu deployen.<\/p>\n
Mit dem Wachstum unserer Kundenanzahl wuchs auch die Infrastruktur, die f\u00fcr den Betrieb des Projekts erforderlich war. Bald, angesichts des fortw\u00e4hrenden 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\u00fcgung jedes neuen Servers erh\u00f6hte die Zeit, die f\u00fcr das Deployment ben\u00f6tigt wurde. Selbst Strategien, die auf paralleler Anwendung von rsync basieren, haben bestimmte Einschr\u00e4nkungen.<\/p>\n
Letztendlich haben wir dieses Problem gel\u00f6st, indem wir auf ein vollst\u00e4ndig 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 \u00fcbertragen, indem wir ein Synchronisierungsskript verwendet haben. Jetzt hat jeder Server selbst\u00e4ndig die neue Version geladen, indem er durch die Beobachtung der Schl\u00fcssel\u00e4nderung in Consul informiert wurde, dass dies notwendig war. Die Server luden den Code parallel. Dies erm\u00f6glichte es uns, eine hohe Geschwindigkeit beim Deployment aufrechtzuerhalten, selbst in einer st\u00e4ndig wachsenden Systemumgebung.<\/p>\n
1. Produktionsserver beobachten den Consul-Schl\u00fcssel. 2. Der Schl\u00fcssel \u00e4ndert sich, was den Servern mitteilt, dass sie mit dem Laden des neuen Codes beginnen m\u00fcssen. 3. Die Server laden Tarball-Dateien mit dem Anwendungs-Code herunter.<\/i><\/p>\n\u258dAtomare Deployments<\/h3>\n
\nEine weitere L\u00f6sung, die uns geholfen hat, ein mehrstufiges Deployment-System zu erreichen, war das atomare Deployment.<\/p>\n
Vor der Verwendung atomarer Deployments konnte jedes Deployment zu einer Vielzahl von Fehlermeldungen f\u00fchren. Der Grund daf\u00fcr war, dass der Prozess des Kopierens neuer Dateien auf die Produktionsserver nicht atomar war. Dies f\u00fchrte zu einem kurzen Zeitfenster, in dem der Code, der neue Funktionen aufrief, verf\u00fcgbar war, bevor diese Funktionen selbst verf\u00fcgbar wurden. Wenn dieser Code aufgerufen wurde, f\u00fchrte dies zu internen Fehlern. Dies \u00e4u\u00dferte sich in fehlgeschlagenen API-Anfragen und \"kaputten\" Webseiten.<\/p>\n
Das Team, das sich mit diesem Problem besch\u00e4ftigte, l\u00f6ste es, indem es das Konzept von \"hei\u00dfen\" (hot) und \"kalten\" (cold) Verzeichnissen einf\u00fchrte. Der Code im \"hei\u00dfen\" Verzeichnis ist f\u00fcr die Verarbeitung des Produktionsverkehrs verantwortlich. In den \"kalten\" Verzeichnissen wird der Code w\u00e4hrend des Betriebs des Systems nur f\u00fcr die Nutzung vorbereitet. W\u00e4hrend 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.<\/p>\n
1. Entpacken des Anwendungs-Codes in das \"kalte\" Verzeichnis. 2. Umschalten auf das \"kalte\" Verzeichnis, das \"hei\u00df\" wird (atomare Operation).<\/i><\/p>\nErgebnisse: Verschiebung des Fokus auf Zuverl\u00e4ssigkeit.<\/h2>\n
\nIm Jahr 2018 erreichte das Projekt Ausma\u00dfe, bei denen die sehr schnelle Bereitstellung die Stabilit\u00e4t des Produkts zu sch\u00e4digen 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\u00dfen Unternehmen entwickelt, dessen Entwicklungen weltweit f\u00fcr die Bereitstellung einer unterbrechungsfreien Kommunikation und zur L\u00f6sung wichtiger Aufgaben eingesetzt wurden. Daher lag unser Fokus auf der Zuverl\u00e4ssigkeit.<\/p>\n
Wir mussten den Prozess der Bereitstellung neuer Slack-Versionen sicherer gestalten. Diese Notwendigkeit f\u00fchrte uns zur Verbesserung unseres Bereitstellungssystems. Tats\u00e4chlich haben wir oben dieses verbesserte System diskutiert. Im Inneren des Systems nutzen wir weiterhin Technologien f\u00fcr schnelle und atomare Bereitstellungen. Was sich ge\u00e4ndert hat, ist die Art und Weise, wie die Bereitstellung tats\u00e4chlich erfolgt. Unser neues System ist f\u00fcr die schrittweise Bereitstellung neuen Codes auf verschiedenen Ebenen in unterschiedlichen Umgebungen konzipiert. Jetzt verwenden wir anspruchsvollere Hilfsmittel und Monitoring-Tools als zuvor. Dies erm\u00f6glicht es uns, Fehler zu erkennen und zu beheben, lange bevor sie die Chance haben, den Endbenutzer zu erreichen.<\/p>\n
Aber wir haben nicht vor, auf dem Erreichten auszuruhen. Wir verbessern dieses System st\u00e4ndig, indem wir anspruchsvollere Hilfsmittel und Automatisierungstools einsetzen.<\/p>\n
Liebe Leser!<\/b> Wie ist der Prozess der Bereitstellung neuer Projektversionen dort, wo Sie arbeiten?<\/p>\n
habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t