<\/a><\/noindex><\/p>\nJak dzisiaj dzia\u0142aj\u0105 procesy wdra\u017cania projekt\u00f3w<\/h2>\n \nKa\u017cde PR (pull request) w Slack musi by\u0107 koniecznie poddane przegl\u0105dowi kodu i musi pomy\u015blnie przej\u015b\u0107 wszystkie testy. Dopiero po spe\u0142nieniu tych warunk\u00f3w programista mo\u017ce scali\u0107 sw\u00f3j kod z ga\u0142\u0119zi\u0105 master projektu. Wdro\u017cenie takiego kodu odbywa si\u0119 jednak tylko w godzinach pracy wed\u0142ug czasu p\u00f3\u0142nocnoameryka\u0144skiego. W efekcie, poniewa\u017c nasi pracownicy s\u0105 w biurze, jeste\u015bmy w pe\u0142ni gotowi na rozwi\u0105zanie wszelkich nieprzewidzianych problem\u00f3w.<\/p>\n
Codziennie przeprowadzamy oko\u0142o 12 zaplanowanych wdro\u017ce\u0144. W trakcie ka\u017cdego wdro\u017cenia programista, odpowiedzialny za wdro\u017cenie, odpowiada za wydanie nowej wersji na produkcj\u0119. To wieloetapowy proces, kt\u00f3ry zapewnia p\u0142ynne wprowadzenie wersji do trybu roboczego. Dzi\u0119ki takiemu podej\u015bciu mo\u017cemy wykrywa\u0107 b\u0142\u0119dy przed tym, jak dotkn\u0105 one wszystkich naszych u\u017cytkownik\u00f3w. Je\u015bli b\u0142\u0119d\u00f3w b\u0119dzie zbyt wiele, wdro\u017cenie wersji mo\u017cna cofn\u0105\u0107. Je\u015bli jednak jaka\u015b konkretna kwestia zostanie odkryta po wydaniu, mo\u017cna \u0142atwo wyda\u0107 poprawk\u0119.<\/p>\n
Interfejs systemu Checkpoint, kt\u00f3rego u\u017cywaj\u0105 w Slack do wdra\u017cania projekt\u00f3w<\/i><\/p>\n
Proces wdra\u017cania nowej wersji na produkcji mo\u017cna przedstawi\u0107 jako sk\u0142adaj\u0105cy si\u0119 z czterech krok\u00f3w.<\/p>\n
\u258d1. Tworzenie ga\u0142\u0119zi wydania<\/h3>\n \nKa\u017cde wydanie zaczyna si\u0119 od nowej ga\u0142\u0119zi wydania, od momentu w naszej historii Git. Pozwala to przypisywa\u0107 tagi do wydania i daje miejsce, w kt\u00f3rym mo\u017cna wprowadza\u0107 pilne poprawki b\u0142\u0119d\u00f3w znalezionych w trakcie przygotowania wydania do produkcji.<\/p>\n
\u258d2. Wdra\u017canie w \u015brodowisku stagingowym<\/h3>\n \nNast\u0119pnym krokiem jest wdro\u017cenie kompilacji na serwerach stagingowych oraz uruchomienie automatycznych test\u00f3w og\u00f3lnej funkcjonalno\u015bci projektu (testy smoke). \u015arodowisko stagingowe to \u015brodowisko produkcyjne, do kt\u00f3rego nie dociera ruch zewn\u0119trzny. W tym \u015brodowisku przeprowadzamy dodatkowe testy r\u0119czne. Daje nam to dodatkow\u0105 pewno\u015b\u0107, \u017ce zmieniony projekt dzia\u0142a prawid\u0142owo. Samych automatycznych test\u00f3w nie wystarcza, aby uzyska\u0107 podobn\u0105 pewno\u015b\u0107.<\/p>\n
\u258d3. Wdra\u017canie w \u015brodowiskach dogfood i canary<\/h3>\n \nWdro\u017cenie w produkcji zaczyna si\u0119 od \u015brodowiska dogfood, kt\u00f3re sk\u0142ada si\u0119 z zestawu host\u00f3w obs\u0142uguj\u0105cych nasze wewn\u0119trzne przestrzenie robocze w Slacku. Jako \u017ce jeste\u015bmy bardzo aktywnymi u\u017cytkownikami Slacka, zastosowanie takiego podej\u015bcia pomog\u0142o odkry\u0107 wiele b\u0142\u0119d\u00f3w na wczesnych etapach wdro\u017cenia. Po upewnieniu si\u0119, \u017ce podstawowa funkcjonalno\u015b\u0107 systemu nie zosta\u0142a naruszona, nast\u0119puje wdro\u017cenie kompilacji w \u015brodowisku canary. Jest to system, na kt\u00f3ry trafia oko\u0142o 2% ruchu produkcyjnego.<\/p>\n
\u258d4. Stopniowe wprowadzenie do produkcji<\/h3>\n \nJe\u015bli wska\u017aniki monitorowania nowego wydania s\u0105 stabilne, a po wdro\u017ceniu projektu w \u015brodowisku canary nie otrzymali\u015bmy skarg, kontynuujemy stopniowe przenoszenie serwer\u00f3w produkcyjnych na nowe wydanie. Proces wdro\u017cenia jest podzielony na nast\u0119puj\u0105ce etapy: 10%, 25%, 50%, 75% i 100%. W rezultacie mo\u017cemy powoli przenosi\u0107 ruch produkcyjny do nowego wydania systemu. Mamy przy tym czas na zbadanie sytuacji w przypadku wyst\u0105pienia jakichkolwiek anomalii.<\/p>\n
\u258dCo zrobi\u0107, je\u015bli podczas wdro\u017cenia co\u015b posz\u0142o nie tak?<\/h3>\n \nWprowadzanie modyfikacji w kodzie zawsze wi\u0105\u017ce si\u0119 z ryzykiem. Jednak radzimy sobie z tym dzi\u0119ki obecno\u015bci dobrze przygotowanych \u201eg\u0142\u00f3wnych do wdro\u017ce\u0144\u201d, kt\u00f3rzy kieruj\u0105 procesem wprowadzania nowej wersji do produkcji, monitoruj\u0105 metryki oraz koordynuj\u0105 prac\u0119 programist\u00f3w wydaj\u0105cych kod.<\/p>\n
W przypadku gdy co\u015b naprawd\u0119 posz\u0142o nie tak, staramy si\u0119 wykry\u0107 problem jak najszybciej. Badamy problem, znajdujemy PR, kt\u00f3ry powoduje b\u0142\u0119dy, wycofujemy go, dok\u0142adnie analizujemy i tworzymy now\u0105 wersj\u0119. Czasami jednak problem staje si\u0119 niezauwa\u017cony do momentu wprowadzenia projektu do produkcji. W takiej sytuacji najwa\u017cniejsze jest przywr\u00f3cenie sprawno\u015bci us\u0142ugi. Dlatego przed rozpocz\u0119ciem badania problemu natychmiast wycofujemy si\u0119 do poprzedniej dzia\u0142aj\u0105cej wersji.<\/p>\n
Elementy sk\u0142adowe systemu wdro\u017ceniowego<\/h2>\n \nPrzyjrzyjmy si\u0119 technologiom, kt\u00f3re le\u017c\u0105 u podstaw naszego systemu wdra\u017cania projekt\u00f3w.<\/p>\n
\u258dSzybkie wdro\u017cenia<\/h3>\n \nOpisany powy\u017cej proces roboczy mo\u017ce wydawa\u0107 si\u0119 wstecznie czym\u015b ca\u0142kowicie oczywistym. Jednak nasz system wdro\u017ceniowy nie osi\u0105gn\u0105\u0142 swojego obecnego kszta\u0142tu od razu.<\/p>\n
Kiedy firma by\u0142a znacznie mniejsza, ca\u0142e nasze aplikacje mog\u0142y dzia\u0142a\u0107 na 10 instancjach Amazon EC2. Wdro\u017cenie projektu w takiej sytuacji oznacza\u0142o zastosowanie rsync do szybkiej synchronizacji wszystkich serwer\u00f3w. Nowy kod od produkcji dzieli\u0142 tylko jeden krok, reprezentowany przez \u015brodowisko po\u015brednie. Budowy by\u0142y tworzone i sprawdzane w tym \u015brodowisku, a nast\u0119pnie od razu trafia\u0142y do produkcji. Zrozumienie takiego systemu by\u0142o bardzo proste, pozwala\u0142o ka\u017cdemu programi\u015bcie w dowolnym momencie wdro\u017cy\u0107 napisany przez niego kod.<\/p>\n
Jednak wraz ze wzrostem liczby naszych klient\u00f3w, ros\u0142y r\u00f3wnie\u017c rozmiary infrastruktury potrzebnej do zapewnienia dzia\u0142ania projektu. Wkr\u00f3tce, bior\u0105c pod uwag\u0119 ci\u0105g\u0142y rozw\u00f3j systemu, nasz model wdro\u017ceniowy oparty na wysy\u0142aniu nowego kodu na serwery przesta\u0142 spe\u0142nia\u0107 swoje zadanie. A dok\u0142adniej, dodanie ka\u017cdego nowego serwera wi\u0105za\u0142o si\u0119 ze zwi\u0119kszeniem czasu potrzebnego na wdro\u017cenie. Nawet strategie oparte na r\u00f3wnoczesnym stosowaniu rsync maj\u0105 pewne ograniczenia.<\/p>\n
Ostatecznie rozwi\u0105zali\u015bmy ten problem, przechodz\u0105c na ca\u0142kowicie r\u00f3wnoleg\u0142y system wdro\u017ceniowy, zorganizowany inaczej ni\u017c stary system. A konkretnie, teraz nie wysy\u0142ali\u015bmy kodu na serwery za pomoc\u0105 skryptu synchronizacyjnego. Ka\u017cdy serwer teraz samodzielnie pobiera\u0142 nowe wersje, dowiaduj\u0105c si\u0119 o tym dzi\u0119ki obserwacji zmiany klucza Consul. Serwery pobiera\u0142y kod r\u00f3wnolegle. Pozwoli\u0142o to nam utrzyma\u0107 wysok\u0105 pr\u0119dko\u015b\u0107 wdro\u017cenia nawet przy ci\u0105g\u0142ym wzro\u015bcie systemu.<\/p>\n
1. Serwery produkcyjne obserwuj\u0105 klucz Consul. 2. Klucz si\u0119 zmienia, co informuje serwery o konieczno\u015bci rozpocz\u0119cia pobierania nowego kodu. 3. Serwery pobieraj\u0105 pliki tarball z kodem aplikacji.<\/i><\/p>\n\u258dAtomowe wdro\u017cenia<\/h3>\n
\nKolejnym rozwi\u0105zaniem, kt\u00f3re pomog\u0142o nam przej\u015b\u0107 na wielopoziomowy system wdro\u017ceniowy, by\u0142y wdro\u017cenia atomowe.<\/p>\n
Przed wprowadzeniem atomowych wdro\u017ce\u0144 ka\u017cde wdro\u017cenie mog\u0142o prowadzi\u0107 do wyst\u0105pienia du\u017cej liczby komunikat\u00f3w o b\u0142\u0119dach. Problemem by\u0142o to, \u017ce proces kopiowania nowych plik\u00f3w na serwery produkcyjne nie by\u0142 atomowy. Sprawia\u0142o to, \u017ce istnia\u0142 kr\u00f3tki okres, w kt\u00f3rym kod wywo\u0142uj\u0105cy nowe funkcje by\u0142 dost\u0119pny zanim same te funkcje sta\u0142y si\u0119 dost\u0119pne. Kiedy taki kod by\u0142 wywo\u0142ywany, prowadzi\u0142o to do zwracania b\u0142\u0119d\u00f3w wewn\u0119trznych. Objawia\u0142o si\u0119 to w nieudanych zapytaniach do API i na \"zepsutych\" stronach internetowych.<\/p>\n
Zesp\u00f3\u0142 zajmuj\u0105cy si\u0119 tym problemem rozwi\u0105za\u0142 go, wprowadzaj\u0105c poj\u0119cia \"gor\u0105cych\" (hot) i \"zimnych\" (cold) katalog\u00f3w. Kod w \"gor\u0105cym\" katalogu odpowiada za przetwarzanie ruchu produkcyjnego. W \"zimnych\" katalogach kod, w trakcie dzia\u0142ania systemu, tylko przygotowuje si\u0119 do u\u017cycia. W trakcie wdro\u017cenia nowy kod jest kopiowany do nieu\u017cywanego \"zimnego\" katalogu. Nast\u0119pnie, gdy na serwerze nie ma aktywnych proces\u00f3w, nast\u0119puje natychmiastowe prze\u0142\u0105czenie katalog\u00f3w.<\/p>\n
1. Rozpakowanie kodu aplikacji do \"zimnego\" katalogu. 2. Prze\u0142\u0105czenie systemu na \"zimny\" katalog, kt\u00f3ry staje si\u0119 \"gor\u0105cy\" (operacja atomowa).<\/i><\/p>\nPodsumowanie: przesuni\u0119cie akcentu na niezawodno\u015b\u0107.<\/h2>\n
\nW 2018 roku projekt osi\u0105gn\u0105\u0142 taki poziom, \u017ce bardzo szybkie wdro\u017cenie zacz\u0119\u0142o szkodzi\u0107 stabilno\u015bci produktu. Mieli\u015bmy do\u015b\u0107 zaawansowany system wdro\u017ceniowy, w kt\u00f3ry w\u0142o\u017cyli\u015bmy du\u017co pracy i czasu. Musieli\u015bmy jedynie przebudowa\u0107 i usprawni\u0107 procesy organizacji wdro\u017ce\u0144. Przekszta\u0142cili\u015bmy si\u0119 w stosunkowo du\u017c\u0105 firm\u0119, kt\u00f3rej rozwi\u0105zania by\u0142y wykorzystywane na ca\u0142ym \u015bwiecie do zapewnienia ci\u0105g\u0142ej \u0142\u0105czno\u015bci i rozwi\u0105zywania wa\u017cnych problem\u00f3w. Dlatego w centrum naszej uwagi znalaz\u0142a si\u0119 niezawodno\u015b\u0107.<\/p>\n
Musieli\u015bmy uczyni\u0107 proces wdra\u017cania nowych wersji Slack bardziej bezpiecznym. Ta potrzeba doprowadzi\u0142a nas do udoskonalenia naszego systemu wdro\u017ceniowego. W\u0142a\u015bciwie to w\u0142a\u015bnie t\u0119 usprawnion\u0105 system om\u00f3wili\u015bmy powy\u017cej. W g\u0142\u0119bi systemu wci\u0105\u017c korzystamy z technologii szybkiego i atomowego wdra\u017cania. Zmieni\u0142o si\u0119 to, jak dok\u0142adnie odbywa si\u0119 wdro\u017cenie. Nasz nowy system jest zaprojektowany do stopniowego wdra\u017cania nowego kodu na r\u00f3\u017cnych poziomach, w r\u00f3\u017cnych \u015brodowiskach. Teraz korzystamy z bardziej zaawansowanych narz\u0119dzi pomocniczych i system\u00f3w monitoruj\u0105cych. Daje nam to mo\u017cliwo\u015b\u0107 wychwytywania i naprawiania b\u0142\u0119d\u00f3w na d\u0142ugo przed tym, gdy maj\u0105 one szans\u0119 dotrze\u0107 do u\u017cytkownika ko\u0144cowego.<\/p>\n
Jednak nie zamierzamy na tym poprzesta\u0107. Nieustannie udoskonalamy ten system, stosuj\u0105c coraz bardziej zaawansowane narz\u0119dzia pomocnicze i \u015brodki automatyzacji pracy.<\/p>\n
Drodzy Czytelnicy!<\/b> Jak wygl\u0105da proces wdra\u017cania nowych wersji projekt\u00f3w w miejscu, w kt\u00f3rym pracujesz?<\/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