Jirowa ściana płaczu, czyli wyznania adminów

By in
Jirowa ściana płaczu, czyli wyznania adminów

Każdy z nas, administratorów, popełnił kiedyś błąd, którego wstydzi się do dziś. Powód? Brak doświadczenia, niedopatrzenie czy heroiczna próba zaspokojenia wymagań klienta. Udało mi się zebrać wypowiedzi kilku odważnych adminów, którzy zdecydowali się podzielić swoimi wyznaniami. Sprawdźcie, co się wydarzyło i jak można było tego uniknąć.

Pomyłki są potrzebne, dzięki nim się uczymy (oby!). Poniżej znajdziecie zatem kilka dobrych materiałów do nauki 😉

Klient chciał widzieć, jaki jest progres poszczególnych tasków w procentach. Powstał zatem workflow „In progress 5%”, „In progress 10%”, „In progress 15%”…. i tak do 100%.

No tak… jeśli mamy do dyspozycji jedynie status In Progress, czasem ciężko stwierdzić w jakim ten progress jest stanie. Bardziej korzystną alternatywą dla dodania masy nowych statusów (!) jest dodanie jednego pola, na przykład select list i odpowiednich wartości do wyboru. Ale jeśli konfiguracja projektu zostaje doprowadzona do takiego miejsca, to należy się raczej zastanowić nad zmianą jego założeń, niż brnąć w ślepą uliczkę.

No ja na przykład jak uczyłem się pisać pluginy to zrobiłem sobie jakieś okienko z przyciskiem o id takim samym jak się okazało „Create” przy tworzeniu zadań. Chciałem sobie zablokować JavaScriptem swój przycisk a okazało się, że w całej organizacji nikt nie mógł stworzyć zadania bo przycisk Create był nieaktywny :D.

Pierwsza sprawa – testowanie na produkcji. To by się nie wydarzyło, gdyby w użyciu była instancja testowa. Niezależnie od tego jaki ID ma przycisk Create (a jest to create-issue-submit), żeby uniknąć powtórzeń warto dodawać unikalny prefiks, np. custom_, dostaniemy wtedy custom_create-issue-submit.

Nasze środowisko testowe jest słabsze, niż produkcja. Testowaliśmy kiedyś nową wersję pluginu i okazało się, że potrzebny jest restart Jiry. No to puszczam i ze zdziwieniem patrzę, jak szybko się wyłącza. Nawet mówię do kolegi, który obserwuje wszystko przez Teams: – Patrz, jak ładnie dzisiaj działa, dodali nam procków, czy coś? Nagle telefon od przedłożonego: – No heeej, robicie coś z produkcją? To był piątek. Godzina 13. :⁠-⁠D

W tym przypadku myślę, że zadziałała rutyna. No i piątek;) A tak poważnie, to instancja testowa powinna mieć zupełnie inną kolorystykę niż produkcyjna. To samo terminal serwera – inne kolory i inny motd (message of the day, czyli wiadomość powitalna).

Ja zmienilem sobie nazwy statusów na workflow i potem bylem zdziwiony ze w sumie te same statusy pozmieniały nazwy na innych projektach … potem zeby to odkrecic to caly zespol klikal pol dnia🤪

Tak to niestety działa – nazwy statusów są unikalne w Jira. Zmiana w jednym workflow zachodzi we wszystkich, które używają tego statusu. Jira przed tym ostrzega (nie wiem jak było we wcześniejszych wersjach) ale moim zdaniem taka zmiana powinna być możliwa jedynie z poziomu strony dotyczącej samych statusów (jiraurl/secure/admin/ViewStatuses.jspa). Dodatkowo nie ma możliwości sprawdzenia (a przynajmniej ja jej nie znalazłem) poprzednich nazw dla zmienionych statusów.
 

Klient miał na hoście dwie Jiry i zrobiłem upgrade… nie tej. Dodatkowo nowa wersja nie miała już aktualnej licencji, a backup bazy danych był wadliwy, więc rollback nie wchodził w grę. Ale finalnie udało się dogadać, żeby zostawić jak jest i wgrać licencję trialową.

Ogólnie – katastrofa. Zadziało się tu kilka rzeczy. Przede wszystkim instalator Jira mógł wskazać domyślnie katalog instalacyjny innej instancji Jira (skąd mógł wiedzieć). Problem z backupem to osobny temat, który powinien być zaadresowany niezwłocznie po takim upgrade. Reszta to kwestia komunikacji i dobrej woli. Jeśli w planach był również upgrade i odnowienie licencji dla tej instancji, to po prostu zostało to zrobione wcześniej.

A czy Wy macie podobne historie, którymi chcecie się podzielić? Odwagi! 🙂

(fot. Nicola Barts)

2 Comments
  1. Hej,

    To dodam coś od siebie. Dawno dawno temu w odległej galaktyce pomyślałem, że zmiana jednego loginu w Bazie Danych w JIRA nie będzie miała żadnego wpływu na inne loginy. Dodałem chyba jak dobrze pamiętam nowy wpis w bazie danych i potem to już wszystkie kolejne loginy zaczęły się źle zakładać. Samo logowanie było ok ale jedno z pól w tabeli chyba jira_users się sypało cały czas. Tal, więc zmiany w bazie danych w JIRA na dużym ryzyku.

    Pozdro

    1. Tak, zmiany na bazie to ryzyko. Ale te loginy to specyficzna sprawa. Jak założysz nowe konto dla użytkownika, to po pierwszym zalogowaniu, jego login zapisuje się do tabeli app_user jako user_key. Jeśli okaże się, że przy zakładaniu zrobiłeś np. błąd w loginie i później go zmienisz (np. z poziomu AD), to i tak user_key pozostanie stary. To może rodzić problemy np. przy skryptowaniu, gdzie będą występować obie wersje loginu: stara (w funkcjach, które odwołują się odwołują się do user_key) oraz nowa (np. z pola user picker).
      Zmiana loginu w bazie jest wtedy jednym z wyjść, ale jak zauważyłeś to bardzo ryzykowne.

Leave a reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *