Wydanie nowej wersji projektu na produkcję wymaga starannego zachowania równowagi między szybkością wdrażania a niezawodnością rozwiązania. W firmie Slack cenią szybkie iteracje, krótkie cykle opinii oraz szybką reakcję na zgłoszenia użytkowników. Ponadto firma ma setki programistów, którzy dążą do maksymalnej produktywności.
Autorzy materiału, którego tłumaczenie publikujemy dzisiaj, mówią, że firma, która stara się trzymać takich wartości i jednocześnie rozwija się, musi nieustannie doskonalić swój system wdrażania projektów. Firmy powinny inwestować w przejrzystość i niezawodność procesów roboczych, aby te procesy odpowiadały rozmiarom projektu. Będzie tu mowa o procesach roboczych stosowanych w Slack oraz o kilku rozwiązaniach, które doprowadziły firmę do obecnego systemu wdrażania projektów.
Jak dzisiaj działają procesy wdrażania projektów
Każde PR (pull request) w Slack musi być koniecznie poddane przeglądowi kodu i musi pomyślnie przejść wszystkie testy. Dopiero po spełnieniu tych warunków programista może scalić swój kod z gałęzią master projektu. Wdrożenie takiego kodu odbywa się jednak tylko w godzinach pracy według czasu północnoamerykańskiego. W efekcie, ponieważ nasi pracownicy są w biurze, jesteśmy w pełni gotowi na rozwiązanie wszelkich nieprzewidzianych problemów.
Codziennie przeprowadzamy około 12 zaplanowanych wdrożeń. W trakcie każdego wdrożenia programista, odpowiedzialny za wdrożenie, odpowiada za wydanie nowej wersji na produkcję. To wieloetapowy proces, który zapewnia płynne wprowadzenie wersji do trybu roboczego. Dzięki takiemu podejściu możemy wykrywać błędy przed tym, jak dotkną one wszystkich naszych użytkowników. Jeśli błędów będzie zbyt wiele, wdrożenie wersji można cofnąć. Jeśli jednak jakaś konkretna kwestia zostanie odkryta po wydaniu, można łatwo wydać poprawkę.
Interfejs systemu Checkpoint, którego używają w Slack do wdrażania projektów
Proces wdrażania nowej wersji na produkcji można przedstawić jako składający się z czterech kroków.
▍1. Tworzenie gałęzi wydania
Każde wydanie zaczyna się od nowej gałęzi wydania, od momentu w naszej historii Git. Pozwala to przypisywać tagi do wydania i daje miejsce, w którym można wprowadzać pilne poprawki błędów znalezionych w trakcie przygotowania wydania do produkcji.
▍2. Wdrażanie w środowisku stagingowym
Następnym krokiem jest wdrożenie kompilacji na serwerach stagingowych oraz uruchomienie automatycznych testów ogólnej funkcjonalności projektu (testy smoke). Środowisko stagingowe to środowisko produkcyjne, do którego nie dociera ruch zewnętrzny. W tym środowisku przeprowadzamy dodatkowe testy ręczne. Daje nam to dodatkową pewność, że zmieniony projekt działa prawidłowo. Samych automatycznych testów nie wystarcza, aby uzyskać podobną pewność.
▍3. Wdrażanie w środowiskach dogfood i canary
Wdrożenie w produkcji zaczyna się od środowiska dogfood, które składa się z zestawu hostów obsługujących nasze wewnętrzne przestrzenie robocze w Slacku. Jako że jesteśmy bardzo aktywnymi użytkownikami Slacka, zastosowanie takiego podejścia pomogło odkryć wiele błędów na wczesnych etapach wdrożenia. Po upewnieniu się, że podstawowa funkcjonalność systemu nie została naruszona, następuje wdrożenie kompilacji w środowisku canary. Jest to system, na który trafia około 2% ruchu produkcyjnego.
▍4. Stopniowe wprowadzenie do produkcji
Jeśli wskaźniki monitorowania nowego wydania są stabilne, a po wdrożeniu projektu w środowisku canary nie otrzymaliśmy skarg, kontynuujemy stopniowe przenoszenie serwerów produkcyjnych na nowe wydanie. Proces wdrożenia jest podzielony na następujące etapy: 10%, 25%, 50%, 75% i 100%. W rezultacie możemy powoli przenosić ruch produkcyjny do nowego wydania systemu. Mamy przy tym czas na zbadanie sytuacji w przypadku wystąpienia jakichkolwiek anomalii.
▍Co zrobić, jeśli podczas wdrożenia coś poszło nie tak?
Wprowadzanie modyfikacji w kodzie zawsze wiąże się z ryzykiem. Jednak radzimy sobie z tym dzięki obecności dobrze przygotowanych „głównych do wdrożeń”, którzy kierują procesem wprowadzania nowej wersji do produkcji, monitorują metryki oraz koordynują pracę programistów wydających kod.
W przypadku gdy coś naprawdę poszło nie tak, staramy się wykryć problem jak najszybciej. Badamy problem, znajdujemy PR, który powoduje błędy, wycofujemy go, dokładnie analizujemy i tworzymy nową wersję. Czasami jednak problem staje się niezauważony do momentu wprowadzenia projektu do produkcji. W takiej sytuacji najważniejsze jest przywrócenie sprawności usługi. Dlatego przed rozpoczęciem badania problemu natychmiast wycofujemy się do poprzedniej działającej wersji.
Elementy składowe systemu wdrożeniowego
Przyjrzyjmy się technologiom, które leżą u podstaw naszego systemu wdrażania projektów.
▍Szybkie wdrożenia
Opisany powyżej proces roboczy może wydawać się wstecznie czymś całkowicie oczywistym. Jednak nasz system wdrożeniowy nie osiągnął swojego obecnego kształtu od razu.
Kiedy firma była znacznie mniejsza, całe nasze aplikacje mogły działać na 10 instancjach Amazon EC2. Wdrożenie projektu w takiej sytuacji oznaczało zastosowanie rsync do szybkiej synchronizacji wszystkich serwerów. Nowy kod od produkcji dzielił tylko jeden krok, reprezentowany przez środowisko pośrednie. Budowy były tworzone i sprawdzane w tym środowisku, a następnie od razu trafiały do produkcji. Zrozumienie takiego systemu było bardzo proste, pozwalało każdemu programiście w dowolnym momencie wdrożyć napisany przez niego kod.
Jednak wraz ze wzrostem liczby naszych klientów, rosły również rozmiary infrastruktury potrzebnej do zapewnienia działania projektu. Wkrótce, biorąc pod uwagę ciągły rozwój systemu, nasz model wdrożeniowy oparty na wysyłaniu nowego kodu na serwery przestał spełniać swoje zadanie. A dokładniej, dodanie każdego nowego serwera wiązało się ze zwiększeniem czasu potrzebnego na wdrożenie. Nawet strategie oparte na równoczesnym stosowaniu rsync mają pewne ograniczenia.
Ostatecznie rozwiązaliśmy ten problem, przechodząc na całkowicie równoległy system wdrożeniowy, zorganizowany inaczej niż stary system. A konkretnie, teraz nie wysyłaliśmy kodu na serwery za pomocą skryptu synchronizacyjnego. Każdy serwer teraz samodzielnie pobierał nowe wersje, dowiadując się o tym dzięki obserwacji zmiany klucza Consul. Serwery pobierały kod równolegle. Pozwoliło to nam utrzymać wysoką prędkość wdrożenia nawet przy ciągłym wzroście systemu.
1. Serwery produkcyjne obserwują klucz Consul. 2. Klucz się zmienia, co informuje serwery o konieczności rozpoczęcia pobierania nowego kodu. 3. Serwery pobierają pliki tarball z kodem aplikacji.
▍Atomowe wdrożenia
Kolejnym rozwiązaniem, które pomogło nam przejść na wielopoziomowy system wdrożeniowy, były wdrożenia atomowe.
Przed wprowadzeniem atomowych wdrożeń każde wdrożenie mogło prowadzić do wystąpienia dużej liczby komunikatów o błędach. Problemem było to, że proces kopiowania nowych plików na serwery produkcyjne nie był atomowy. Sprawiało to, że istniał krótki okres, w którym kod wywołujący nowe funkcje był dostępny zanim same te funkcje stały się dostępne. Kiedy taki kod był wywoływany, prowadziło to do zwracania błędów wewnętrznych. Objawiało się to w nieudanych zapytaniach do API i na "zepsutych" stronach internetowych.
Zespół zajmujący się tym problemem rozwiązał go, wprowadzając pojęcia "gorących" (hot) i "zimnych" (cold) katalogów. Kod w "gorącym" katalogu odpowiada za przetwarzanie ruchu produkcyjnego. W "zimnych" katalogach kod, w trakcie działania systemu, tylko przygotowuje się do użycia. W trakcie wdrożenia 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 na "zimny" katalog, który staje się "gorący" (operacja atomowa).
Podsumowanie: przesunięcie akcentu na niezawodność.
W 2018 roku projekt osiągnął taki poziom, że bardzo szybkie wdrożenie zaczęło szkodzić stabilności produktu. Mieliśmy dość zaawansowany system wdrożeniowy, w który włożyliśmy dużo pracy i czasu. Musieliśmy jedynie przebudować i usprawnić procesy organizacji wdrożeń. Przekształciliśmy się w stosunkowo dużą firmę, której rozwiązania były wykorzystywane na całym świecie do zapewnienia ciągłej łączności i rozwiązywania ważnych problemów. Dlatego w centrum naszej uwagi znalazła się niezawodność.
Musieliśmy uczynić proces wdrażania nowych wersji Slack bardziej bezpiecznym. Ta potrzeba doprowadziła nas do udoskonalenia naszego systemu wdrożeniowego. Właściwie to właśnie tę usprawnioną system omówiliśmy powyżej. W głębi systemu wciąż korzystamy z technologii szybkiego i atomowego wdrażania. Zmieniło się to, jak dokładnie odbywa się wdrożenie. Nasz nowy system jest zaprojektowany do stopniowego wdrażania nowego kodu na różnych poziomach, w różnych środowiskach. Teraz korzystamy z bardziej zaawansowanych narzędzi pomocniczych i systemów monitorujących. Daje nam to możliwość wychwytywania i naprawiania błędów na długo przed tym, gdy mają one szansę dotrzeć do użytkownika końcowego.
Jednak nie zamierzamy na tym poprzestać. Nieustannie udoskonalamy ten system, stosując coraz bardziej zaawansowane narzędzia pomocnicze i środki automatyzacji pracy.
Drodzy Czytelnicy! Jak wygląda proces wdrażania nowych wersji projektów w miejscu, w którym pracujesz?
Źródło: habr.com
