Być może niejednokrotnie zdarzało Ci się słyszeć dyskusje o releasach, w szczególności, jeśli planowaliście wejście na produkcję lub już na niej byliście. Releasach, a więc niczym innym jak wydaniach kolejnych wersji aplikacji. Każda wersja może zawierać w sobie większe lub mniejsze zmiany, dlatego często mówi się, że release to zbiór zmian/ zbiór funkcjonalności. Mając na uwadze, czy są releasy, dzisiaj pogłębimy zrozumienie zagadnienia jakim jest release management process a więc proces zarządzania releasami.

Proces release managementu

Proces release managementu zawiera planowanie, przygotowywanie harmonogramów, kontrolowanie całego cyklu wytwarzania oprogramowania od fazy ustalania wymagań po testy i deployementy na różne środowiska (np. środowisko testowe, stage czy produkcyjne). Release management jest skoncentrowany na kontrolowaniu tego, jak zmiany przepływają przez wszystkie środowiska pre-produkcyjne docierając finalnie do produkcji.

Możemy powiedzieć, że obejmuje następujące etapy:

• Zatwierdzenie zmiany/pojawienie się nowych wymagań
• Planowanie release, ( w jego trakcie powinny zostać również, najczęściej przez analityków biznesowych, zdefiniowane wymagania oraz oszacowana przynajmniej zgrubnie ilość pracy do zrobienia)
• Przygotowywanie releasu- implementacja rozwiązania
• Testowanie releasu (często obejmujące wiele różnych środowisk)
• Testy akceptacyjne użytkownika (ang. UAT – User Acceptance Tests)
• Przygotowywanie releasu do dostarczenia na produkcję
• Deployement

Ostatecznym celem zarządzania releasami jest zapewnienie, że zakończą się one sukcesem i deployement na produkcję przebiegnie tak bezproblemowo jak to tylko możliwe. Chcemy, aby był zauważalny dla użytkownika końcowego tylko w sposób pozytywny – poprzez dostrzeżenie nowych lub odmienionych funkcjonalności.

Warto wspomnieć również, że testowanie danej wersji często obejmuje wiele cykli testowania czasami poprzecinanych krótszymi fazami stabilizacji rozwiązania (ang. remediation).

Istotne aspekty i ryzyka

W zakresie planowania releasu koniecznie musimy wziąć pod uwagę nie tylko terminy dostarczania i estymowane czasy trwania poszczególnych etapów przygotowań, ale, co niebywale istotne, również zależności pomiędzy zespołami i ewentualne konfigurowalne aspekty rozwiązań. Wszystko rozbija się więc o dobrze zdefiniowane wymagania, a także jasność co do tego, jakie czynności potrzebujemy wykonać, aby produkt finalnie powstał.

Dużym ryzykiem jest przy tym brak wnikliwości i analizy potrzebnych elementów ZANIM rozwiązanie powstanie. Może się bowiem okazać, że deklarowany przez zespół komponent tak naprawdę nie jest w stanie działać samodzielnie bez odpowiednio dostosowanego API. Obrazki, które mamy pokazać w aplikacji nie zostały wygenerowane przez grafików, a tłumaczenia dla danego języka nie są jeszcze gotowe. Z naszego releasu nic więc nie będzie.

Innym aspektem jest uzgadnianie rozmieszczenia wersji w czasie na różnych środowiskach. Warto również zastanowić się nad ustanowieniem odpowiedniej numeracji kolejnych buildów, a także ustanowieniem kadencji(rytmu) dostarczania rozwiązań. Przykładowo jeden lub dwa razy w tygodniu. Inaczej rozwiązanie każdego buga będziemy dostarczać w osobnym buildzie i prędzej czy później zespół się w tym pogubi.

Definicja sukcesu nowego wydania

Zastanawiasz się wobec tego, co świadczy o sukcesie nowego releasu? Ostateczna odpowiedź jest prosta- zadowolenia użytkowników, które przyniesie wartość klientowi i wpłynie również na jego satysfakcję. Zakładając jednak, że wiemy co i dlaczego dostarczamy, a zdefiniowane dla releasu wymagania zostały wcześniej odpowiednio zweryfikowane, możemy powiedzieć, że udany release:

• jest dostarczony na czas
• jest dostarczony w zakładanym budżecie
• nie ma lub ma zaniedbywalny negatywny wpływ na istniejących użytkowników
• przynosi biznesowi WARTOŚĆ

Każdy dobry Release Manager powinien więc stawiać sobie za cel, aby:

• Odpowiednio wcześnie identyfikować i mitigować ryzyka w czasie całego cyklu wytwarzania oprogramowania (danego releasu)
• Dbać o to, aby zrozumienie i stan wiedzy wszystkich zespołów zaangażowanych w proces wytwarzania releasu był taki sam
• Wspierając Product Ownera zwracać uwagę na to, aby cele danego releasu były zgodne z celami biznesowymi firmy
• Dbać o przestrzeganie terminów
• Zadawać właściwe pytania liderom technicznym projektu, które pomogą im zidentyfikować jeszcze więcej potencjalnych nieścisłości