Programista skończył pracę i przyszedł czas na wdrożenie aplikacji? W prostym scenariuszu mogłoby tak to wyglądać. Żeby jednak deploy przebiegł bez większych problemów, Project Manager z zespołem powinni wykonać szereg czynności, które zabezpieczą projekt przed nieudanym wdrożeniem.

Wdrożenie na produkcję (ang. deploy) to przeniesienie efektów pracy zespołu deweloperskiego na środowisko użytkownika docelowego. Zastanawiasz się, co może pójść nie tak? Poniżej przedstawiamy 4 rzeczy, na które warto zwrócić uwagę przy planowaniu deploymentu.

1. Testy przed deploymentem aplikacji na produkcję – zgodność z kryteriami akceptacji 

Efekt zespołu to tzw. przyrost, czyli działająca funkcjonalność wytworzona przez zespół deweloperski. Przed każdym wdrożeniem produkcyjnym aplikacja powinna być właściwie przetestowana. Podczas testowania aplikacji należy wziąć pod uwagę kryteria akceptacji projektu spisane przy planowaniu sprintu oraz definicję ukończenia (tzw. definition of done). 

Testy powinny odbywać się na środowisku deweloperskim jak najbardziej zbliżonym do produkcyjnego. Jeśli środowisko produkcyjne korzysta z obszernych baz danych (np. baza użytkowników), to zespół powinien zadbać o to, żeby podobna ilość danych była dostępna do testów na środowisku deweloperskim. Takie działanie może być konieczne szczególnie przy migracji danych z jednej aplikacji do drugiej. 

 Można to zrobić na dwa sposoby: 

  • wykorzystując fixture’y do wygenerowania fałszywej bazy danych,
  • wykonując anonimizację bazy produkcyjnej i wrzucając ją na środowisko lokalne.

Gruntownie przetestowany przyrost z uwzględnieniem wszystkich obszarów, których dotyka, może zabezpieczyć przed niepowodzeniem wdrożenia. Stosujcie w zespole zasadę ograniczonego zaufania do siebie nawzajem. Sprawdzajcie się i nie dopuszczajcie do sytuacji, w której członek zespołu będzie zapewniał, że coś zadziała na produkcji. Deploy bez wykonanego review niesie duże ryzyko, że nie zadziała.

Deploy aplikacji
Źródło: https://9gag.com/gag/av8A6DZ

2. Sprawdź aktualność uzasadnienia biznesowego historyjki przed wdrożeniem aplikacji na produkcję 

Nierzadko zdarza się, że efekt, który wytworzył zespół, traci uzasadnienie biznesowe. Grozi to rezygnacją z wdrożenia danego przyrostu na środowisko produkcyjne. Przyczyną takiej sytuacji może być bardzo zmienne, burzliwe otoczenie projektu lub niewłaściwe planowanie harmonogramu. Niezależnie od tego, co było powodem, upewnij się, że dany przyrost spełnia warunki biznesowe. Są to pierwotne założenia, dla których była tworzona funkcja. Zweryfikuj, czy uzasadnienie jest aktualne, a użytkownicy aplikacji oczekują na wdrożenie przyrostu.  

Dla przykładu: rozważmy aplikację oznaczającą obszar Polski jako strefę zieloną, żółtą lub czerwoną w zależności od liczby zachorowań na COVID-19. Przy zakończeniu prac, okazuje się, że cała Polska staje się obszarem czerwonym. Pomimo tego, że zachorowania z czasem maleją w poszczególnych regionach, nie stają się one automatycznie inną strefą (kolorem) zgodnie z pierwotnymi założeniami. Uzasadnienie wdrożenia tej funkcji do aplikacji nie jest w takiej sytuacji oczywiste, skoro podstawowym założeniem było oznaczanie stref Polski kolorem w zależności od liczby zachorowań.

Innym przykładem może być zmiana kierownictwa i często idąca za tym nowa wizja projektu. Zmiana kierunku działania nie musi być zbieżna z ostatnio wypracowanym przyrostem. Może wiązać się to z odłożeniem wytworzonego efektu na półkę. 

Takie sytuacje są rzadkie. Niemniej jednak przyrost może utracić swoje uzasadnienie biznesowe. Przed każdym wdrożeniem produkcyjnym należy upewnić się, że wdrażana funkcja przyniesie korzyści zarówno użytkownikowi, jak i klientowi, który złożył zamówienie na daną funkcjonalność. 

3. Zaplanuj zasoby przed wejściem nowej wersji aplikacji na produkcję

Podczas wdrożenia nowej wersji aplikacji na produkcję ważne jest, aby odpowiednio zaplanować zasoby. Proces wdrażania obarczony jest sporym ryzykiem niepowodzenia, więc warto zwrócić uwagę na:

  • harmonogram dostępności zespołu deweloperskiego,
  • porę dnia (chwilowa niedostępność dla użytkowników),
  • wydarzenia klienta/użytkownika wymagające 100% dostępności i stabilności aplikacji. 

Harmonogram dostępności zespołu deweloperskiego

Zwróć uwagę, czy wszyscy członkowie zespołu są dostępni. W razie problemów z wdrożonymi funkcjami umożliwi to szybką reakcję i wprowadzenie ewentualnych poprawek (tzw. hot fix). Mimo wykonania testów na środowisku deweloperskim często zdarza się, że przyrost na środowisku produkcyjnym zachowuje się inaczej. Z tego powodu gotowość zespołu do ewentualnych poprawek jest bardzo ważna. 

Pora dnia wdrożenia

Upewnij się, że godzina wdrożenia jest właściwa i ustal to z klientem. Czy to mają być godziny poranne, czy wieczorne? Deploy wiąże się z chwilową niedostępnością aplikacji, dlatego ustalenie czasu deploymentu jest bardzo ważne. Pora dnia zależy ściśle od biznesu i rodzaju aplikacji. Wybierz tę godzinę, w której użytkownicy nie korzystają z aplikacji lub kiedy użytkowników jest niewielu. 

I pamiętaj – nie wykonuj wdrożenia w piątki. Ani Ty, ani Twój zespół nie chcecie pracować w weekend, aby zlikwidować ewentualne błędy lub awarie. Aktualizacja środowiska produkcyjnego to wprowadzenie czynnika niepewności. Nie ma gwarancji czy przyjmie się w taki sposób, jak na środowisku deweloperskim. Zapewnij spokojny weekend sobie, zespołowi i Twojemu klientowi i nie planuj nigdy większego wdrożenia w piątek.

Wdrożenie na produkcję
Źródło: https://www.facebook.com/JustJoinIT/posts/2611673209071142?comment_id=2620877361484060

Ważne wydarzenie u klienta

Zweryfikuj, czy w firmie klienta/użytkownika nie nadchodzi ważne wydarzenie. Dla przykładu: w aplikacji sprzedającej kosmetyki może być to Black Friday. Jest to jeden ze szczególnych dni w roku, w którym sklepy internetowe przeżywają prawdziwe oblężenie. Może to być również ważna prezentacja systemu i jego funkcjonalności zarządowi firmy.

W takich przypadkach warto być przygotowanym wcześniej. Nie ma potrzeby podnoszenia ryzyka, dlatego na co najmniej 2-3 dni przed ważnym wydarzeniem nie należy robić wdrożenia produkcyjnego.

4. Wymagania techniczne przy wdrażaniu nowej wersji oprogramowania na serwer

Przy wdrażaniu nowej wersji aplikacji na serwer zwróć także uwagę na zasoby serwera. Upewnij się, że na serwerze jest wystarczająco miejsca na aktualizację środowiska. W przypadku skalowalności zasobów sprawdź, czy jest odpowiednia ilość środków do ich utrzymania. 

Warto również upewnić się, że w trakcie deploymentu nie będą wykonywane żadne prace serwisowe serwerów, na których przechowywana jest aplikacja. Nałożenie się tych dwóch procesów może wywołać spore problemy. 

Przydatna jest także umowa SLA (ang. Service Level Agreement), w której można dokładnie zawrzeć odpowiedzialność stron w konkretnych sytuacjach. Umowa SLA określa co w przypadku wystąpienia awarii serwera, kto podejmuje działania, aby uruchomić na nowo serwer, oraz ile ma na to czasu.

Warto też określić czas reakcji w przypadku wystąpienia awarii w samej aplikacji. Umowa ma za zadanie ochronić zespół, aby nie pojawiły się zbędne pretensje przy wystąpieniu usterki serwera.

Deploy na produkcję
Źródło: https://makeameme.org/meme/lets-deploy

Udany deploy 

Każdy, kto uczestniczy w procesie deploymentu nowej wersji aplikacji na produkcję, ma świadomość, jak bardzo jest to skomplikowane oraz ile czynników ma wpływ na poprawne wdrożenie. Powyższe 4 obszary warto wziąć pod uwagę przy deploymencie. Razem z zespołem możecie uznać je za swego rodzaju checklistę do odhaczenia przed każdym deployem. Odpowiednie podejście do procesu implementacji może ograniczyć nieprzyjemne skutki takie jak: awarie, błędy i w konsekwencji roszczenia ze stron bezpośrednio dotkniętych, czyli klientów i użytkowników. Zastosuj zasadę ograniczonego zaufania i sprawdź każdy aspekt, który może zaburzyć proces, i tak skomplikowanego już, wdrożenia na produkcję. Powodzenia!

Dodaj komentarz