Zarządzanie wersjami: Różnice pomiędzy wersjami
Nie podano opisu zmian |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 19 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Zarządzanie wersjami''' | '''[[Zarządzanie]] wersjami''' - [[proces]] zawierający w sobie takie działania jak konsultowanie, [[planowanie]] oraz zarządzanie zmianami w danym produkcie lub usłudze. Zarządzanie wersjami charakteryzuje się koncentracją na wysokiej jakości rezultatów działań w ramach rozwijania [[usługi]] lub produktu od momentu inicjacji prac aż do publikacji [Howard 2012, s.1-2]. Celem tego podejścia jest przede wszystkim pewność, że poczynione w trakcie realizacji produktu zmiany zostały odpowiednio wdrożone w środowisku IT przy jednoczesnym minimalizowaniu ryzyka dla biznesowej strony przedsięwzięcia [Shanmugasundaram, Sarojini 2018, s. 5]. W ramach powtarzalnego i kontrolowanego procesu zarządzania wersjami, wersje oprogramowania powinny być wydawane na czas, przy zachowaniu najwyższej jakości i zgodności z wymaganiami [Howard 2012, s. 1-2]. | ||
W zakres zarządzania wersjami wchodzą takie działania jak [Shanmugasundaram, Sarojini 2018, s. 5]: | W zakres zarządzania wersjami wchodzą takie działania jak [Shanmugasundaram, Sarojini 2018, s. 5]: | ||
* szybka implementacja zmian w oprogramowaniu przy jednoczesnym optymalizowaniu kosztów i zmniejszaniu ryzyka, | * szybka [[implementacja]] zmian w oprogramowaniu przy jednoczesnym optymalizowaniu kosztów i zmniejszaniu ryzyka, | ||
* wydawanie wersji według ustalonego harmonogramu oraz według kryteriów gotowości danej wersji, wśród których wymienia się m.in. jakość danej wersji, plan wdrażania i wycofywania, a także plan zarządzania ryzykiem, | * wydawanie wersji według ustalonego harmonogramu oraz według kryteriów gotowości danej wersji, wśród których wymienia się m.in. [[jakość]] danej wersji, [[plan]] wdrażania i wycofywania, a także [[plan zarządzania ryzykiem]], | ||
* prowadzenie szkoleń i dokumentacji związanych z zapewnieniem wsparcia technicznego dla użytkowników wprowadzanej usługi lub produktu, mających na celu ułatwienie korzystania. | * prowadzenie szkoleń i dokumentacji związanych z zapewnieniem wsparcia technicznego dla użytkowników wprowadzanej usługi lub produktu, mających na celu ułatwienie korzystania. | ||
Metody związane z zarządzaniem wersjami stosuje się w organizacjach, które mierzą się z następującymi czynnikami [PMI]: | Metody związane z zarządzaniem wersjami stosuje się w organizacjach, które mierzą się z następującymi czynnikami [PMI 2021]: | ||
* złożona infrastruktura operacyjna, | * złożona [[infrastruktura]] operacyjna, | ||
* wiele zespołów pracujących równolegle, | * wiele zespołów pracujących równolegle, | ||
* brak doświadczenia zespołów. | * brak doświadczenia zespołów. | ||
W przypadku złożonej infrastruktury operacyjnej istnieje wysokie [[ryzyko]], że [[wdrożenie]] nowych funkcji do środowiska produkcyjnego uszkodzi oprogramowanie. Na tę [[złożoność]] wpływa m.in. stosowanie wielu różnych, mocno ze sobą powiązanych technologii. W organizacji, gdzie pracuje wiele zespołów deweloperskich przy współdzielonym środowisku rośnie [[prawdopodobieństwo]] kolidowania ze sobą zmian wprowadzanych przez te zespoły. Nowe zespoły często nie zdążyły nabrać jeszcze doświadczenia związanego z pracą w danym środowisku, tym samym będą potrzebowały pomocy przy wydawaniu wersji. Taka pomoc polegać może na wsparciu przy planowaniu, ustalaniu skutecznej strategii wydawania oraz koordynacji działań zespołu [PMI 2021]. | |||
<google>n</google> | |||
== Proces zarządzania wersjami == | ==TL;DR== | ||
Za proces zarządzania wersjami odpowiada menedżer wersji (ang. ''release manager''). Osoba na tym stanowisku zajmuje się doprowadzeniem prac nad wersją aż do jej pełnej gotowości do publikacji. Ustala również cele poszczególnych etapów prac nad daną wersją [Shanmugasundaram, Sarojini 2018, s. 5]. Wyróżnia się również taką rolę jak menedżer projektu wersji (ang. ''release project manager''), który wraz z menedżerem wersji i innymi kluczowymi interesariuszami może stanowić zespół planowania wersji (ang. ''release planning team'') [Rasa, Wahida Banu 2019, s. 21]. | Zarządzanie wersjami to proces konsultowania, planowania i zarządzania zmianami w produkcie lub usłudze. Celem jest zapewnienie wysokiej jakości rezultatów i minimalizowanie ryzyka. Proces obejmuje szybką implementację zmian, wydawanie wersji według harmonogramu, szkolenia i wsparcie techniczne. Wyróżnia się różne metody wydawania wersji, takie jak "big bang" czy podejście etapowe. Dobre praktyki to współpraca DevOps, automatyzacja, zrozumienie procesu wydawania wersji i zarządzanie środowiskiem testowym. | ||
==Proces zarządzania wersjami== | |||
Za [[proces zarządzania]] wersjami odpowiada [[menedżer]] wersji (ang. ''release [[manager]]''). Osoba na tym stanowisku zajmuje się doprowadzeniem prac nad wersją aż do jej pełnej gotowości do publikacji. Ustala również [[cele]] poszczególnych etapów prac nad daną wersją [Shanmugasundaram, Sarojini 2018, s. 5]. Wyróżnia się również taką rolę jak menedżer projektu wersji (ang. ''release project manager''), który wraz z menedżerem wersji i innymi kluczowymi interesariuszami może stanowić [[zespół]] planowania wersji (ang. ''release planning team'') [Rasa, Wahida Banu 2019, s. 21]. | |||
Proces zarządzania wersjami składa się z następujących podprocesów [Rasa, Wahida Banu 2019, s. 21-24]: | Proces zarządzania wersjami składa się z następujących podprocesów [Rasa, Wahida Banu 2019, s. 21-24]: | ||
* planowanie wersji, | * planowanie wersji, | ||
* projektowanie, tworzenie oraz konfigurowanie wersji, | * [[projektowanie]], tworzenie oraz konfigurowanie wersji, | ||
* akceptacja wersji, | * [[akceptacja]] wersji, | ||
* dystrybucja i instalacja wersji. | * [[dystrybucja]] i instalacja wersji. | ||
Podczas '''planowania wersji''' powinno się wziąć pod uwagę wszystkie jej aspekty. Menedżer odpowiedzialny za wydanie kompletuje zespół, wraz z którym definiuje podejście i zakres prac nad daną wersją. Te następnie dokumentuje się w planie wydania. Jeżeli plan zostanie zaakceptowany przez decyzyjne osoby w organizacji, zespół przystępuje do kolejnego etapu. '''Etap projektowania, tworzenia i konfiguracji wersji''' poddawany jest ciągłej weryfikacji przez menedżerów, którzy sprawdzają stan realizacji zadań danych zespołowi. Ustala się także plan testów. Po stworzeniu wersji dokonuje się przeglądu planu, a także naprawia błędy, które napotkano. Jeżeli wersja jest już w pełni sprawna, plan wersji zostaje przekazany menedżerowi wersji do ostatecznego zatwierdzenia. Następnie testuje się zaakceptowaną wersję i planuje działania związane z wdrożeniem wersji do użytkowników. Nim to jednak nastąpi, wersja musi się spotkać z '''akceptacją''' interesariuszy biznesowych oraz pracowników IT w ramach testów akceptacyjnych. Wyniki testów są dokumentowane oraz porównywane do wyników oczekiwanych. Jeżeli wyniki są satysfakcjonujące przystępuje się do wdrożenia wersji. Finalizuje się wówczas plan wydania, który zostaje jeszcze zweryfikowany przez menedżera wersji. Następnie rozpoczyna się etap '''instalacji i dystrybucji'''. Wdrożoną wersję wysyła się do kierownika projektu wydania, który weryfikuje zgodność wersji z założonymi kryteriami. Na tej podstawie określa się, czy cały proces zakończył się pomyślnie. W przeciwnym przypadku inicjuje się proces zarządzania zmianą [Rasa, Wahida Banu 2019, s. 21-24]. | Podczas '''planowania wersji''' powinno się wziąć pod uwagę wszystkie jej aspekty. Menedżer odpowiedzialny za wydanie kompletuje zespół, wraz z którym definiuje podejście i [[zakres]] prac nad daną wersją. Te następnie dokumentuje się w planie wydania. Jeżeli plan zostanie zaakceptowany przez decyzyjne osoby w organizacji, zespół przystępuje do kolejnego etapu. '''Etap projektowania, tworzenia i konfiguracji wersji''' poddawany jest ciągłej weryfikacji przez menedżerów, którzy sprawdzają stan realizacji zadań danych zespołowi. Ustala się także plan testów. Po stworzeniu wersji dokonuje się przeglądu planu, a także naprawia błędy, które napotkano. Jeżeli wersja jest już w pełni sprawna, plan wersji zostaje przekazany menedżerowi wersji do ostatecznego zatwierdzenia. Następnie testuje się zaakceptowaną wersję i planuje działania związane z wdrożeniem wersji do użytkowników. Nim to jednak nastąpi, wersja musi się spotkać z '''akceptacją''' interesariuszy biznesowych oraz pracowników IT w ramach testów akceptacyjnych. Wyniki testów są dokumentowane oraz porównywane do wyników oczekiwanych. Jeżeli wyniki są satysfakcjonujące przystępuje się do wdrożenia wersji. Finalizuje się wówczas plan wydania, który zostaje jeszcze zweryfikowany przez menedżera wersji. Następnie rozpoczyna się etap '''instalacji i dystrybucji'''. Wdrożoną wersję wysyła się do kierownika projektu wydania, który weryfikuje zgodność wersji z założonymi kryteriami. Na tej podstawie określa się, czy cały proces zakończył się pomyślnie. W przeciwnym przypadku inicjuje się proces zarządzania zmianą [Rasa, Wahida Banu 2019, s. 21-24]. | ||
== Metody wydawania wersji == | ==Metody wydawania wersji== | ||
Wyróżnia się kilka możliwości przeprowadzenia procesu tworzenia i wydawania wersji. Wybiera się ją w zależności od rozmiaru prac związanych z daną wersją, a także biorąc pod uwagę samą organizację [Shanmugasundaram, Sarojini 2018, s. 9]. | Wyróżnia się kilka możliwości przeprowadzenia procesu tworzenia i wydawania wersji. Wybiera się ją w zależności od rozmiaru prac związanych z daną wersją, a także biorąc pod uwagę samą organizację [Shanmugasundaram, Sarojini 2018, s. 9]. | ||
Metody wydawania wersji prezentują się następująco [Shanmugasundaram, Sarojini 2018, s. 9]: | Metody wydawania wersji prezentują się następująco [Shanmugasundaram, Sarojini 2018, s. 9]: | ||
* | * "big bang", | ||
* podejście etapowe, | * podejście etapowe, | ||
* metoda | * [[metoda]] "push", | ||
* metoda | * metoda "pull", | ||
* metoda automatyzacji, | * metoda automatyzacji, | ||
* wdrażanie ręczne. | * wdrażanie ręczne. | ||
'''Podejście | '''Podejście "big bang"''' oznacza udostępnianie wersji wszystkim końcowym użytkownikom w tym samym czasie. W '''podejściu etapowym''' wersję udostępnia się wstępnie tylko jednej, określonej grupie użytkowników końcowych, a samo wydawanie odbywa się zgodnie z ustalonym wcześniej harmonogramem. '''Podejście "push"''' również zakłada wdrażanie wersji zgodnie z założonym harmonogramem. Jednak przy tej metodzie użytkownicy końcowi nie mogą sami wybrać momentu, kiedy skorzystają z wersji, gdyż ten jest odgórnie ustalony. '''Metoda "pull"''' oznacza udostępnianie wersji według ustalonego harmonogramu z tą różnicą do poprzedniego podejścia, że użytkownicy końcowi sami decydują, kiedy skorzystają z nowej wersji. '''Podejście automatyzacji''' zakłada wykorzystanie metod automatycznego wydawania wersji do użytkowników końcowych. '''Wdrażanie ręczne''' oznacza wykonywanie czynności związanych z wydawaniem wersji w sposób manualny. Oznacza to konieczność ciągłego monitorowania i pomiaru wpływu tych czynności na wydanie [Shanmugasundaram, Sarojini 2018, s. 9]. | ||
== Dobre praktyki == | ==Dobre praktyki== | ||
Wyróżnia się kilka praktyk, które są pomocne przy realizacji procesu zarządzania wersjami. Są to m.in | Wyróżnia się kilka praktyk, które są pomocne przy realizacji procesu zarządzania wersjami. Są to m.in [Shanmugasundaram, Sarojini 2018, s. 9-10]: | ||
* | * współ[[praca]] [[DevOps]], | ||
* automatyzacja, | * [[automatyzacja]], | ||
* przyjęcie zwinnego podejścia do zarządzania, | * przyjęcie zwinnego podejścia do zarządzania, | ||
* zrozumienie, analiza i ocena procesu wydawania wersji, | * zrozumienie, analiza i [[ocena]] procesu wydawania wersji, | ||
* zarządzanie preprodukcyjnym środowiskiem. | * zarządzanie preprodukcyjnym środowiskiem. | ||
Zespoły deweloperskie i operacyjne powinny ściśle ze sobą '''współpracować'''. W przypadku problemów komunikacyjnych lub braku odpowiedniej synchronizacji praca nad wspólnymi zadaniami czy naprawianie błędów może odbywać się z dużymi opóźnieniami, co może spowodować straty w organizacji. '''Automatyzacja''' jest metodą, która pozwala na szybkie wprowadzanie zmian. Istotnym jest, aby organizacja zidentyfikowała te działania, które można zautomatyzować. W przypadku błędów, niektóre narzędzia związane z automatyzacją pozwalają na określenie awarii, powrotu do poprzedniego stanu pozbawionego danego błędu i sprawne wprowadzenie nowych zmian. Zmiana w dotychczasowym, nieusprawnionym procesie zarządzania wersjami może być trudnym przedsięwzięciem, zwłaszcza dla dużych organizacji wykorzystujących wiele różnych technologii i procesów. Aby usprawnić ten proces, organizacja powinna przyjąć '''bardziej zwinne podejście do zarządzania''' i, tym samym, wprowadzić dobre praktyki polegające na m.in. dostarczaniu najwyższej możliwej wartości biznesowej, eliminowaniu marnotrawstwa, ciągłym doskonaleniu się pracowników itd. Do '''analizy i lepszego zrozumienia procesu''' wydawania wersji pomocna jest metoda mapowania strumienia wartości. Pozwala ona lepiej zrozumieć dane działania realizowane wewnątrz procesu, ich konsekwencje w przyszłości oraz wartość dodaną dla organizacji i klienta. Ponadto dzięki niej możliwa jest ocena różnych etapów prac zespołu oraz zaplanowanie działań mających na celu ich zoptymalizowanie. Pomyślna realizacja procesu wydawania wersji jest uzależniona także od '''dobrze zorganizowanych środowisk testowych i preprodukcyjnych'''. W tych działaniach pomocny jest ustalony harmonogram pozwalający na sprawne zarządzanie testami poprzez m.in. wgląd w to, kto jest odpowiedzialny za jakie czynności i w jakim środowisku. Podgląd powinien zawierać również ustalone terminy wydań i planowanych przerw technicznych [Shanmugasundaram, Sarojini 2018, s. 9-10]. | Zespoły deweloperskie i operacyjne powinny ściśle ze sobą '''współpracować'''. W przypadku problemów komunikacyjnych lub braku odpowiedniej synchronizacji praca nad wspólnymi zadaniami czy naprawianie błędów może odbywać się z dużymi opóźnieniami, co może spowodować straty w organizacji. '''Automatyzacja''' jest metodą, która pozwala na szybkie wprowadzanie zmian. Istotnym jest, aby [[organizacja]] zidentyfikowała te działania, które można zautomatyzować. W przypadku błędów, niektóre narzędzia związane z automatyzacją pozwalają na określenie awarii, powrotu do poprzedniego stanu pozbawionego danego błędu i sprawne wprowadzenie nowych zmian. [[Zmiana]] w dotychczasowym, nieusprawnionym procesie zarządzania wersjami może być trudnym przedsięwzięciem, zwłaszcza dla dużych organizacji wykorzystujących wiele różnych technologii i procesów. Aby usprawnić ten proces, organizacja powinna przyjąć '''bardziej zwinne podejście do zarządzania''' i, tym samym, wprowadzić [[dobre praktyki]] polegające na m.in. dostarczaniu najwyższej możliwej wartości biznesowej, eliminowaniu marnotrawstwa, ciągłym doskonaleniu się pracowników itd. Do '''analizy i lepszego zrozumienia procesu''' wydawania wersji pomocna jest metoda mapowania strumienia wartości. Pozwala ona lepiej zrozumieć [[dane]] działania realizowane wewnątrz procesu, ich konsekwencje w przyszłości oraz [[wartość]] dodaną dla organizacji i klienta. Ponadto dzięki niej możliwa jest ocena różnych etapów prac zespołu oraz zaplanowanie działań mających na celu ich zoptymalizowanie. Pomyślna realizacja procesu wydawania wersji jest uzależniona także od '''dobrze zorganizowanych środowisk testowych i preprodukcyjnych'''. W tych działaniach pomocny jest ustalony [[harmonogram]] pozwalający na sprawne zarządzanie testami poprzez m.in. wgląd w to, kto jest odpowiedzialny za jakie czynności i w jakim środowisku. Podgląd powinien zawierać również ustalone terminy wydań i planowanych przerw technicznych [Shanmugasundaram, Sarojini 2018, s. 9-10]. | ||
{{infobox5|list1={{i5link|a=[[Metodyka Ten Step]]}} — {{i5link|a=[[Scrumban]]}} — {{i5link|a=[[Six sigma]]}} — {{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Metody kontroli zasobów]]}} — {{i5link|a=[[Procesy planowania wg PMBOK]]}} — {{i5link|a=[[Szacowanie czasu trwania zadań]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[DMAIC]]}} }} | |||
==Bibliografia== | |||
<noautolinks> | |||
* Hoek A., Hall R., Heimbigner D., Wolf A. (1997), ''[https://www.ics.uci.edu/~andre/papers/C5.pdf?ref=driverlayer.com/web Software Release Management]'', Proceedings of the 6th European Software Engineering Conference | |||
* Howard D. (2012), ''IT Release Management: A Hands-on Guide'', CRC Press, Boca Raton FL | |||
* PMI (2021), ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management'' | |||
* Rasa G., Wahida Banu R. (2019), ''The Roles and Responsibilities of ITIL Release Management Process'', International Journal of Advance Research in Computer Science and Management Studies, vol. 7, nr 7 | |||
* Shanmugasundaram P., Sarojini B. (2018), ''[https://acadpubl.eu/jsi/2018-118-7-9/articles/9/2.pdf An Overview on Release and Deployment Management Strategy]'', International Journal of Pure and Applied Mathematics, vol. 118, nr 9 | |||
</noautolinks> | |||
[[Kategoria:Wariantowanie]] | |||
{{a|Maciej Szczuka}} | |||
{{#metamaster:description|Zarządzanie wersjami - planowanie i zarządzanie zmianami w produkcie lub usłudze, minimalizujące ryzyko dla biznesu. Powtarzalny proces, wydawanie wersji na czas i zgodność z wymaganiami.}} | |||
Aktualna wersja na dzień 19:24, 8 sty 2024
Zarządzanie wersjami - proces zawierający w sobie takie działania jak konsultowanie, planowanie oraz zarządzanie zmianami w danym produkcie lub usłudze. Zarządzanie wersjami charakteryzuje się koncentracją na wysokiej jakości rezultatów działań w ramach rozwijania usługi lub produktu od momentu inicjacji prac aż do publikacji [Howard 2012, s.1-2]. Celem tego podejścia jest przede wszystkim pewność, że poczynione w trakcie realizacji produktu zmiany zostały odpowiednio wdrożone w środowisku IT przy jednoczesnym minimalizowaniu ryzyka dla biznesowej strony przedsięwzięcia [Shanmugasundaram, Sarojini 2018, s. 5]. W ramach powtarzalnego i kontrolowanego procesu zarządzania wersjami, wersje oprogramowania powinny być wydawane na czas, przy zachowaniu najwyższej jakości i zgodności z wymaganiami [Howard 2012, s. 1-2].
W zakres zarządzania wersjami wchodzą takie działania jak [Shanmugasundaram, Sarojini 2018, s. 5]:
- szybka implementacja zmian w oprogramowaniu przy jednoczesnym optymalizowaniu kosztów i zmniejszaniu ryzyka,
- wydawanie wersji według ustalonego harmonogramu oraz według kryteriów gotowości danej wersji, wśród których wymienia się m.in. jakość danej wersji, plan wdrażania i wycofywania, a także plan zarządzania ryzykiem,
- prowadzenie szkoleń i dokumentacji związanych z zapewnieniem wsparcia technicznego dla użytkowników wprowadzanej usługi lub produktu, mających na celu ułatwienie korzystania.
Metody związane z zarządzaniem wersjami stosuje się w organizacjach, które mierzą się z następującymi czynnikami [PMI 2021]:
- złożona infrastruktura operacyjna,
- wiele zespołów pracujących równolegle,
- brak doświadczenia zespołów.
W przypadku złożonej infrastruktury operacyjnej istnieje wysokie ryzyko, że wdrożenie nowych funkcji do środowiska produkcyjnego uszkodzi oprogramowanie. Na tę złożoność wpływa m.in. stosowanie wielu różnych, mocno ze sobą powiązanych technologii. W organizacji, gdzie pracuje wiele zespołów deweloperskich przy współdzielonym środowisku rośnie prawdopodobieństwo kolidowania ze sobą zmian wprowadzanych przez te zespoły. Nowe zespoły często nie zdążyły nabrać jeszcze doświadczenia związanego z pracą w danym środowisku, tym samym będą potrzebowały pomocy przy wydawaniu wersji. Taka pomoc polegać może na wsparciu przy planowaniu, ustalaniu skutecznej strategii wydawania oraz koordynacji działań zespołu [PMI 2021].
TL;DR
Zarządzanie wersjami to proces konsultowania, planowania i zarządzania zmianami w produkcie lub usłudze. Celem jest zapewnienie wysokiej jakości rezultatów i minimalizowanie ryzyka. Proces obejmuje szybką implementację zmian, wydawanie wersji według harmonogramu, szkolenia i wsparcie techniczne. Wyróżnia się różne metody wydawania wersji, takie jak "big bang" czy podejście etapowe. Dobre praktyki to współpraca DevOps, automatyzacja, zrozumienie procesu wydawania wersji i zarządzanie środowiskiem testowym.
Proces zarządzania wersjami
Za proces zarządzania wersjami odpowiada menedżer wersji (ang. release manager). Osoba na tym stanowisku zajmuje się doprowadzeniem prac nad wersją aż do jej pełnej gotowości do publikacji. Ustala również cele poszczególnych etapów prac nad daną wersją [Shanmugasundaram, Sarojini 2018, s. 5]. Wyróżnia się również taką rolę jak menedżer projektu wersji (ang. release project manager), który wraz z menedżerem wersji i innymi kluczowymi interesariuszami może stanowić zespół planowania wersji (ang. release planning team) [Rasa, Wahida Banu 2019, s. 21].
Proces zarządzania wersjami składa się z następujących podprocesów [Rasa, Wahida Banu 2019, s. 21-24]:
- planowanie wersji,
- projektowanie, tworzenie oraz konfigurowanie wersji,
- akceptacja wersji,
- dystrybucja i instalacja wersji.
Podczas planowania wersji powinno się wziąć pod uwagę wszystkie jej aspekty. Menedżer odpowiedzialny za wydanie kompletuje zespół, wraz z którym definiuje podejście i zakres prac nad daną wersją. Te następnie dokumentuje się w planie wydania. Jeżeli plan zostanie zaakceptowany przez decyzyjne osoby w organizacji, zespół przystępuje do kolejnego etapu. Etap projektowania, tworzenia i konfiguracji wersji poddawany jest ciągłej weryfikacji przez menedżerów, którzy sprawdzają stan realizacji zadań danych zespołowi. Ustala się także plan testów. Po stworzeniu wersji dokonuje się przeglądu planu, a także naprawia błędy, które napotkano. Jeżeli wersja jest już w pełni sprawna, plan wersji zostaje przekazany menedżerowi wersji do ostatecznego zatwierdzenia. Następnie testuje się zaakceptowaną wersję i planuje działania związane z wdrożeniem wersji do użytkowników. Nim to jednak nastąpi, wersja musi się spotkać z akceptacją interesariuszy biznesowych oraz pracowników IT w ramach testów akceptacyjnych. Wyniki testów są dokumentowane oraz porównywane do wyników oczekiwanych. Jeżeli wyniki są satysfakcjonujące przystępuje się do wdrożenia wersji. Finalizuje się wówczas plan wydania, który zostaje jeszcze zweryfikowany przez menedżera wersji. Następnie rozpoczyna się etap instalacji i dystrybucji. Wdrożoną wersję wysyła się do kierownika projektu wydania, który weryfikuje zgodność wersji z założonymi kryteriami. Na tej podstawie określa się, czy cały proces zakończył się pomyślnie. W przeciwnym przypadku inicjuje się proces zarządzania zmianą [Rasa, Wahida Banu 2019, s. 21-24].
Metody wydawania wersji
Wyróżnia się kilka możliwości przeprowadzenia procesu tworzenia i wydawania wersji. Wybiera się ją w zależności od rozmiaru prac związanych z daną wersją, a także biorąc pod uwagę samą organizację [Shanmugasundaram, Sarojini 2018, s. 9].
Metody wydawania wersji prezentują się następująco [Shanmugasundaram, Sarojini 2018, s. 9]:
- "big bang",
- podejście etapowe,
- metoda "push",
- metoda "pull",
- metoda automatyzacji,
- wdrażanie ręczne.
Podejście "big bang" oznacza udostępnianie wersji wszystkim końcowym użytkownikom w tym samym czasie. W podejściu etapowym wersję udostępnia się wstępnie tylko jednej, określonej grupie użytkowników końcowych, a samo wydawanie odbywa się zgodnie z ustalonym wcześniej harmonogramem. Podejście "push" również zakłada wdrażanie wersji zgodnie z założonym harmonogramem. Jednak przy tej metodzie użytkownicy końcowi nie mogą sami wybrać momentu, kiedy skorzystają z wersji, gdyż ten jest odgórnie ustalony. Metoda "pull" oznacza udostępnianie wersji według ustalonego harmonogramu z tą różnicą do poprzedniego podejścia, że użytkownicy końcowi sami decydują, kiedy skorzystają z nowej wersji. Podejście automatyzacji zakłada wykorzystanie metod automatycznego wydawania wersji do użytkowników końcowych. Wdrażanie ręczne oznacza wykonywanie czynności związanych z wydawaniem wersji w sposób manualny. Oznacza to konieczność ciągłego monitorowania i pomiaru wpływu tych czynności na wydanie [Shanmugasundaram, Sarojini 2018, s. 9].
Dobre praktyki
Wyróżnia się kilka praktyk, które są pomocne przy realizacji procesu zarządzania wersjami. Są to m.in [Shanmugasundaram, Sarojini 2018, s. 9-10]:
- współpraca DevOps,
- automatyzacja,
- przyjęcie zwinnego podejścia do zarządzania,
- zrozumienie, analiza i ocena procesu wydawania wersji,
- zarządzanie preprodukcyjnym środowiskiem.
Zespoły deweloperskie i operacyjne powinny ściśle ze sobą współpracować. W przypadku problemów komunikacyjnych lub braku odpowiedniej synchronizacji praca nad wspólnymi zadaniami czy naprawianie błędów może odbywać się z dużymi opóźnieniami, co może spowodować straty w organizacji. Automatyzacja jest metodą, która pozwala na szybkie wprowadzanie zmian. Istotnym jest, aby organizacja zidentyfikowała te działania, które można zautomatyzować. W przypadku błędów, niektóre narzędzia związane z automatyzacją pozwalają na określenie awarii, powrotu do poprzedniego stanu pozbawionego danego błędu i sprawne wprowadzenie nowych zmian. Zmiana w dotychczasowym, nieusprawnionym procesie zarządzania wersjami może być trudnym przedsięwzięciem, zwłaszcza dla dużych organizacji wykorzystujących wiele różnych technologii i procesów. Aby usprawnić ten proces, organizacja powinna przyjąć bardziej zwinne podejście do zarządzania i, tym samym, wprowadzić dobre praktyki polegające na m.in. dostarczaniu najwyższej możliwej wartości biznesowej, eliminowaniu marnotrawstwa, ciągłym doskonaleniu się pracowników itd. Do analizy i lepszego zrozumienia procesu wydawania wersji pomocna jest metoda mapowania strumienia wartości. Pozwala ona lepiej zrozumieć dane działania realizowane wewnątrz procesu, ich konsekwencje w przyszłości oraz wartość dodaną dla organizacji i klienta. Ponadto dzięki niej możliwa jest ocena różnych etapów prac zespołu oraz zaplanowanie działań mających na celu ich zoptymalizowanie. Pomyślna realizacja procesu wydawania wersji jest uzależniona także od dobrze zorganizowanych środowisk testowych i preprodukcyjnych. W tych działaniach pomocny jest ustalony harmonogram pozwalający na sprawne zarządzanie testami poprzez m.in. wgląd w to, kto jest odpowiedzialny za jakie czynności i w jakim środowisku. Podgląd powinien zawierać również ustalone terminy wydań i planowanych przerw technicznych [Shanmugasundaram, Sarojini 2018, s. 9-10].
| Zarządzanie wersjami — artykuły polecane |
| Metodyka Ten Step — Scrumban — Six sigma — Inżynieria oprogramowania — Metody kontroli zasobów — Procesy planowania wg PMBOK — Szacowanie czasu trwania zadań — Feature-Driven Development — DMAIC |
Bibliografia
- Hoek A., Hall R., Heimbigner D., Wolf A. (1997), Software Release Management, Proceedings of the 6th European Software Engineering Conference
- Howard D. (2012), IT Release Management: A Hands-on Guide, CRC Press, Boca Raton FL
- PMI (2021), A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management
- Rasa G., Wahida Banu R. (2019), The Roles and Responsibilities of ITIL Release Management Process, International Journal of Advance Research in Computer Science and Management Studies, vol. 7, nr 7
- Shanmugasundaram P., Sarojini B. (2018), An Overview on Release and Deployment Management Strategy, International Journal of Pure and Applied Mathematics, vol. 118, nr 9
Autor: Maciej Szczuka
