Przystępując do realizacji automatyzacji procesu deploymentu aplikacji w firmie, warto się zastanowić nie tylko nad narzędziem, którego użyjemy, ale również nad sposobem bezproblemowego włączenia go w cały cykl release’u oprogramowania.

Na tym polu bardzo dobrze wypada narzędzie IBM UrbanCode Deploy (UCD), które daje szerokie możliwości integracji z innymi, wykorzystywanymi dotychczas w firmie systemami. Dzięki temu połączenie UCD np. z narzędziem do zarządzania zgłoszeniami, pozwala użytkownikom rozpocząć korzystanie z jego funkcjonalności niezwłocznie, bez konieczności nauki nowego interfejsu.

Użytkownicy UCD zauważą również, że cały proces deploymentu po zautomatyzowaniu staje się bardziej stabilny i mniej podatny na błędy ludzkie. Ponadto, problem niezaplanowanych wdrożeń zmian i ich wpływu na harmonogram pracy zespołu zostaje w znacznym stopniu zredukowany – zmiany te w dużej mierze obsługuje automat.

Zespół, odciążony nie tylko od zadań niezaplanowanych, ale również tych częstych, prostych i powtarzalnych – bo do takich w większości zaliczyć można zadania związane z aktualizacją aplikacji i wdrażaniem w nich wszelkich zmian –  może wreszcie w pełni wykorzystać swój potencjał. Specjaliści mogą zająć się rzeczywistymi problemami na środowiskach, wymagającymi doświadczenia i wiedzy eksperckiej. Dodatkowo, zespół zyskuje czas umożliwiający zaangażowanie się w nowe projekty, wymagające bardziej twórczej pracy.

Poniższy scenariusz opisuje przykładową sytuację wyjściową, od której rozpoczynamy integrację między tymi narzędziami

Po jednej stronie mamy narzędzie JIRA, w którym zgłoszenia deploymentu są rejestrowane i ręcznie aktualizowane przez użytkowników. Każde zgłoszenie dotyczące instalacji nowej wersji aplikacji zawiera w sobie niezbędne artefakty (w formie linku do repozytorium) oraz powiązanie z aplikacją, jej komponentami oraz środowiskiem. Zgłoszenia mają również swój cykl życia, który jest zdefiniowany w przepływie (tzw. workflow) w JIRA. Od momentu założenia, do zamknięcia zgłoszenia przechodzą one przez kolejne stany, które definiują jaki jest ich status. Dzięki temu w jednym miejscu jest dostępna historia każdego zgłoszenia, jego aktualny stan oraz wszystkie komentarze, które zostały dodane w międzyczasie przez osoby zajmujące się tym zgłoszeniem. Każdy stan jest przypisywany do innej grupy osób (np. deweloperzy, administratorzy, biznes itd.), które są odpowiedzialne za wykonanie odpowiednich czynności i przekazanie zgłoszenia dalej. W tym momencie JIRA jest jedynie standardowym narzędziem przechowującym określone informacje i komentarze użytkowników.

Z drugiej strony mamy narzędzie UCD, w którym są już przygotowane wszystkie procesy deploymentu dla aplikacji wykorzystywanych w firmie, ale są one uruchamiane ręcznie przez administratorów. Dodatkowo, przed uruchomieniem samego deploymentu,  pobierana jest paczka instalacyjna z linku podanego w zgłoszeniu oraz dodawana do repozytorium UCD za pomocą skryptu. Drugim krokiem jest uruchomienie deploymentu pobranej paczki w UCD. Administratorzy na podstawie przypisanego do nich zgłoszenia w JIRA wiedzą, dla której aplikacji należy wykonać deployment. Po wykonaniu tych zadań zgłoszenie w JIRA jest uzupełniane o odpowiedni komentarz informujący o wyniku pracy i zgłoszenie to jest przekazywane dalej. Taki tryb pracy wiąże się ze sporym nakładem czasu na samą obsługę formalną zgłoszenia. Jeżeli nie mamy standardów komentarzy, może się zdarzyć, że istotne informacje w zgłoszeniu nie zostaną odnotowane i osoba odpowiedzialna może nie wychwycić w odpowiednim czasie istotnych błędów czy pomyłek.

Poniższy diagram przedstawia sekwencję działań niezbędnych do zainstalowania nowej wersji aplikacji przed integracją narzędzi.

Co jest potrzebne po stronie Jira?

Przygotowanie integracji po stronie JIRA wiąże się przede wszystkim z napisaniem własnego pluginu oraz przygotowaniem odpowiedniego workflow dla zgłoszeń. Napisanie pluginu jest zadaniem typowo deweloperskim, którego przedstawienie nie jest celem tego artykułu. Ogólna zasada działania takiego pluginu polega na tym, że jest on wyzwalany w momencie przejścia zgłoszenia do odpowiedniego stanu, czyli uruchomienia tranzycji. Powoduje to wysłanie żądania do UCD za pomocą protokołu REST API. Żądanie jest przesyłane pod odpowiedni adres URL, dzięki czemu UCD jest w stanie uruchomić wewnętrznie odpowiedni proces.

Pełną listę parametrów niezbędnych do utworzenia zapytania http uruchamiającego deployment aplikacji możemy znaleźć w oficjalnej dokumentacji produktu (przykładowo dla wersji 6.2): LISTA PARAMETRÓW

Workflow zgłoszenia powinien uwzględniać wszystkie etapy instalacji paczki na środowisku wraz z możliwymi scenariuszami negatywnymi. Jego uproszczona wersja, uwzględniająca statusy i tranzycje wykorzystywane do deploymentu, może wyglądać jak na schemacie poniżej.

Taki workflow może być dedykowany tylko do obsługi zgłoszeń instalacji paczki, ale również może stanowić część już istniejącego workflow, w którym kontrolowany jest cały cykl życia zgłoszenia. Zmiany pomiędzy statusami są realizowane za pomocą odpowiednich tranzycji.

1. Tranzycje wyzwalane przez użytkownika:
   • Utwórz zgłoszenie
   • Utwórz wersję
   • Uruchom deployment

2. Tranzycje wyzwalane automatycznie przez proces w UCD:
   • Wersja dodana
   • Błąd dodawania wersji
   • Instalacja poprawna
   • Instalacja niepoprawna

Informacje niezbędne do wykonania zadań po stronie UCD są przechowywane w zdefiniowanych polach, tzn. custom field. Te informacje to przede wszystkim nazwa aplikacji, nazwa środowiska, lista komponentów i wersji do instalacji, nazwa procesu do uruchomienia po stronie UCD oraz dodatkowe parametry sterujące, przydatne w procesie.

W jaki sposób przygotować proces generyczny po stronie UCD?

Integrację po stronie UCD należy rozpocząć od skonfigurowania nowej aplikacji, która będzie odpowiedzialna za uruchamianie w sposób automatyczny odpowiednich podprocesów sterujących dodawaniem nowej wersji dla komponentów oraz deploymentem aplikacji

Kolejnym krokiem jest utworzenie procesów generycznych, uruchamianych przez nowo utworzoną aplikację w których zawarta będzie cała logika wykonywanych czynności. Te procesy to Set Version, czyli dodanie do repozytorium UCD wersji komponentów zawartych w paczce instalacyjnej, oraz Run Application, czyli uruchomienie docelowego deploymentu aplikacji.

Set Version

Proces generyczny dodający nowe wersje komponentów musi uwzględniać szereg założeń, tak, aby jego działanie było jak najlepiej udokumentowane w JIRA. Na wejściu takiego procesu otrzymujemy przede wszystkim adres URL do pliku z paczką zawierającą nowe wersje komponentów oraz dodatkowo informacj jakiej aplikacji dotyczy ta paczka. Efektem końcowym działania procesu są dodane nowe wersje komponentów w UCD oraz informacja zwrotna w JIRA o pozytywnym zakończeniu działania.

Poniższy workflow przedstawia proces generyczny wykorzystywany do automatycznego dodawania wersji ze zgłoszenia JIRA.

1. Pierwszy krok to wygenerowanie poświadczeń, które będą służyć do wysyłania odpowiedzi do zgłoszenia
2. W kolejny kroku dodawany jest komentarz do zgłoszenia w JIRA zawierający adres URL do aktualnie wykonywanego procesu. Komunikat HTTP POST wysyłany jest na adres: http://jira_base_url/rest/api/2/issue/jira_issue_id/comment . W treści tego komunikatu zostaje podany plik JSON z następującą zawartością:

3. Następnie wykonywany jest test wszystkich parametrów aplikacji, której dotyczy zgłoszenie. Jest to wstępna weryfikacja, która ma na celu odrzucenie zgłoszeń, które są źle wypełnione. Weryfikowana jest nazwa aplikacji, nazwa procesu, nazwa środowiska. Jeżeli którykolwiek z tych parametrów nie istnieje w UCD, proces przechodzi do ścieżki negatywnej.
4. Kolejny krok to uruchomienie skryptu setVersion, którego zadaniem jest pobranie paczki instalacyjnej, rozpakowanie jej oraz dodanie nowych wersji do komponentów w UCD. Skrypt ten również posiada obsługę błędów i w przypadku wystąpienia takiego błędu, proces przechodzi do ścieżki negatywnej.
5. Ostatnie 3 kroki to aktualizacja zgłoszenia JIRA o kolejne elementy:
   • publikacja wszystkich wersji komponentów, które zostały dodane w poprzednim kroku – lista ta jest przechowywana w dedykowanym polu typu customfield,
   • zmiana tranzycji na pozytywną – “Wersja dodana” (patrz rys. 1),
   • dodanie w zgłoszeniu komentarza informującego o pozytywnym wykonaniu procesu dodawania nowych wersji komponentów.
6. Scenariusz negatywny wygląda następująco:
   • ustawienie negatywnego statusu wywołania procesu w UCD,
   • zmiana tranzycji zgłoszenia na negatywną – “Błąd dodawania wersji” (patrz rys. 1),
   • dodanie komentarza w zgłoszeniu JIRA o negatywnym zakończeniu działania.

Run Application

Ten proces generyczny jest bezpośrednio odpowiedzialny za uruchomienie deploymentu konkretnych wersji aplikacji. W tym procesie na wejściu otrzymujemy listę komponentów i wersji do deploymentu, którą otrzymaliśmy w poprzednim kroku, nazwę aplikacji, środowiska i procesu. Efektem końcowym jest zainstalowana nowa wersja aplikacji oraz informacja zwrotna w JIRA o sukcesie deploymentu.

Workflow realizujący deployment wygląda następująco:

1. Pierwszy krok to, identycznie jak w procesie Set Version, wygenerowanie poświadczeń, które będą służyć do wysyłania odpowiedzi do zgłoszenia.
2. W kolejnym kroku zostaje dodany URL aktualnie wykonywanego procesu jako komentarz w JIRA
3. Trzeci krok do uruchomienie deploymentu aplikacji za pomocą wbudowanego w narzędzie pluginu. Wykorzystując ten plugin jesteśmy w stanie uruchomić proces deploymentu dokładnie z takimi samymi parametrami, jak byśmy to robili za pomocą interfejsu graficznego. Szczegółowy opis tego kroku opisany jest poniżej.
4. Na koniec aktualizujemy nasze zgłoszenie w JIRA o następujące elementy:
   • zmiana tranzycji zgłoszenia na pozytywną,
   • dodanie komentarza o pozytywnym zakończeniu działania.
5. Scenariusz negatywny polega, tak jak w poprzednim procesie, na zmianie tranzycji zgłoszenia na negatywną, oraz dodaniu komentarza o negatywnym zakończeniu procesu, wraz z informacją, dlaczego proces nie zakończył się poprawnie.

Krok nr 3 został przeniesiony do osobnego procesu generycznego, po to, żeby nie zaciemniać czytelności głównego procesu. Poniższy workflow pokazuje sposób działania tego procesu:

Przed wywołaniem deploymentu należy upewnić się, że wszystkie przekazane parametry są poprawne. Jeżeli któryś z parametrów był niepoprawny, dodajemy odpowiedni komentarz, który identyfikuje nam jednoznacznie błąd. Taki komentarz pojawi się później w zgłoszeniu JIRA. Dzięki temu dosyć szybko jesteśmy w stanie dowiedzieć się w czym tkwił błąd.

Ostatecznie nasz diagram sekwencji dla scenariusza pozytywnego przyjmuje następującą postać:

Jakie korzyści może przynieść sterowanie procesem deploymentu z poziomu zewnętrznego systemu?

Korzyści wynikających z przekazania sterowania procesem deploymentu do zewnętrznego systemu jest kilka.

Po pierwsze korzystamy z wdrożonego systemu, który jest znany wszystkim pracownikom w organizacji i pozbywamy się konieczności obsługi nowego narzędzia z poziomu interfejsu graficznego. Redukuje to czas konieczny na obsługę tego interfejsu. Zapytania wysyłane bezpośrednio z JIRY za pomocą REST API realizują zadania w UCD zdecydowanie szybciej. Użytkownik wykonujący operację deploymentu nie musi wiedzieć w jaki sposób proces w UCD został wywołany. Z jego punktu widzenia istotne są komunikaty przekazywane zwrotnie do zgłoszenia, na podstawie których może analizować na bieżąco status.

Po drugie posiadamy dokładną oraz ustandaryzowaną historię każdego zgłoszenia. Od momentu założenia do momentu gdy nowa paczka została zainstalowana na środowisku, widzimy wszystkie etapy przez które przechodziło zgłoszenie, widzimy w jaki sposób było uzupełniane o komentarze z UCD oraz inne przydatne informacje.

Po trzecie zmniejszamy liczbę pomyłek, które mogłyby wynikać z niedokładnej analizy wykonanej operacji. Automatyzując proces uruchamiania deploymentu, mamy pewność, że każdorazowo zostaną wykonane konkretne czynności, które w odpowiedni sposób zweryfikują nasze zgłoszenie oraz wykonywane operacje.

Jeśli interesuje Cię więcej informacji, skontaktuj się z nami!

Błąd: Brak formularza kontaktowego.