<\/a><\/noindex><\/p>\nWie die Deployment-Prozesse heute funktionieren<\/h2>\n \nJede PR (Pull Request) in Slack muss unbedingt einer Code-\u00dcberpr\u00fcfung unterzogen werden und alle Tests erfolgreich bestehen. Erst nachdem diese Bedingungen erf\u00fcllt sind, kann der Entwickler seinen Code mit dem Master-Branch des Projekts zusammenf\u00fchren. Die Bereitstellung des Codes erfolgt jedoch nur w\u00e4hrend der Arbeitszeiten in Nordamerikanischer Zeitzone. Dadurch sind wir dank unserer Mitarbeiter vor Ort vollst\u00e4ndig bereit, unerwartete Probleme zu l\u00f6sen.<\/p>\n
Jeden Tag f\u00fchren wir etwa 12 geplante Bereitstellungen durch. W\u00e4hrend jeder Bereitstellung ist der f\u00fcr die Bereitstellung verantwortliche Entwickler f\u00fcr die Einf\u00fchrung des neuen Builds in die Produktion zust\u00e4ndig. Dies ist ein mehrstufiger Prozess, der eine reibungslose Einf\u00fchrung des Builds in den Live-Betrieb gew\u00e4hrleistet. Mit diesem Ansatz k\u00f6nnen wir Fehler erkennen, bevor sie alle unsere Nutzer beeintr\u00e4chtigen. Sollte es zu vielen Fehlern kommen, kann die Bereitstellung des Builds zur\u00fcckgesetzt werden. Wird hingegen ein spezifisches Problem nach der Ver\u00f6ffentlichung entdeckt, l\u00e4sst sich daf\u00fcr leicht ein Hotfix ausbringen.<\/p>\n
Die Schnittstelle des Checkpoint-Systems, die in Slack zur Bereitstellung von Projekten verwendet wird<\/i><\/p>\n
Der Prozess der Bereitstellung eines neuen Releases in der Produktion kann als bestehend aus vier Schritten dargestellt werden.<\/p>\n
\u258d1. Erstellung eines Release-Branches<\/h3>\n \nJedes Release beginnt mit einem neuen Release-Branch zu einem bestimmten Zeitpunkt in unserer Git-Historie. Dies erm\u00f6glicht es, dem Release Tags zuzuweisen und schafft einen Bereich, in den schnelle Korrekturen f\u00fcr Fehler eingef\u00fcgt werden k\u00f6nnen, die w\u00e4hrend der Vorbereitung des Releases f\u00fcr die Produktion entdeckt wurden.<\/p>\n
\u258d2. Bereitstellung in der Zwischenumgebung<\/h3>\n \nDer n\u00e4chste Schritt besteht darin, das Build auf den Staging-Servern bereitzustellen und einen automatischen Test auf die allgemeine Funktionsf\u00e4higkeit des Projekts (Smoke-Test) durchzuf\u00fchren. Die Zwischenumgebung ist eine Produktionsumgebung, in die kein externer Traffic eindringt. In dieser Umgebung f\u00fchren wir zus\u00e4tzliche manuelle Tests durch. Dies gibt uns zus\u00e4tzliche Sicherheit, dass das angepasste Projekt korrekt funktioniert. Automatisierte Tests allein reichen nicht aus, um ein solches Vertrauen zu gewinnen.<\/p>\n
\u258d3. Bereitstellung in Dogfood- und Canary-Umgebungen<\/h3>\n \nDie Bereitstellung in der Produktion beginnt mit der dogfood-Umgebung, die aus einer Reihe von Hosts besteht, die unsere internen Arbeitsbereiche in Slack unterst\u00fctzen. Da wir starke Slack-Nutzer sind, hat dieser Ansatz geholfen, viele Fehler in den fr\u00fchen Phasen der Bereitstellung zu erkennen. Sobald wir unsergestellt haben, dass die grundlegenden Funktionalit\u00e4ten des Systems nicht beeintr\u00e4chtigt sind, erfolgt die Bereitstellung des Builds in der Canary-Umgebung. Diese besteht aus Systemen, die etwa 2% des Produktionsverkehrs erhalten.<\/p>\n
\u258d4. Schrittweise Einf\u00fchrung in der Produktion<\/h3>\n \nWenn die \u00dcberwachungskennzahlen der neuen Version stabil sind und wir nach der Bereitstellung des Projekts in der Canary-Umgebung keine Beschwerden erhalten haben, setzen wir die schrittweise Umstellung der Produktionsserver auf die neue Version fort. Der Bereitstellungsprozess ist in die folgenden Phasen unterteilt: 10%, 25%, 50%, 75% und 100%. So k\u00f6nnen wir den Produktionsverkehr schrittweise auf die neue Version des Systems \u00fcbertragen. Dies gibt uns Zeit, die Situation zu beobachten, falls Anomalien auftreten.<\/p>\n
\u258dWas tun, wenn w\u00e4hrend der Bereitstellung etwas schiefgeht?<\/h3>\n \n\u00c4nderungen im Code sind immer mit Risiken verbunden. Doch wir meistern dies dank unserer gut geschulten Deployment-Leiter, die den Prozess der Bereitstellung neuer Releases in die Produktion leiten, die \u00dcberwachungskennzahlen im Blick behalten und die Arbeit der Entwickler koordinieren, die den Code erstellen.<\/p>\n
Falls etwas tats\u00e4chlich schiefgeht, versuchen wir, das Problem so fr\u00fch wie m\u00f6glich zu erkennen. Wir analysieren das Problem, identifizieren den PR, der die Fehler verursacht, setzen ihn zur\u00fcck, untersuchen ihn gr\u00fcndlich und erstellen ein neues Build. Manchmal bleibt das Problem jedoch bis zur Produktion unentdeckt. In einem solchen Fall ist es am wichtigsten, den Dienst wiederherzustellen. Daher setzen wir, bevor wir mit der Problemuntersuchung beginnen, sofort zur letzten funktionierenden Version zur\u00fcck.<\/p>\n
Die Grundbausteine des Deployment-Systems<\/h2>\n \nBetrachten wir die Technologien, die unserer Projektbereitstellung zugrunde liegen.<\/p>\n
\u258dSchnelle Deployments<\/h3>\n \nDer oben beschriebene Arbeitsprozess mag im R\u00fcckblick als vollkommen offensichtlich erscheinen. Aber unser Deployment-System hat sich nicht von Anfang an so entwickelt.<\/p>\n
Als das Unternehmen noch viel kleiner war, konnte unsere gesamte Anwendung auf 10 Amazon EC2-Instanzen laufen. Die Bereitstellung eines Projekts in einer solchen Situation bedeutete, rsync f\u00fcr eine schnelle Synchronisation aller Server zu verwenden. Fr\u00fcher trennte nur ein Schritt den neuen Code von der Produktion, der durch eine Zwischenumgebung dargestellt wurde. Builds wurden in dieser Umgebung erstellt und getestet, bevor sie direkt in die Produktion gingen. Es war sehr einfach, sich in einem solchen System zurechtzufinden, da es jedem Programmierer zu jedem Zeitpunkt erm\u00f6glichte, seinen geschriebenen Code bereitzustellen.<\/p>\n
Doch mit wachsenden Kundenzahlen stieg auch der Umfang der Infrastruktur, die f\u00fcr den Betrieb des Projekts erforderlich war. Bald, angesichts des st\u00e4ndigen Systemwachstums, konnte unser Bereitstellungsmodell, das auf dem Senden neuen Codes an die Server basierte, nicht mehr seinen Zweck erf\u00fcllen. Jedes Hinzuf\u00fcgen eines neuen Servers bedeutete eine Erh\u00f6hung der Zeit, die f\u00fcr die Bereitstellung ben\u00f6tigt wurde. Selbst Strategien, die auf der parallelen Anwendung von rsync basierten, haben gewisse Einschr\u00e4nkungen.<\/p>\n
Schlie\u00dflich haben wir das Problem gel\u00f6st, indem wir auf ein vollst\u00e4ndig paralleles Bereitstellungssystem umgestiegen sind, das anders strukturiert ist als das alte System. Statt den Code \u00fcber ein Synchronisationsskript auf Server zu senden, laden nun die Server selbstst\u00e4ndig die neue Version herunter, nachdem sie durch das Monitoring der \u00c4nderung des Consul-Schl\u00fcssels dar\u00fcber informiert wurden. Die Server laden den Code parallel herunter. Dies erm\u00f6glichte es uns, eine hohe Bereitstellungsgeschwindigkeit auch in Zeiten des st\u00e4ndigen Systemwachstums aufrechtzuerhalten.<\/p>\n
1. Produktionsserver \u00fcberwachen den Consul-Schl\u00fcssel. 2. Der Schl\u00fcssel \u00e4ndert sich, was den Servern signalisiert, dass sie mit dem Herunterladen des neuen Codes beginnen m\u00fcssen. 3. Die Server laden die Tarball-Dateien mit dem Anwendungscode herunter.<\/i><\/p>\n\u258dAtomare Bereitstellungen<\/h3>\n
\nEine weitere L\u00f6sung, die uns geholfen hat, zu einem mehrstufigen Bereitstellungssystem zu gelangen, war die atomare Bereitstellung.<\/p>\n
Vor der Einf\u00fchrung atomarer Bereitstellungen konnte jede Bereitstellung eine Vielzahl von Fehlermeldungen verursachen. Der Grund daf\u00fcr war, dass der Prozess des Kopierens neuer Dateien auf Produktionsserver nicht atomar war. Dies f\u00fchrte zu einer kurzen Zeitspanne, in der der Code, der neue Funktionen aufrief, zug\u00e4nglich war, bevor die Funktionen selbst verf\u00fcgbar waren. Wenn solcher Code ausgef\u00fchrt wurde, kam es zu internen Fehlern. Dies \u00e4u\u00dferte sich in fehlgeschlagenen API-Anfragen und \u201ekaputten\u201c Webseiten.<\/p>\n
Das Team, das sich mit diesem Problem besch\u00e4ftigte, l\u00f6ste es durch die Einf\u00fchrung des Konzepts von \u201ehei\u00dfen\u201c (hot) und \u201ekalten\u201c (cold) Verzeichnissen. Der Code im \u201ehei\u00dfen\u201c Verzeichnis ist f\u00fcr die Verarbeitung des Produktionsverkehrs verantwortlich. In den \u201ekalten\u201c Verzeichnissen wird der Code w\u00e4hrend des Systembetriebs lediglich f\u00fcr die Nutzung vorbereitet. Bei der Bereitstellung wird der neue Code in ein ungenutztes \u201ekaltes\u201c Verzeichnis kopiert. Dann, wenn auf dem Server keine aktiven Prozesse mehr laufen, erfolgt ein sofortiger Verzeichniswechsel.<\/p>\n
1. Entpacken des Anwendungscodes in ein 'kaltes' Verzeichnis. 2. Umschalten des Systems auf das 'kalte' Verzeichnis, das zu einem 'hei\u00dfen' wird (atomare Operation)<\/i><\/p>\nZusammenfassung: Verschiebung des Fokus auf Zuverl\u00e4ssigkeit<\/h2>\n
\nIm Jahr 2018 erreichte das Projekt ein solches Ausma\u00df, dass eine sehr schnelle Bereitstellung der Stabilit\u00e4t des Produkts schadete. Wir hatten ein \u00e4u\u00dferst fortschrittliches Bereitstellungssystem, in das wir viel M\u00fche und Zeit investiert hatten. Wir mussten nur die Prozesse der Bereitstellungsorganisation neu strukturieren und verbessern. Wir sind zu einem ausreichend gro\u00dfen Unternehmen geworden, dessen Entwicklungen weltweit f\u00fcr die Organisation einer unterbrechungsfreien Kommunikation und zur L\u00f6sung wichtiger Aufgaben verwendet wurden. Daher stand die Zuverl\u00e4ssigkeit im Mittelpunkt unserer Aufmerksamkeit.<\/p>\n
Wir mussten den Prozess f\u00fcr die Bereitstellung neuer Slack-Versionen sicherer gestalten. Diese Notwendigkeit f\u00fchrte uns zur Verbesserung unseres Bereitstellungssystems. Wie bereits oben erw\u00e4hnt, haben wir dieses verbesserte System diskutiert. Innerhalb des Systems setzen wir weiterhin auf Technologien f\u00fcr schnelle und atomare Bereitstellungen. Was sich ver\u00e4ndert hat, ist, wie die Bereitstellung selbst erfolgt. Unser neues System ist darauf ausgelegt, die Bereitstellung neuer Codes schrittweise auf verschiedenen Ebenen und in unterschiedlichen Umgebungen durchzuf\u00fchren. Jetzt verwenden wir fortschrittlichere Tools und Monitoring-Mittel als zuvor. Dies erm\u00f6glicht es uns, Fehler fr\u00fchzeitig zu erkennen und zu beheben, bevor sie die Endnutzer erreichen.<\/p>\n
Doch wir haben nicht vor, uns auf unseren Erfolgen auszuruhen. Wir verbessern dieses System st\u00e4ndig, indem wir fortschrittlichere Support-Tools und Automatisierungstechniken einsetzen.<\/p>\n
Sehr geehrte Leser!<\/b> Wie funktioniert der Prozess der Bereitstellung neuer Projekt-Versionen in Ihrem Arbeitsumfeld?<\/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