Jeśli tytuł tego artykułu wydał Ci się dziwny, nie jesteś sam. Ja również na pierwszy rzut oka nie zrozumiałabym, o co chodzi. Zauważ, że i tak użyłam słów „rollout” oraz „deployment”, nie zostałeś więc całkowicie pozbawiony kontekstu. Pokazuje to jednak tylko osobliwe piękno branży IT, gdzie wiele terminów nie tłumaczymy na język polski. Posługujemy się terminami angielskimi. Z jednej strony dlatego, że przez większość czasu komunikacja odbywa się w języku angielskim, z drugiej strony, ponieważ terminy te stały się niemalże niezmienialnymi terminami branżowymi, agnostycznymi względem języka, w którym odbywa się komunikacja.
Mowa będzie więc dzisiaj oczywiście o canary rollout, dark launching oraz blue/green deployements. Jest to kontynuacja cyklu z wiedzy o release managemencie. Więcej informacji na ten temat znajdziesz w ostatnim artykule.
Canary rollout
Czy zastanawiałeś się kiedyś, dlaczego posługujemy się terminem canary rollout i co on właściwie znaczy? Myślę, że każda osoba używająca tego terminu podświadomie czuje, że chodzi o dostarczenie czegoś na produkcję na próbę, małymi kroczkami. Czasami jest to naturalnie również powiązane z dostarczeniem czegoś wcześniej niż zakładany termin, kiedy już „musi u wszystkich działać”.
Etymologia tego terminu odnosi się do lat 80-tych XX wieku, kiedy górnicy wydobywający węgiel na dużych głębokościach zabierali ze sobą na dół kanarki. Celem było wykrywanie obecności bezwonnych, niewidocznych, aczkolwiek toksycznych gazów. Jeśli kanarek umierał górnicy wiedzieli, że są w niebezpieczeństwie i powinni się ewakuować. Szczęśliwie w trochę mniej ekstremalnych okolicznościach metafora kanarka stosowana jest w informatyce.
Canary testing to testowanie nowych funkcjonalności lub nowych wersji oprogramowania z rzeczywistymi użytkownikami na środowisku produkcyjnym. Często canary testing bywa używane w tym samym kontekście zamiennie z canary rollout, canary release lub canary deployement. W zasadzie są to określenia odnoszące się do tego samego założenia- robiąc canary rollout zazwyczaj na początku udostępniamy nową wersję aplikacji dla małej grupy użytkowników (na przykład około 5%). Dzięki temu, jeśli coś w naszej nowej wersji aplikacji miałoby nie działać, canary rollout jest w stanie szybko nas o tym ostrzec. Mamy wówczas czas na reakcję i nie musimy stawiać czoła sytuacji, gdy nagle cała produkcja przestaje funkcjonować.
🦋Canary rollout pozwala nam więc zminimalizować ryzyko w czasie releasu oraz wpływ błędów /’bugów’/ produkcyjnych🦋
Dark launching
Dark launching to uruchamianie nowej wersji oprogramowania tylko dla małego odsetka użytkowników- np.. 1% Następnie stopniowo zwiększamy % uruchomienia dla użytkowników i obserwujemy, jak zachowuje się oprogramowanie.
Możesz się teraz zastanawiać, czym wobec tego różni się ono od canary rollout. Dark launching jest do niego bardzo podobny. Jedyna różnica polega na tym, że canary rollout dotyczy całego releasu, natomiast dark launching odbywa sie zazwyczaj dla jednej lub kilku, czasami głównych, funkcjonalności aplikacji.
Celem canary rollout jest minimalizowanie wpływu, jaki błędy będą miały na produkcję poprzez zatrzymanie releasu ZANIM dotknie on większą liczbę użytkowników. Dark launching natomiast koncentruje się na testowaniu funkcjonalności ZANIM będą one dostępne dla szerszego grona użytkowników.
W celu zabezpieczenia przed ewentualnymi błędami w tych funkcjonalnościach, możemy zastosować tak zwane feature flags. Jest to rozwiązanie programistyczne, które umożliwia łatwe wyłączenie danej funkcjonalności (ustawienie flagi, która ją włącza na FALSE). Dzięki temu nie musimy wycofywać całego releasu i jesteśmy w stanie testować pozostałe funkcjonalności w przypadku, gdy tylko jedna z nich okaże się wadliwa.
Dark launching wykorzystywany jest również w swego rodzaju testach A/B, w przypadkach, gdzie chcemy zbadać, jak nowe rozwiązanie wpłynęło na przykład na wysokość sprzedaży.
Przy bardziej ryzykownej wersji wydarzeń czasami istnieje konieczność przetestowania czegoś na infrastrukturze produkcyjnej. Takie okoliczności wystepują, kiedy z różnych względów nie można tego zrobić na innym środowisku. Środowisku, które byłoby pod względem infrastruktury odzwierciedleniem środowiska produkcyjnego, takim jak na przykład „stage” lub „pre-prod”.
Inną sytuacją, w której wykorzystujemy również tryb dark launching jest wdrożenie beta testingu dla jakiejś określonej grupy użytkowników. Jest to wówczas tak zwana wersja pilotażowa („Pilot mode”), która stanowi preludium do pełnego wejścia na produkcję.
Blue/green deployments
W powyższych sekcjach wytłumaczyliśmy progresywne wdrażanie całego releasa za pomocą canary rollout. Wyjaśniłam Wam również jak wdrażać pojedyncze nowe funkcjonalności (dark launching) jednocześnie będąc w stanie wyłączyć każdą z nich z osobna poprzez feature flags. Na koniec został nam najprostszy termin. Jakby to było, gdybyś mógł w jednej chwili przełączyć się pomiędzy starą i nową wersją aplikacji? Przykładowo co 2 tygodnie wdrażałbyś nową wersje, monitorował i w razie konieczności przełączał się z powrotem na starszą wersję? Czy Twój zespół nie czułby się wtedy bezpieczniej? Z pewnością. Właśnie wychodząc na przeciw takim potrzebom Amazon w ramach usług AWS zaproponował nowe rozwiązanie Blue/Green deployment.
Blue/Green deployment jest praktyką z zakresu releasowania aplikacji, która zakłada utrzymywanie w gotowości dwóch środowisk produkcyjnych: green i blue. Środowisko Green zawiera starszą, uprzednio aktualną wersję aplikacji, środowisko Blue wersję nową. Jeśli tylko wystąpi taka konieczność możemy przełączyć się na starsze środowisko, łagodząc tym samym skutki zdarzenia.
Blue/green delivery jest jedną z best practices wykorzystywanych operacyjnie, która pozwala nam na dokonywanie zmian w infrastrukturze przy jednoczesnym minimalizowaniu ryzyka. Należy zwrócić uwagę, że nie jest to to samo, co wykorzystywanie features flags, ponieważ one umożliwiają nam dokonywanie zmian w pojedynczych funkcjonalnościach oprogramowania. Blue/green deployment natomiast przełącza całe rozwiązanie. Mówi się, że blue/green deployment to jedno z najlepszych rozwiązań devopsowych, podczas gdy feature flags są rozwiązaniem developerskim.
Zastanawiasz się, czy można połączyć blue/green deployment z feature flags i jak to może działać w praktyce? Załóżmy, ze wraz z zespołem przygotowujecie nowy release dotyczący pięciu nowych funkcjonalności. Krótko po dostarczeniu rozwiązania na produkcję okazuje się, że jedna z funkcjonalności nie działa i powoduje przerwanie działania aplikacji. Posiadając wdrożone blue/green deployements możesz w łatwy sposób wykonać rollback do poprzedniej wersji oprogramowania. Tracisz jednak wtedy również pozostałe 4 funkcjonalności, które mógłbyś dostarczyć. Mając do dyspozycji jednak jeszcze dodatkowo feature flags możesz wyłączyć tylko jedną problematyczną funkcjonalność. Pozostałe 4 mogą wciąż funkcjonować normalnie. Pełna elastyczność!
