Dostałem dzisiaj kolejne, ciekawe zadanie. Issue w statusie ZAWIESZONY ma automatycznie zmienić status na „W TOKU” po upływie określonego czasu tak, żeby agenci Service Desk mogli się nim w porę zająć.
Po co?
Cel ćwiczenia jest następujący:
- Agent Service Desk:
- zakłada issue „Zadanie”
- ustawia w polu Due Date termin wykonania zadania na datę w przyszłości
- zmienia status Zadania z „W TOKU” na „ZAWIESZONY”, dzięki temu issue znika z dashboardu, który codziennie obserwują Agenci i nie zaśmieca im widoku
- Na dobę przed terminem wykonania zadania automat zmienia status na „W TOKU” tak, żeby issue na nowo pojawiło się w dashboardzie i Agenci wiedzieli, że mają się nim zająć.
Mechanizm taki może znaleźć zastosowanie w przypadku takich zgłoszeń jak: prace planowe własne, prace planowe dostawców, konieczność cyklicznego wykonywania jakichś działań czy zwykłe przypomnienie.
Wyobrażam sobie sytuację, w której dostajemy od naszego dostawcy powiadomienie o tym, że za 2 tygodnie będzie przeprowadzał prace planowe w swojej infrastrukturze mające wpływ na nasze systemy. Zakładamy wtedy zgłoszenie w Jira, żeby temat nie umknął. Dedykowana osoba lub osoby sprawdzają jak nadchodzące prace wpłyną na nas i ewentualnie przygotowują się na nie. W chwili, kiedy wszystko jest gotowe, zgłoszenie jest traktowane w sposób opisany wyżej. Na ustalony czas przed pracami „odwiesza” się tak, żeby wszyscy pamiętali o nadchodzącym wydarzeniu.
Co?
Na potrzeby konfiguracji przyjmijmy następujące założenia i elementy konfiguracji:
| Issue Type | Prace planowe (Planned works) |
| Label | prace-planowe-obce |
| Statusy | 1. W TOKU (in progress) 2. ZAWIESZONY (suspended) |
| Due Date | 15/Dec/19 |
| Akcje do podjęcia przez automat | 1. Wykonanie issue transition ze statusu ZAWIESZONY do W TOKU o godzinie 9:00 rano dnia poprzedzającego Due Date. 2. Dodanie do zgłoszenia komentarza: „Automatyczne przypomnienie o zbliżającym się terminie wykonania”. 3. Wysłanie maila z powiadomieniem o zmianie. |
| User | robbo.robot |
Parę słów wyjaśnienia do powyższej tabeli:
Issue Type: to typ zgłoszenia, na którym będzie wykonane automatyczne działanie. To tylko przykład. Działanie to można podjąć na dowolnym rodzaju zgłoszenia jaki mam skonfigurowany w swojej instancji.
Label: labelka będzie dodatkowym elementem identyfikującym moje zgłoszenie. Mogę chcieć inaczej traktować prace planowe wewnętrzne a inaczej zewnętrzne. Sposobów na rozróżnienie jest wiele. Mogę pod to stworzyć osobne issue type. Albo skorzystać z łatwiejszego rozwiązania – labelki.
Statusy: każde issue ma jakiś swój workflow. W tym przypadku „W TOKU” oraz „ZAWIESZONY” są dwoma statusami z workflow dla issue type Prace planowe. Muszę jednak pamiętać, że pomiędzy tymi statusami musi istnieć bezpośrednie połączenie (transition). Więcej o tym poniżej w szczegółach konfiguracji.
Due Date: to pole, w którym Jira umożliwia wpisanie daty określającej na kiedy trzeba wykonać dany temat. Pole to nie zawsze jest widoczne. Jeśli nie jest muszę je włączyć w Field Configurations.
Akcja do podjęcia przez automat: na etapie planowania czy rozmów z osobą, która zleca mi jakieś zadanie lubię mieć jasno określone jaki efekt trzeba osiągnąć. W tym przypadku są to trzy punkty. Po pierwsze, automat ma sprawdzać codziennie rano o godzinie 9:00 czy są jakieś issue, które należy zmienić i jeśli tak to ma przeprowadzić zmianę. Po drugie, dla issue dla, których jest przeprowadzona zmiana ma zostać dodany odpowiedni komentarz. Po trzecie, na koniec ma zostać wysłany mail o przeprowadzonym działaniu.
User: zmiany w Jira, także te przeprowadzane przez automaty, nie mogą być przeprowadzane anonimowo. Musi pozostać ślad po tym kto dokonał zmiany. Dlatego potrzebuję mieć usera, który będzie takie zmiany przeprowadzał. Mogę do tego celu wskazać istniejącego człowieka jednak uważam, że lepszym rozwiązaniem jest stworzenie dedykowanego usera dla automatycznych zmian. Wystarczy wtedy spojrzeć na to kto dokonał zmiany i wiadomo od razu czy to człowiek czy automat. Minusem tego rozwiązania jest to, że user taki „zżera” nam licencje Jira.
Ja swojego nazwałem Robbo, od imienia robota-bohatera prehistorycznej polskiej gry na Atari 🙂
Czym?
Jira sama w sobie nie ma wbudowanych mechanizmów, które umożliwiłyby mi dostarczenie rozwiązania. Jak to często bywa w takich sytuacjach trzeba skorzystać z zewnętrznej apki. Ja wybrałem do tego celu ScriptRunner a dokładniej funkcję Jobs – Escalation Service. Przyznaję, że podchodziłem do ScriptRunnera trochę jak pies do jeża, trochę bojąc się jego skomplikowania, ale teraz nie wyobrażam sobie życia administratora Jira bez tego pluginu. A jestem dopiero na samym początku jego poznawania.
Jak?
Akcja 1: Wykonanie issue transition ze statusu Zawieszony do W TOKU o godzinie 9:00 rano dnia poprzedzającego Due Date
Zakładam, że macie już zainstalowanego ScriptRunnera.
Krok 1:
W menu Administracja wybieram opcję Manage apps:
Następnie z menu po prawej stronie w sekcji Scriptrunner wybieram Jobs (UWAGA: w starszych wersjach Script Runnera ta pozycja zamiast Jobs nazywała się Escalation Services):
Krok 2:
Jako, że wcześniej nie konfigurowałem żadnego joba to w menu mam pustą listę. Jeśli wcześniej coś bym konfigurował to miałbym w tym widoku listę utworzonych elementów. Wrócimy do niej później. Na razie klikam niebieski przycisk Create Job (UWAGA: w starszych wersjach Script Runnera przycisk ten nazywał się Create Escalation Service)
Krok 3:
W kolejnym widoku klikam raz jeszcze Escalation service (ramkę)
Krok 4:
Zaczynam właściwą konfigurację.
Note (w starszych wersjach Description): tutaj podaję nazwę mojego escalation service. Może być dowolna. Ja przyjąłem zasadę, że elementy konfiguracji opisuję po angielsku więc nazwałem ją: „Auto transition issue from „ZAWIESZONY” to „W TOKU” based on Due Date”.
User: w tym miejscu podaję w imieniu którego usera chcę żeby automat dokonywał zmian. Pamiętajcie, że user taki musi mieć wszystkie niezbędne dostępy oraz uprawnienia do działań jakie chcemy automatycznie wykonać. Ja tak napisałem wyżej stworzyłem dedykowanego usera pod tego typu zmiany. Nazwałem go Robbo.
Interval/CRON Expression: teraz czas na skonfigurowanie tego, jak często mój automat ma zadziałać. Do tego celu wykorzystywany jest cron. Dla niewiedzących, czymże jest ów cron? Cytując Wikipedię:
„cron jest opartym na czasie programem do harmonogramowania zadań w systemach operacyjnych z rodziny Unixa. Może zostać wykorzystany do uruchamiania zadań (programów, komend, skryptów) o określonych godzinach, datach albo regularnie zgodnie z określonym interwałem.”
Ci z Was, którzy potrafią się posługiwać cronem napiszą sobie wyrażenie samemu a Ci, którzy go nie znają mogą się nauczyć 😉 Albo posłużyć generatorem takim jak np ten: https://www.freeformatter.com/cron-expression-generator-quartz.html
Co jest bardzo ważne i o czym trzeba pamiętać? W dokumentacji ScriptRunnera znalazłem informację, że jeśli skonfiguruję częstotliwość jako interwał, to przy starcie Jira (np. restart) zadania takie zostaną wywołane. Aby tego uniknąć zamiast interwału muszę podać konkretny czas. Ja w przykładzie skonfigurowałem wywołanie codziennie na godzinę 9:00 poczynając od pierwszego dnia każdego miesiąca czyli 0 00 9 1/1 * ? *
JQL Query: tutaj wskazuję jakich issues dotyczyć będą wykonywane przez automat działania. Z tabelki z założeniami umieszczonej na początku tego wpisu wiem, że interesują mnie prace planowe (w konfiguracji używam angielskiego nazewnictwa, więc tutaj będą to Planned works) o statusie ZAWIESZONY (suspended) i labelką prace-planowe-obce (labelki mam po polsku) oraz terminem wykonania na jeden dzień przed uruchomieniem automatu, czyli due date mniejsza bądź równa jeden dzień. W efekcie otrzymuję następujące zapytanie JQL:
issuetype="Planned Works" AND labels = prace-planowe-obce AND status = Suspended AND duedate <= 1d
Action: dochodzę w końcu do tego jaką akcję ma podjąć mój automat. Przypominam, że mi zależy na tym, żeby w określonej skonfigurowanej w poprzednich krokach sytuacji issue o typie Planned Works zmieniło swój status z „ZAWIESZONY” na „W TOKU”.
Przejścia pomiędzy statusami są określane jako transition, które z kolei są elementami workflow.
Logiczne zatem, że żeby odszukać właściwe transition muszę najpierw określić jakim workflow posługuje się zgłoszenie Planned Works.
Poniżej interesujący mnie fragment tego workflow:
Transition, o którym mowa jest reprezentowane przez strzałki pomiędzy statusami W TOKU oraz ZAWIESZONY. Gwoli ścisłości – to są dwie strzałki nałożone na siebie. Transition w Jira jest zawsze w jedną stronę. Jeśli chcę skonfigurować możliwość przechodzenia pomiędzy statusami „w te i we wte” muszę je skonfigurować najpierw „w te” a potem „we wte” 😉 Strzałki mogę umieszczać osobno, ale ja zdecydowałem się nakładać je jedna na drugą, żeby zaoszczędzić miejsce.
Przejście ze statusu W TOKU do ZAWIESZONY nazwane „Zawieś” jest realizowane ręcznie przez Agenta Service Desk. Automat, który konfiguruję ma dokonać przejścia w drugą stronę, czyli nazwanego „Wznów pracę”.
OK, wracam zatem do Script Runnera. Klikam listę i rozwija mi się baaardzo długa lista do wyboru. Zawiera ona wszystkie transition dostępne w mojej instancji Jira:
Przewijam w dół i widzę, że jest wiele pozycji o nazwie W TOKU. Którą mam wybrać? Odpowiedź stanowią numerki w nawiasach, które są unikalnymi ID dla danego transition. Jak zatem określić jakie ID ma interesujące mnie transition? Z pomocą przychodzi widok text dla mojego workflow. Poniżej wyjaśniam o co chodzi.
Workflow możemy konfigurować na dwa sposoby. W trybie diagramu, który w mojej opinii jest łatwiejszym sposobem, gdzie za pomocą interfejsu graficznego wyklikujemy interesujące nas statusy, a następnie łączmy je strzałkami.
Drugim sposobem jest tryb text. Przyznam się szczerze, że od samego początku omijam go szerokim łukiem i zastanawiałem się zawsze po co on istnieje. Cóż. Znalazłem pierwsze jego zastosowanie.
Przechodzę zatem ponownie do interesującego mnie workflow, ale przełączam się z trybu Diagram na Text, gdzie w kolumnach dostaję następujące informacje: Step Name (id), Linked Status, interesujące mnie Transitions (id) oraz Actions:
W kolumnie Linked Status szukam statusu ZAWIESZONY. Obok w kolumnie Transitions (id) widzę jakie transitions wychodzą z tego statusu. W moim przypadku jest tylko jeden – Wznów pracę. Obok w nawiasie jest jego ID 61. Bingo. To jest informacja, której potrzebuję.
Wracam zatem do Script Runnera i rozwijanej listy Action, gdzie odnajduję transition Wznów pracę (61):
Tym samym pierwsza akcja z tabeli wymagań „Wykonanie issue transition ze statusu ZAWIESZONY do W TOKU o godzinie 9:00 rano dnia poprzedzającego Due Date.” zrobiona. Czas na kolejne.
Akcja 2: Dodanie do zgłoszenia komentarza: „Automatyczne przypomnienie o zbliżającym się terminie wykonania”
To jest stosunkowo łatwe. Wystarczy, że dodam do mojego Escalation Service jedną linijkę skryptu.
Na samym dole konfiguracji Escalation Service mam pole Additional issue actions, gdzie za pomocą wbudowanego w Script Runnera edytora kodu mogę dopisać za pomocą Groovy co jeszcze ma zostać wykonane:
W edytorze wystarczy, że wpiszę jedną linijkę:
issueInputParameters.setComment("Automatyczne przypomnienie o zbliżającym się terminie wykonania")
Oczywiście tekst jaki chcesz, żeby został wpisany możesz dowolnie zmienić. Ja wybrałem taki jak widać. Komentarz ten zostanie wpisany w imieniu usera Robbo, o którym była mowa wyżej.
Kolejna akcja z tabeli zrobiona. Czas na trzecią, ostatnią.
Akcja 3: Wysłanie maila z powiadomieniem o zmianie
To już też mam zrobione… Dostałem to w bonusie do punktu drugiego. Dodanie komentarza do zgłoszenia powoduje automatyczne wysłanie maila z powiadomieniem o zmianie. Nie jest ważne czy zmiany dokonuje człowiek czy automat 🙂 Oczywiście mail zostanie wysłany jeśli spełnione są dwa warunki: Twoja instancja Jira ma skonfigurowane wysyłanie maili oraz Notification Scheme dla eventu Issue Commented dla projektu, w którym będzie działał nasz automat jest aktywne.
Pozostaje kliknąć na dole przycisk Add i moje Escalation Service gotowe.
Kontrola działania Escalation Service
Kiedy mam już skonfigurowane Escalation Service po kliknięciu w menu Jobs widzę ten element skonfigurowany na liście.
Mogę zobaczyć kiedy nastąpi kolejne uruchomienie joba a także jaki był jego dotychczasowy przebieg – czy wystąpiły błędy, jaki był czas wykonania oraz zajęcie CPU. Poniżej wynik działania mojej konfiguracji po kilkunastu dniach:
I to wszystko 🙂
