Wprowadzanie nowej wersji projektu do środowiska produkcyjnego wymaga starannej równowagi pomiędzy szybkością wdrożenia i niezawodnością rozwiązania. Slack ceni szybkie iteracje, krótkie cykle informacji zwrotnej i szybką reakcję na żądania użytkowników. Ponadto firma zatrudnia setki programistów, którzy starają się być jak najbardziej produktywni.
Autorzy materiału, którego tłumaczenie dziś publikujemy, mówią, że firma, która stara się trzymać takich wartości, a jednocześnie się rozwija, musi stale doskonalić swój system wdrażania projektów. Firma musi inwestować w przejrzystość i niezawodność procesów pracy, robiąc to tak, aby procesy te odpowiadały skali projektu. Tutaj porozmawiamy o przepływach pracy, które rozwinęły się w Slacku, oraz o niektórych decyzjach, które skłoniły firmę do korzystania z istniejącego dzisiaj systemu wdrażania projektów.
Jak dzisiaj działają procesy wdrażania projektów
Każde PR (pull request) w Slacku musi zostać poddane przeglądowi kodu i musi pomyślnie przejść wszystkie testy. Dopiero po spełnieniu tych warunków programista może połączyć swój kod z główną gałęzią projektu. Jednak ten kod jest wdrażany tylko w godzinach pracy czasu północnoamerykańskiego. Dzięki temu, dzięki temu, że nasi pracownicy są na swoich stanowiskach pracy, jesteśmy w pełni przygotowani na rozwiązanie wszelkich nieoczekiwanych problemów.
Codziennie realizujemy około 12 zaplanowanych wdrożeń. Podczas każdego wdrożenia programista wyznaczony jako kierownik wdrożenia jest odpowiedzialny za wprowadzenie nowej wersji do środowiska produkcyjnego. Jest to wieloetapowy proces, który zapewnia sprawne wprowadzenie zestawu do produkcji. Dzięki takiemu podejściu jesteśmy w stanie wykryć błędy, zanim dotkną one wszystkich naszych użytkowników. Jeśli jest zbyt wiele błędów, wdrożenie zestawu można wycofać. Jeśli po wydaniu zostanie wykryty konkretny problem, można łatwo wydać dla niego poprawkę.
Interfejs systemu Checkpoint, który służy w Slacku do wdrażania projektów
Proces wdrażania nowej wersji do środowiska produkcyjnego można podzielić na cztery kroki.
▍1. Tworzenie gałęzi wydania
Każde wydanie zaczyna się od nowej gałęzi wydania, punktu w naszej historii Git. Pozwala to na przypisanie tagów do wydania i zapewnia miejsce, w którym można na bieżąco wprowadzać poprawki błędów znalezionych w procesie przygotowania wydania do wydania na produkcję.
▍2. Wdrożenie w środowisku przejściowym
Następnym krokiem jest wdrożenie zestawu na serwerach pomostowych i uruchomienie automatycznego testu ogólnej wydajności projektu (test dymu). Środowisko testowe to środowisko produkcyjne, które nie odbiera ruchu zewnętrznego. W tym środowisku wykonujemy dodatkowe testy manualne. Daje nam to dodatkową pewność, że zmodyfikowany projekt działa poprawnie. Same testy automatyczne nie wystarczą, aby zapewnić taki poziom pewności.
▍3. Wdrożenie w środowiskach dogfood i kanarkowych
Wdrożenie do środowiska produkcyjnego rozpoczyna się od środowiska testowego, reprezentowanego przez zestaw hostów obsługujących nasze wewnętrzne obszary robocze Slack. Ponieważ jesteśmy bardzo aktywnymi użytkownikami Slacka, przyjęcie tego podejścia pomogło nam wyłapać wiele błędów na wczesnym etapie wdrożenia. Po upewnieniu się, że podstawowa funkcjonalność systemu nie jest uszkodzona, montaż zostaje wdrożony w środowisku canary. Reprezentuje systemy, które odpowiadają za około 2% ruchu produkcyjnego.
▍4. Stopniowe wprowadzanie do produkcji
Jeśli wskaźniki monitorowania nowej wersji okażą się stabilne, a po wdrożeniu projektu w środowisku kanarkowym nie otrzymamy żadnych reklamacji, będziemy kontynuować stopniowe przenoszenie serwerów produkcyjnych na nową wersję. Proces wdrożenia dzieli się na etapy: 10%, 25%, 50%, 75% i 100%. Dzięki temu możemy powoli przenosić ruch produkcyjny na nową wersję systemu. Jednocześnie mamy czas na zbadanie sytuacji w przypadku wykrycia jakichkolwiek nieprawidłowości.
▍Co się stanie, jeśli coś pójdzie nie tak podczas wdrażania?
Wprowadzanie modyfikacji w kodzie zawsze wiąże się z ryzykiem. Ale radzimy sobie z tym dzięki obecności dobrze wyszkolonych „liderów wdrożeń”, którzy zarządzają procesem wprowadzenia nowego wydania do produkcji, monitorują wskaźniki monitorowania i koordynują pracę programistów wypuszczających kod.
W przypadku, gdy rzeczywiście coś pójdzie nie tak, staramy się wykryć problem możliwie najwcześniej. Badamy problem, znajdujemy PR powodujący błędy, wycofujemy go, dokładnie analizujemy i tworzymy nową kompilację. To prawda, że czasami problem pozostaje niezauważony, dopóki projekt nie trafi do produkcji. W takiej sytuacji najważniejsze jest przywrócenie usługi. Dlatego zanim zaczniemy badać problem, natychmiast wracamy do poprzedniej działającej wersji.
Elementy składowe systemu wdrażania
Przyjrzyjmy się technologiom leżącym u podstaw naszego systemu wdrażania projektów.
▍Szybkie wdrożenia
Z perspektywy czasu opisany powyżej przepływ pracy może wydawać się nieco oczywisty. Jednak nasz system wdrażania nie stał się taki od razu.
Gdy firma była znacznie mniejsza, cała nasza aplikacja mogła działać na 10 instancjach Amazon EC2. Wdrożenie projektu w tej sytuacji oznaczało użycie rsync do szybkiej synchronizacji wszystkich serwerów. Wcześniej nowy kod był tylko o krok od produkcji, co było reprezentowane przez środowisko testowe. W takim środowisku powstały zespoły, które następnie przetestowano, a następnie trafiły bezpośrednio do produkcji. Zrozumienie takiego systemu było bardzo łatwe, pozwalało każdemu programiście na wdrożenie w dowolnym momencie napisanego przez siebie kodu.
Jednak wraz ze wzrostem liczby naszych klientów rosła skala infrastruktury wymaganej do obsługi projektu. Wkrótce, w obliczu ciągłego rozwoju systemu, nasz model wdrożenia, polegający na wpychaniu nowego kodu na serwery, przestał spełniać swoje zadanie. Mianowicie dodanie każdego nowego serwera oznaczało wydłużenie czasu wymaganego do zakończenia wdrożenia. Nawet strategie oparte na równoległym użyciu rsync mają pewne ograniczenia.
Ostatecznie rozwiązaliśmy ten problem, przechodząc na całkowicie równoległy system wdrażania, który został zaprojektowany inaczej niż stary system. Mianowicie teraz nie wysyłaliśmy kodu na serwery za pomocą skryptu synchronizacyjnego. Teraz każdy serwer niezależnie pobrał nowy zestaw, wiedząc, że musi to zrobić, monitorując zmianę klucza Consul. Serwery ładowały kod równolegle. Pozwoliło nam to utrzymać wysoką prędkość wdrożenia nawet w środowisku ciągłego wzrostu systemu.
1. Serwery produkcyjne monitorują klucz Consul. 2. Kluczowe zmiany informują serwery, że muszą rozpocząć pobieranie nowego kodu. 3. Serwery pobierają pliki tar z kodem aplikacji
▍Rozmieszczenia atomowe
Kolejnym rozwiązaniem, które pomogło nam osiągnąć wielopoziomowy system wdrażania, było wdrożenie atomowe.
Przed użyciem wdrożeń atomowych każde wdrożenie może spowodować dużą liczbę komunikatów o błędach. Faktem jest, że proces kopiowania nowych plików na serwery produkcyjne nie był atomowy. Skutkowało to krótkim okresem czasu, w którym kod wywołujący nowe funkcje był dostępny, zanim udostępniono same funkcje. Wywołanie takiego kodu powodowało zwrócenie błędów wewnętrznych. Przejawiało się to w nieudanych żądaniach API i uszkodzonych stronach internetowych.
Zespół pracujący nad tym problemem rozwiązał go, wprowadzając koncepcję katalogów „gorących” i „zimnych”. Kod w katalogu hot odpowiada za przetwarzanie ruchu produkcyjnego. Natomiast w „zimnych” katalogach kod podczas działania systemu jest jedynie przygotowywany do użycia. Podczas wdrażania nowy kod jest kopiowany do nieużywanego zimnego katalogu. Następnie, gdy na serwerze nie ma aktywnych procesów, następuje natychmiastowe przełączenie katalogów.
1. Rozpakowanie kodu aplikacji do „zimnego” katalogu. 2. Przełączenie systemu do katalogu „zimnego”, który staje się „gorący” (operacja atomowa)
Wyniki: przesunięcie nacisku na niezawodność
W 2018 roku projekt rozrósł się do takiej skali, że bardzo szybkie wdrożenie zaczęło szkodzić stabilności produktu. Mieliśmy bardzo zaawansowany system wdrażania, w który zainwestowaliśmy dużo czasu i wysiłku. Jedyne, co musieliśmy zrobić, to odbudować i ulepszyć nasze procesy wdrażania. Wyrośliśmy na dość dużą firmę, której rozwiązania są wykorzystywane na całym świecie do organizowania nieprzerwanej komunikacji i rozwiązywania ważnych problemów. Dlatego w centrum naszej uwagi znalazła się niezawodność.
Musieliśmy zwiększyć bezpieczeństwo procesu wdrażania nowych wersji Slacka. Ta potrzeba skłoniła nas do ulepszenia naszego systemu wdrażania. Prawdę mówiąc, omówiliśmy ten ulepszony system powyżej. W głębi systemu nadal korzystamy z technologii szybkiego i atomowego wdrażania. Zmienił się sposób wdrażania. Nasz nowy system został zaprojektowany tak, aby stopniowo wdrażać nowy kod na różnych poziomach, w różnych środowiskach. Korzystamy teraz z bardziej zaawansowanych narzędzi wsparcia i narzędzi do monitorowania systemu niż wcześniej. Daje nam to możliwość wychwytywania i naprawiania błędów na długo przed tym, zanim zdążą dotrzeć do użytkownika końcowego.
Ale nie zamierzamy na tym poprzestać. Stale udoskonalamy ten system, wykorzystując coraz bardziej zaawansowane narzędzia pomocnicze i narzędzia automatyzacji pracy.
Drodzy Czytelnicy! Jak wygląda proces wdrażania nowych wersji projektów tam, gdzie pracujesz?
Źródło: www.habr.com