Release and Deployment Management - definicje.

Release and Deployment Management zalicza się do kluczowych elementów procesów IT. Oba są ze sobą ściśle skorelowane, a granice między nimi są bardzo płynne, ale po kolei.

Release Management jest to praktyka, która obejmuje zarządzanie, planowanie, harmonogramowanie i kontrolowanie całego procesu tworzenia oprogramowania poprzez każdy etap i środowisko, w którym się odbywa, w tym testowanie i wdrażanie wydań oprogramowania. Podstawowym celem jest zapewnienie, że integralność środowiska rzeczywistego jest odpowiednio chroniona, a właściwe komponenty są wdrażane i dostępne do użytku.

software developer Craftware

Ostatnim elementem tej układanki jest faza deploymentu, czyli wdrożenia nowego lub zmodyfikowanego wcześniej procesu, aplikacji, dokumentacji lub jakiegokolwiek elementu na odpowiednio przygotowane środowiska testowe, bądź produkcyjne.
Reasumując, celem deployment managementu jest przeniesienie nowego lub zmienionego oprogramowania, sprzętu, dokumentacji, procesów lub dowolnego innego komponentu do środowisk testowych lub produkcyjnych. Może być on również zaangażowany we wdrażanie komponentów do innych środowisk w celu testowania.
Innymi słowy są to dwa nierozłączne procesy występujące naturalnie jeden po drugim, (właściwie to deployment zawiera się w relase managemencie) trochę jak przygotowanie posiłku w celu jego podania do konsumpcji. Po co ktoś miałby przygotować posiłek, żeby ostatecznie go nie skonsumować?

Skoro definicje mamy już przedstawione, skupmy się teraz, na czym opiera się release and deployment management? Nie odkryję Ameryki twierdząc, że jeżeli nie wiadomo od czego zacząć to najlepiej zacząć od początku, czyli planowania.

Planowanie i koordynacja release’u

Planowanie releasu koncentruje się na ciągłym doskonaleniu praktyki zarządzania wydaniami, podejściach i modelach, oraz opracowywaniu planów kompleksowych wdrożeń.

Jest on wykonywany regularnie i wyzwalany przez eventy lub requesty. Regularne przeglądy mogą odbywać się co dwa i trzy miesiące lub częściej, w zależności od skuteczności istniejących modeli i procedur.

Pierwszym krokiem w procesie planowania nowego releasu jest opracowanie roadmapy  dla projektu. Pomoże ona zidentyfikować główne kamienie milowe, cele, a także zostanie wykorzystana do opracowania harmonogramu.

Kolejnym krokiem jest opracowanie szczegółowego harmonogramu projektu. Będzie on identyfikował zadania, które muszą być wykonane, aby osiągnąć kamienie milowe releasu i wyniki. Harmonogram określi również zasoby, które będą wymagane do wykonania zadań oraz czas trwania każdego zadania.

W planowaniu kolejnych releasów warto jednak wdrożyć bardzo popularne ostatnio zwinne zarządzanie releasem. Jest to proces tworzenia backlogu dla nadchodzącego wydania produktu lub aplikacji zamiast tworzyć go całościowo i za jednym podejściem. Proces ten rozpoczyna się od przeglądu backlogu produktu, czyli listy priorytetowych funkcjonalności lub wymagań, które muszą zostać zrealizowane. Następnie product owner definiuje cel wydania, który jest wysokopoziomowym opisem tego, co wydanie powinno osiągnąć.

Gdy harmonogram projektu jest gotowy product owner i zespół deweloperów wspólnie tworzą plan wydania, który powinien wyszczególniać zadania, które muszą zostać wykonane, aby dostarczyć funkcjonalności, jak również harmonogramy dla każdego zadania. Plan ten powinien również identyfikować zasoby, które będą potrzebne do wykonania każdego zadania oraz ryzyka związane z każdym z nich. Ponadto warto ująć, kiedy każda z cech lub wymagań zostanie wdrożona i w jakiej kolejności. Zazwyczaj odbywa się to za pomocą schematu priorytetyzacji, który uwzględnia znaczenie poszczególnych cech i zależności między nimi. Plan wydania jest zazwyczaj tworzony na okres od dwóch do czterech tygodni.

Po jego stworzeniu, kolejnym krokiem jest implementacja funkcjonalności. Wiąże się to zazwyczaj z napisaniem kodu, a później kolejno:

  • wdrożeniem do środowiska testowego,
  • przeprowadzeniem testów – SATów (system acceptance testing), ewentualną naprawą znalezionych bugów i UATów (User Acceptance Tests)
  • zatwierdzeniem ze strony testerów i product ownera
  • wdrożeniem funkcjonalności do środowiska produkcyjnego.

Zanim poinformujemy użytkowników o dostępnej nowej wersji, warto monitorować system przez jakiś czas i ponownie zrobić podstawowe testy, aby upewnić się, że funkcjonalności działają zgodnie z oczekiwaniami i nie wpływają negatywnie na stabilność środowiska produkcyjnego.

Zwinny proces realizacji wydań jest procesem iteracyjnym. Celem każdej iteracji jest dostarczenie funkcjonalności oraz zapewnienie, że spełniają one wyznaczone standardy. Proces jest zazwyczaj powtarzany do momentu, gdy wszystkie funkcjonalności zostaną dostarczone, a organizacja będzie zadowolona z rezultatów. Ponadto należy pamiętać, że elastyczne zarządzanie releasem może być też realizowane poprzez descoping, czyli przerzucenie jednej bądź kilku rzeczy z backlogu do późniejszych releasów, (oczywiście za uprzednią zgodą product ownera) lub przesunięcie terminu wdrożenia testowego/produkcyjnego. Aby lepiej zobrazować sobie całościowy proces, zerknijmy na model cyklu życia rozwoju oprogramowania (SDLC), czyli ogólne ramy koncepcyjne opisujące wszystkie działania w projekcie rozwoju oprogramowania od planowania do utrzymania.

Kto jest zaangażowany w ten proces i kim jest ten ktoś, kto ciągle dopytuje o postępy?

Nie ma sztywno przypisanych ról w procesie release managementu. Związane są one raczej z powierzonymi obowiązkami i uczestnictwa w danych procesach. Struktura i nazewnictwo w każdej firmie może być różne, więc nie zaleca się przypisania na sztywno ról, są one ustalane w zależności od uskutecznianych praktyk. Należy mieć na uwadze, że role to nie są nazwy stanowisk w firmie. Jedna osoba może być przypisana do kilku ról i odwrotnie -b jedna rola do kilku osób. Jak wyżej wspomniałem role zazwyczaj są definiowane w kontekście procesów i aktywności. Z pomocą przychodzi tutaj ITIL, który opisuje rolę właśnie pod tym kątem:

Leader – podejmuje kluczowe w strategicznym rozwoju serwisu, koordynuje aktywności, jest swego rodzaju motorem napędowym

Administrator – rola ta ma za zadanie raportowanie i zarządzania czasem, przypisuje i prioretyzuje zadania

Coordinator/communicator – W tej roli czas poświęca się na komunikację, zarówno wewnętrzną jak i zewnętrzną.

Methods and technical expert – opracowują instrukcje krok po kroku, dokumentują procedury, pracują nad ulepszeniami

Technical expert – ta rola zazwyczaj przypisana jest do inżynierów, którzy mają głębokie doświadczenie teoretyczne i praktyczne w danym nurcie świadczenia usług.

 

Według dobrych praktyk IT, poleca się wyróżnienie jednej specyficznej roli – release manager. Pojawia się ona zazwyczaj w organizacjach, gdzie ilość zaimplementowanych zmian jest znacząca, w szczególności jeżeli chodzi o manualne planowanie. W innych firmach, rola ta może być zaopiekowana przez product lub service ownera. Kiedy jednak zdefiniuje się role release managera, przypisuje się ją do osób z dużą wiedzą danej organizacji w zakresie jej biznesu, produktów, serwisów, technologii i procesów. Rola Release managera wymaga mocnych umiejętności zarządzania projektem, elastyczności, ale też potrzeby zbudowania autorytetu, aby skutecznie koordynować pracę zespołów. A jak można by określić jego skuteczność? Najprościej będzie można go ocenić poprzez:

  • wdrożenia na czas
  • wdrożenia nie przekraczającego wyznaczonego budżetu
  • poprzez nie impaktowanie użytkowników wdrożeniami
  • zaspokajanie potrzeby i oczekiwań użytkowników dzięki spełnieniu powyższych punktów.
oferta-pracy-banner

Mam nadzieję, temat release managementu trochę się rozjaśnił. Naturalnie release management będzie się różnić w zależności od konkretnych potrzeb i celów danej organizacji.  Ponadto warto pamiętać, że każdy release jest okazją do udoskonalenia wszystkiego, od przepływu pracy po listę kontrolną i procesy, ponieważ zespół odkrywa w trakcie, jaki proces  najlepiej sprawdza się w przypadku danego rodzaju release’u – a jaki nie.

Autor
  • Mateusz Bełza
  • Service Manager Service Management & Validation
  • Od 9 lat pracuje w obszarze IT wspierając największe firmy, m.in. z sektora Healthcare & Life Sciences, od 3 lat na stanowisku Service Managera. Odpowiedzialny za koordynację i optymalizację wszystkich niezbędnych działań związanych ze świadczeniem usług

Opracowanie redakcyjne:
Kamil Falarowski
Redakcja tekstu
Chcesz wiedzieć więcej?

Dołącz do naszego newslettera, a nie ominą Cię żadne nowości!