Dlaczego skrypty Groovy nie zadziałają w Jira Cloud?
Powód jest architektoniczny, nie licencyjny. Na Data Center ScriptRunner wykonuje skrypty w tym samym procesie co Jira, w tej samej maszynie wirtualnej Javy. Skrypt ma bezpośredni dostęp do wewnętrznego Java API: czyta obiekty zgłoszeń z pamięci, woła serwisy Jiry, reaguje na zdarzenia synchronicznie, zanim użytkownik zobaczy wynik operacji. Jira Cloud nie pozwala uruchamiać obcego kodu w procesie aplikacji. Skrypt z Data Center nie ma żadnego trybu zgodności, w którym mógłby się wykonać.
To nie znaczy, że logika przepada. Znaczy, że trzeba ją odtworzyć świadomie, a do tego najpierw wiedzieć, co dokładnie robi.
Co dokładnie się zmienia?
Zmieniają się trzy rzeczy: model wykonania, API i język.
Model wykonania. Cała logika rozszerzeń działa poza Jirą i komunikuje się z nią przez sieć. W konsekwencji część operacji przestaje być synchroniczna. Listener na Data Center mógł zmodyfikować zgłoszenie w trakcie zapisu, zaś w Cloud reakcja przychodzi po zdarzeniu, z opóźnieniem. Dla większości automatyzacji to bez znaczenia, a pozostałe, jak na przykład walidacje w locie czy wyliczenia widoczne natychmiast, wymuszają zmianę podejścia.
API. Java API dawało dostęp do wszystkiego, co Jira ma w środku, łącznie z rzeczami, których Atlassian nigdy nie planował wystawiać. REST API udostępnia to, co zostało zaprojektowane jako publiczny interfejs. Większość typowych operacji jest osiągalna, ale nie wszystkie – pojedyncze elementy trzeba obejść inaczej albo z nich zrezygnować. Do tego należy pamiętać o limitach liczby zapytań, szczególnie istotnych przy skryptach masowo przetwarzających zgłoszenia. Dla jobów przechodzących nocą przez tysiące zgłoszeń to realna zmiana: to, co na Data Center było jedną pętlą po bazie, w Cloud staje się serią wywołań.
Język. Groovy zastępuje TypeScript lub JavaScript, a warunki i proste wyrażenia Jira expressions: ograniczony język wyliczany po stronie Jiry, bez dostępu do REST. W tym przypadku nie istnieje tłumaczenie linijka po linijce – przekłada się intencję skryptu, nie jego tekst. Właśnie dlatego pierwszym krokiem jest zrozumienie, po co skrypt powstał.
Jak zinwentaryzować skrypty przed migracją?
Policzyć każdy skrypt na instancji, opisać, co robi, i sprawdzić, czy działa. Inwentaryzacja to najtańszy etap całego projektu i jednocześnie ten, który najmocniej wpływa na przewidywalność jego planu i kosztu. Warto podejść do przeglądu trzywymiarowo:
- Typy – ScriptRunner na Data Center to nie jeden mechanizm, tylko rodzina: behaviours, scripted fields, listenery, joby, walidatory, warunki i post-funkcje w przepływach pracy, własne endpointy REST, fragmenty interfejsu. Każdy typ ma inną drogę odtworzenia w Cloud, więc sam podział listy według typów już porządkuje rozmowę o pracochłonności.
- Miejsce przechowywania – skrypty z repozytorium widać od razu, da się je przejrzeć i policzyć. Zdradliwe mogą być jednak skrypty inline, wklejone bezpośrednio w konfigurację: w polu walidatora, w definicji pola, w konsoli. Nie ma ich w żadnym repozytorium, często nie ma ich w żadnej dokumentacji, a bywa, że napisała je osoba, która od dawna nie pracuje w firmie. Rzetelna inwentaryzacja wymaga przejścia konfiguracji całej instancji, a nie samego przeglądu repozytorium.
- Realne użycie – Kiedy skrypt ostatnio się wykonał? Czy ktokolwiek patrzy na pole, które wylicza? Czy walidacja nadal odpowiada procesowi, czy pilnuje reguły sprzed czterech lat? To pytania do logów i do ludzi, nie warto w tym miejscu zgadywać odpowiedzi.
Adaptavist, producent ScriptRunnera, udostępnia narzędzia wspierające ten etap, w tym zestaw do analizy skryptów pod kątem gotowości chmurowej (ScriptRunner Migration Suite). Przyspieszają przegląd i wskazują ryzyka, więc opłaca się ich użyć. Decyzji, co z każdym skryptem zrobić, z nikogo jednak nie zdejmą: to praca analityczna, nie automat.
Czym odtwarzać logikę: Automation, ScriptRunner for Cloud czy Forge?
Trzy drogi, żadna nie jest uniwersalna.
Jira Automation to natywny mechanizm reguł: wyzwalacz, warunki, akcje – wszystko wyklikiwalne. Jest to najlepsze rozwiązanie dla prostych i średnich automatyzacji np. przypisz zgłoszenie, ustaw pole, powiadom zespół, przenieś status. Ogromną zaletą jest możliwość utrzymania reguły przez administratora – bez programisty. Granica opłacalności przebiega tam, gdzie logika robi się rozgałęziona, dotyka danych poza Jirą albo operuje masowo.
ScriptRunner for Cloud ma odpowiedniki części funkcji znanych z Data Center. Model jest jednak inny: skrypty w TypeScript lub JavaScript wykonywane są poza Jirą, przez REST, a część mechanizmów oparta jest na Jira expressions. Zakres funkcji tego narzędzia nie pokrywa się jeden do jednego z wersją DC, więc przed decyzją trzeba sprawdzić w dokumentacji odpowiedniki konkretnych opcji, których używacie. Dla zespołów, które znają ScriptRunnera i mają logikę ze środkowej półki złożoności, to często najkrótsza droga.
Forge to platforma Atlassiana do budowy własnych aplikacji, działających w infrastrukturze Atlassiana. Daje pełną kontrolę i pokrywa przypadki bez gotowego odpowiednika: nietypowe integracje, złożone wyliczenia, własne widoki. Ceną tego rozwiązania jest jednak potrzeba współpracy z zespołem deweloperskim, który taką aplikację zbuduje i utrzyma.
Wyboru odpowiedniej ściezki dokonuje się per skrypt, nie per instancja. Typowy wynik dla dojrzałego środowiska jest zróżnicowany: większość przypadków ląduje w Automation, kilkanaście w ScriptRunner for Cloud albo podobnym narzędziu, a jedna czy dwie funkcje, dla których nie ma gotowego mechanizmu, powstają jako aplikacja Forge. Kryteria jakie należy wziąć pod uwagę to złożoność logiki, kto będzie utrzymywał dany mechanizm, jak często się zmienia i czy sięga poza Jirę. Jest jeszcze jeden szczegół, o którym łatwo zapomnieć przy wycenie: koszt utrzymania po migracji. Regułę Automation administrator zmieni w kwadrans, jednak aplikacja Forge potrzebuje dewelopera przy każdej zmianie procesu.
Na co patrzeć, gdy dostawca szacuje przepisanie?
Liczba skryptów mówi o budżecie niewiele: sto prostych walidatorów to mniej pracy niż pięć scripted fields z logiką wielosystemową. Wycena, która się broni, dzieli skrypty wg złożoności i każdej kategorii przypisuje drogę odtworzenia. Testy również powinny być w wycenie od początku: w praktyce potrafią kosztować tyle, co samo przepisanie, i pominięcie ich to najczęstsze źródło przekroczeń.
Jeśli słyszycie, że „skrypty przeniosą się narzędziem migracyjnym”, dopytajcie, co dokładnie zostanie przeniesione. Narzędzia przenoszą definicje i konfigurację, ale nie działania logiki.
Które skrypty warto porzucić zamiast przepisywać?
Zwykle jest ich zaskakująco wiele. Po latach na Data Center lista skryptów odzwierciedla historię firmy, nie jej obecne potrzeby. Trzy grupy do odstrzału:
Niewykorzystywane. Skrypty, które nie wykonały się od miesięcy, pola, na które nikt nie patrzy, walidacje procesów, które już nie istnieją. Wychodzą one przy pomiarze realnego użycia i znikają z backlogu bez żalu. Dobrym filtrem jest pytanie do właściciela procesu, nie do administratora: administrator wie, że skrypt się wykonuje, właściciel wie, czy jego wynik komukolwiek służy.
Zastąpione przez funkcje natywne. Cloud rozwinął się od czasu, gdy wiele skryptów powstało. Część rzeczy, które kiedyś wymagały Groovy, dziś robi Jira Automation albo funkcja wbudowana w produkt. Przed przepisaniem czegokolwiek sprawdźcie, czy problem nadal wymaga kodu.
Do uproszczenia. Skrypt obsługiwał proces, który przy okazji migracji i tak się zmienia. Zamiast wiernie odtwarzać starą logikę, prościej przeprojektować regułę pod nowy proces.
Efektem dobrze przeprowadzonej inwentaryzacji jest backlog przepisania wyraźnie krótszy niż lista skryptów. To ta różnica sprawia, że migracja skryptów, na papierze najczęściej niedoszacowana część projektu, w praktyce daje się domknąć w przewidywalnym budżecie.
Skala skryptów to jeden z sygnałów decydujących o tym, czy migracja będzie prosta, czy złożona. Szersze spojrzenie na elementy, które zaskakują przy migracji, i podpowiedzi, jak zweryfikować je u siebie, znajdziecie w artykule o czterech pułapkach.
Na bezpłatnej konsultacji patrzymy między innymi na skrypty w Waszej instancji: ile ich jest, jakiego typu i co z tego wynika dla projektu. Godzina rozmowy i wiecie, na czym stoicie.
