Żarty na temat piątkowych deploymentów krążą w internecie od dawna. Nieustannie też pojawiają się nowe. Dlatego dziś postaramy się odpowiedzieć na pytanie, o co tak na prawdę w nich chodzi i dlaczego deployment w piątek nie jest najlepszym pomysłem.

Czym jest rzeczony deployment? W największym uproszczeniu i skrócie – to wydanie nowej wersji oprogramowania na serwery produkcyjne. Brzmi jak coś przydatnego i najlepiej wdrożyć to od razu, prawda? Dlaczego więc nie w piątek? Powodów może być bardzo wiele, ale postaramy się przytoczyć niektóre możliwe scenariusze.

Oczywiście jeżeli wdrażane oprogramowanie lub nowa wersja obecnego była testowana bardzo długo i dokładnie, to nie mamy się czego obawiać… Czy aby na pewno? Nawet najlepiej przetesowana poprawka może zachować się nieprzewidywalnie. A może w ogóle nie było testów, ale hołdujesz zasadzie „Rób deploy w piątek – będziesz mieć cały weekend, żeby poprawić swoje błędy”? Zwolenników tego drugiego podejścia wcale nie brakuje.

Co może się wydarzyć?

Przede wszystkim należy rozważyć scenariusz, w którym środowisko testowe nie było idealnym odwzorowaniem produkcyjnego. Testy zostały przeprowadzone dokładnie, ale po już wdrożeniu na produkcję pokazały się poważne błędy. Zwykle środowisko produkcyjne zawiera znacznie więcej danych, co może stać się przyczyną problemu, który nie sposób było przewidzieć sprawdzając nową wersję oprogramowania w środowisku testowym.

Podczas testów nie jesteśmy również w stanie idealnie odwzorować zachowań użytkowników. Jednym z najczęściej powtarzanych i najmocniejszych argumentów przeciwko wdrożeniom w piątek jest wsparcie w weekend. Lub raczej jego brak (lub ograniczony zakres). Większość ludzi nie pracuje w weekendy. Czas od piątkowego wieczoru do niedzieli przeznaczony jest na odpoczynek i odstresowanie po całym tygodniu pracy. Pamiętaj też, że oprócz wsparcia wewnątrz własnego zespołu musisz wziąć pod uwagę możliwe problemy ze wsparciem zewnętrznym. Czy jeśli problem będzie dotyczył zewnętrznego komponentu, to w razie czego możesz sobie pozwolić na dwa dni przestoju?

Pisaliśmy powyżej o długim i dokładnym testowaniu. Nie daje ono gwarancji powodzenia, ale może zminimalizować ryzyko, że coś przestanie działać. Pytaniem, które należy sobie zadać jest: czy testy nowego oprogramowania były dostatecznie długie i odwzorowywały zachowanie aplikacji podczas wysokiego obciążenia? Jest to trudne zadanie, ale wysiłek włożony w odwzorowanie warunków produkcyjnych obniży szanse, że finalnie coś pójdzie nie tak. Niemniej, jak już wspomnieliśmy, nie wszystko możesz przetestować, więc deployment w dalszym ciągu obarczony jest ryzykiem wystąpienia nieprzewidzianych błędów.

Kolejnym pytaniem, które warto sobie zadać jest: jak poważne zmiany zamierzamy wdrożyć i ile czasu zajmie wprowadzenie nowej wersji oprogramowania? Czy będzie możliwe jej wycofanie w razie awarii? Czy nieprzewidziany problem wpłynie na usługi Twoich klientów? Jeśli ich firmy nie pracują w weekendy, to możesz dopiero w poniedziałek dowiedzieć się, że przez dwa dni ich usługi nie działały poprawnie i z tego powodu ponieśli straty. Robiąc wdrożenie w inne dni robocze otrzymasz szybszy odzew i będziesz w stanie od razu zareagować.

Następne zagadnienie związane z deploymentem to obserwacja aplikacji i reakcja na problemy wydajnościowe po zmianach. Wszystko oczywiście zależy od skali wdrożenia, ale bezpieczniej jest reagować już przy pierwszych sygnałach wskazujących na niespodziewane obciążenie systemów.

Powyższe obawy, to oczywiście czarne scenariusze i nie zawsze muszą się zdarzyć. Mimo to, ryzyko ich pojawienia się jest na tyle duże, że nie można nie wziąć ich pod uwagę. Zadaj więc sobie pytanie: czy Twoja firma jest gotowa na weekendowe rozwiązywanie problemów po nieudanym piątkowym deploymencie? Jeśli zależy Ci, by weekendy były czasem odpoczynku dla Ciebie i Twoich współpracowników, to gorąco zachęcamy do działań w inne dni robocze. Takie podejście zdecydowanie ułatwia pracę i minimalizuje ryzyko niepowodzenia wdrożeń 🙂