FishEye + Crucible + JIRA czyli inspekcje kodu w dużych projektach
Każdy zespół programistów, ma własną receptę na inspekcję kodu. W zależności od liczby osób w zespole oraz przykładanej wagi do jakości kodu, inspekcje mogą wyglądać nieco inaczej. Czasami wystarczy poprosić kolegę siedzącego obok, podając mu informację o zakresie rewizji oraz z jakim zadaniem się ona wiąże, tak by mógł przejrzeć kod z wykorzystaniem prostego narzędzia jakim jest np. vimdiff. Niestety często takie rozwiązanie nie jest wystarczające – zwłaszcza w dużym zespole z dynamicznie modyfikowanym kodem. W niniejszym wpisie chciałbym przybliżyć możliwości narzędzi pochodzących od firmy Atlassian skupiając się głównie na produkcie Crucible, który znacząco ułatwił mi pracę. Dodatkowo obecnym artykułem chciałbym rozpocząć cykl kolejnych poruszających tematykę inspekcji kodu.
Problematyka inspekcji kodu w dużych projektach
Wyobraźmy sobie sytuację, w której mamy dwa zespoły składające się z testerów i programistów, którzy pracują w oddalonych od siebie miejscach. Każdy zespół liczy między 7, a 9 osób i pracuje nad tym samym produktem. Dodajmy do tego jeszcze inspekcje kodu bez użycia jakiś wyspecjalizowanych narzędzi. Wówczas pojawiają się m.in. takie problemy jak:
- informowanie pozostałych osób o konieczności inspekcji
- informowanie autora kodu o zakończeniu inspekcji i ewentualnych wymaganych poprawkach
- poinformowanie osoby, która robiła inspekcję o wprowadzeniu poprawek i prośba o kolejną
- zmiany w kodzie, który jest w trakcie inspekcji przez inne osoby niż zgłaszający konieczność inspekcji oraz osoba jej dokonująca
- pytania w trakcie inspekcji i konieczność konsultacji z innymi członkami zespołu
- zmiana statusów zadań
- zgłaszanie błędów/zadań powiązanych z kodem do późniejszego rozwiązania
- wygoda przeglądania zmian w kodzie
Oczywiście wymienione pozycje na liście to tylko garstka problemów jakie się pojawiają w przypadku inspekcji kodu w dużych projektach. Na szczęście znaczna ich liczba została rozwiązana przez różne narzędzia.
FishEye
Jest to narzędzie umożliwiające przeglądanie różnych repozytoriów (m.in. Subversion, Perforce, GIT, Mercurial), zapewniające spójną prezentację. Przydatne zwłaszcza kiedy poszczególne składowe projektu korzystają z kilku systemów wersjonowania. Zapewnia mechanizmy znacznie przyspieszające wyszukiwanie informacji o konkretnych rewizjach czy plikach. Jest to możliwe dzięki rozwiązaniu polegającym na zeskanowaniu struktury danego repozytorium i umieszczeniu tych informacji bezpośrednio w bazie danych. Dzięki FishEye możemy nasz kod pozwiązywać bezpośrednio ze zgłoszeniami z JIRY. Mechanizm automatycznego rozpoznawania comitów zapewnia, że są one widocznie w konkretnym zadaniu w JIRA niezwłocznie po ich umieszczeniu w repozytorium. W praktyce oznacza to, iż programista może uzyskać niezbędne informacje nie wychodząc z zadania w JIRA, co pozwala zaoszczędzić czas. Wbudowane mechanizmy wizualizacji branchy, comitów oraz diffów ułatwiają analizę oraz dostarczają czytelnych statystyk. W moim przekonaniu jest to użyteczne narzędzie w przypadku kiedy jest zintegrowane z JIRĄ. W przeciwnym razie pełni rolę nakładki na repozytorium i nie przynosi aż tak wielu wymiernych korzyści.
Crucible
Podstawową funkcją tego narzędzia jest możliwość komentowania kodu. Nie zawsze musi ona służyć typowym inspekcjom kodu z czym głównie utożsamiany jest Crucible. Dzięki różnorodnemu podejściu do komentowania źródeł oraz wielowątkowym dyskusjom jest używane również jako miejsce, w którym można przedyskutować zmiany implementacyjne, z innymi członkami zespołu, jeszcze przed ich wprowadzeniem. Dzięki integracji z JIRA jest możliwe wskazanie miejsc w kodzie, które należy zmienić, bezpośrednio z utworzonego zadania. Chociaż Crucible jest bardzo użyteczne samo w sobie i nie musi być integrowane z JIRA, to dopiero połączenie tych dwóch dostarcza nam największych korzyści. W dalszej części wpisu postaram się je zaprezentować zakładając, że używamy obu produktów i są one ze sobą zintegrowane. Możliwości narzędzia najprościej pokazać jest na konkretnych przykładach. Załóżmy, że mamy utworzone zadanie w JIRA mówiące o konieczności implementacji nowej funkcjonalności w istniejącej aplikacji. Realizator zadania – Piotr ukończył je i zgłasza zapotrzebowanie na inspekcję kodu. Kod przeznaczony do inspekcji może wybrać na kilka sposobów:
- wskazać rewizję do inspekcji w ramach repozytorium
- wybrać cały branch w ramach którego zostało zaimplementowane zadanie
- wskazać konkretne pliki z repozytorium do inspekcji
- załadować paczkę zmian (w przypadku jeśli inspekcja ma mieć miejsce przed wysłaniem zmian do globalnie dostępnego repozytorium)
- załadować konkretny plik nie wskazując konkretnego repozytorium
W zależności od wybranego sposobu Crucible oferuje różne mechanizmy późniejszego śledzenia zmian oraz zarządzania zadaniem inspekcji kodu. Załóżmy, że programista wybrał do przeglądu cały branch. W kolejnym kroku może zdefiniować względem którego brancha ma być porównywany dany branch oraz czy nowe comity mają automatycznie zmieniać status zadania inspekcji kodu. Oczywiście istnieje możliwość wyboru kilku branchy do sprawdzenia w ramach jednego zadania.
Opcja automatycznej aktualizacji zadania inspekcji jest bardzo użyteczna – w zależności od konfiguracji wiąże się ona z powiadomieniami mailowymi oraz automatyczną zmianą statusów zadań w JIRA (więcej informacji na ten temat można znaleźć tutaj). W naszym przykładzie wybieramy opcję aktualizacji automatycznej. Dodatkowo zadanie inspekcji kodu łączymy z konkretnym zadaniem w JIRA co będzie skutkowało zmianą statusu zadania JIRA np. na „code review”. Zanim uruchomimy inspekcję (do tego czasu nie jest aktywna) możemy jeszcze usunąć poszczególne pliki z inspekcji (nie koniecznie chcemy zawracać komuś głowę sprawdzaniem pliku CSS ze zmianą koloru danego elementu).
Po uruchomieniu inspekcji zadanie w JIRA zmienia status. Zaraz po przypisaniu do konkretnej osoby, która ma jej dokonać, wysyłany jest mail informujący o przypisanym zadaniu. Od tej chwili zaczął się proces sprawdzania kodu. Załóżmy, że inny programista Alex odczytał e-maila i rozpoczął inspekcję kodu (zmienił status zadania w Crucible). Piotr otrzymał powiadomienie mailowe zaś zadanie w JIRA automatycznie zyskało inny status. Piotr może na bieżąco śledzić postęp inspekcji kodu (podawany procentowo w ramach zadania). Dodatkowo jest informowany o komentarzach i uwagach Alexa. Ciekawą i przydatną opcją jest możliwość tworzenia nowego zadnia w JIRA bezpośrednio z inspekcji kodu np. w przypadku, gdy dany kod jest zgodny z danymi wymaganiami, ale w przyszłości może wymagać aktualizacji – oczekiwana nowa wersja API, etc. Alex po zgłoszeniu uwag zmienia status zadania inspekcji na zamknięte, wysyłane jest powiadomienie mailowe do Piotra i zmieniany automatycznie status zadania w JIRA. Od tej chwili Piotr może skomentować wymagane poprawki lub jeśli są jasne wprowadzić zmiany w kodzie. Zacomitowanie zmian spowoduje automatyczne otwarcie zadania inspekcji i powiadomienie Alexa o konieczności ponownego sprawdzenia.
Zaprezentowane możliwości to tylko jedne z wielu – zachęcam do przetestowania opisanych narzędzi oraz zgłębienia tematu bezpośrednio na stronach firmy Atlassian.
Warto obejrzeć:
