Zarządzanie wersjami: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
Linia 62: | Linia 62: | ||
== Bibliografia == | == Bibliografia == | ||
* Howard D. | * Howard D. (2012). ''[https://books.google.pl/books?id=Nl7NBQAAQBAJ&dq=IT+Release+Management:+A+Hands-on+Guide&hl=pl&source=gbs_navlinks_s IT Release Management: A Hands-on Guide]'', CRC Press, Boca Raton FL | ||
* PMI | * PMI (2021). [https://www.pmi.org/disciplined-agile/process/release-management ''Release Management''] (dostęp on-line: 22.04.21 r.) | ||
* Rasa G., Wahida Banu R.S.D. | * Rasa G., Wahida Banu R.S.D. (2019). [https://www.academia.edu/44232309/The_Roles_and_Responsibilities_of_ITIL_Release_Management_Process ''The Roles and Responsibilities of ITIL Release Management Process''], "International Journal of Advance Research in Computer Science and Management Studies", wol. 7, nr 7 | ||
* Shanmugasundaram P., Sarojini B. | * 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", wol. 118, nr 9, s. 5-12 |
Wersja z 21:00, 22 kwi 2021
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]:
- 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.
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ą.
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.
Bibliografia
- Howard D. (2012). IT Release Management: A Hands-on Guide, CRC Press, Boca Raton FL
- PMI (2021). Release Management (dostęp on-line: 22.04.21 r.)
- Rasa G., Wahida Banu R.S.D. (2019). The Roles and Responsibilities of ITIL Release Management Process, "International Journal of Advance Research in Computer Science and Management Studies", wol. 7, nr 7
- Shanmugasundaram P., Sarojini B. (2018). An Overview on Release and Deployment Management Strategy, "International Journal of Pure and Applied Mathematics", wol. 118, nr 9, s. 5-12