W codziennej pracy z kodem ważne jest, by nie tracić czasu na sprawy operacyjne. Jak jednak nie zagubić się w zgłoszeniach i kontrybucjach swoich oraz innych osób? Jak rozpoznać czemu należy się przyjrzeć? Jak niczego nie przegapić? Zarówno GitHub, jak i Gitlab mają swoje własne mechanizmy do monitorowania aktywności – przyjrzyjmy się im!

Kontekst

Na początku nakreślmy perspektywę, z której zaprezentuję oba wspomniane systemy.

Z Gitlabem mam do czynienia na co dzień od wielu lat, ponieważ firmy, z którymi współpracowałem i obecnie współpracuję, wybrały tę platformę do przechowywania kodu, realizacji code review i automatyzacji procesów CI/CD (istotnym argumentem za taką decyzją jest fakt, że Gitlab można uruchomić jako instancję On Premise we własnej infrastrukturze, nie wypuszczając kodu poza sieć firmową).

GitHub z kolei jest swego rodzaju standardem w świecie Open Source, można zatem śmiało stwierdzić, że korzystanie z niego jest w pewnym sensie nieuniknione – czy to w formie zgłoszeń w używanych projektach, czy w formie kontrybucji. Swoje własne projekty OSS również przechowuję na GitHubie, głównie po to by poznawać jego możliwości od strony maintainera.

Okoliczności te sprawiają, że z Gitlaba korzystam zdecydowanie więcej niż z GitHuba, ale jednocześnie nie oznacza to, że jednoznacznie wskazałbym którąś z tych platform jako lepszą – są one po prostu inne, choć mają wiele podobieństw.

Być na bieżąco

To, na czym chciałbym się skupić w tym artykule, to techniki obserwowania i reagowania na aktywności w systemie, głównie w kontekście merge/pull requestów (ale nie tylko). Możemy wyróżnić 2 podstawowe potrzeby:

  • dostęp do listy wszystkich zadań lub merge/pull requestów, które obserwujemy (będąc autorem, recenzentem czy po prostu śledząc przebieg wydarzeń)
  • dostęp do aktywności w ramach tychże (komentarze innych osób, zmiany w kodzie, zmiany stanu)

Lista jest nam potrzebna, by móc w dowolnej chwili odnaleźć interesujące nas zadanie lub merge request, samemu decydując, czego w danym momencie szukamy. Możemy potrzebować, żeby dodać jakiś komentarz rzucający nowe światło na sprawę, albo chcieć podzielić się linkiem z innymi osobami. W takiej chwili chcemy mieć możliwość wyszukania interesujących nas rzeczy, korzystając z różnych kryteriów.

Z kolei chcąc być na bieżąco z tym, co dzieje się w obserwowanych przez nas zgłoszeniach czy też MRach, chcielibyśmy mieć dostęp do chronologicznego strumienia zdarzeń w obserwowanych przez nas obszarach.

O ile pierwszą potrzebę realizują obie platformy, o tyle drugą zaadresował jedynie GitHub swoim systemem powiadomień. Osobiście bardzo lubię ten widok i znacząco ułatwia mi on śledzenie tego, co się dzieje. W przypadku Gitlaba muszę posiłkować się mizernym ekwiwalentem, jakim są powiadomienia email…

Praca z GitHub

Obserwowane obszary

GitHub daje nam wiele predefiniowanych widoków do śledzenia obserwowanych obszarów, z których dwa są dostępne w głównym, górnym menu:

Oba te widoki oferują zarówno możliwość przejścia do innych predefiniowanych widoków, jak i zmianę domyślnych kryteriów wyszukiwania (domyślnie wyświetlane są otwarte PRy/zgłoszenia we wszystkich organizacjach).

Moje Pull Requesty

Przyjrzyjmy się liście Pull Requestów i temu, co nam prezentuje:

Lista Pull Requestów w GitHub
  1. Przełącznik kontekstu: otwarte i zamknięte PRy
  2. Predefiniowane widoki dla PRów: stworzone przeze mnie (domyślny); przypisane do mnie; ze wzmianką o mnie; z prośbą o recenzję
  3. Zaawansowana wyszukiwarka oferująca mnóstwo filtrów
  4. Pomocnicze filtry i ustawienia widoku
  5. Etykiety przypisane do PRów
  6. Stan wykonania ostatnich Akcji
  7. Stan checklisty w ramach PR (postęp prac)
  8. Powiązane zgłoszenia
  9. Ilość komentarzy

Moje zgłoszenia

Bardzo podobne funkcjonalności i zestaw prezentowanych informacji oferuje widok zgłoszeń:

Lista zgłoszeń w GitHub

Wszystkie te elementy są pomocne w kontekście wyszukiwania interesujących nas treści i ciężko znaleźć scenariusz, w którym odnalezienie konkretnych rzeczy byłoby niemożliwe. Pomocne są również podpowiedzi wyświetlane pod listą, które zawierają losowe informacje o dostępnych filtrach i sposobach ich wykorzystania.

Wyszukiwarka

Niemniej jednak do tej beczki miodu trafiła łyżka dziegciu. Wyszukiwarka w GitHubie ma jeden, ale za to spory mankament: nie oferuje podpowiadania. Efekt jest taki, że musimy się nauczyć filtrów na pamięć, lub za każdym razem korzystać z dokumentacji.

Na szczęście istnieją nieoficjalne rozwiązania dla tego problemu, mianowicie skrypty użytkownika takie jak np. ten. Ułatwiają one znacznie korzystanie z wyszukiwarki, podpowiadając jakich filtrów można użyć oraz jakie wartości owe filtry przyjmują (w przypadku wartości słownikowych).

Widok powiadomień

Jak już wcześniej wspomniałem, GitHub oferuje widok powiadomień, który bardzo lubię. Przyjrzyjmy się mu:

Lista powiadomień w GitHub
  1. Konteksty:
    • Inbox: tam znajdziemy wszystkie nowe powiadomienia. Ja używam go również do utrzymywania listy rzeczy, z którymi chcę być na bieżąco
    • Saved: elementy zapisane na później (patrz punkt 7)
    • Done: elementy oznaczone jako wykonane
  2. Szybkie filtry umożliwiające ograniczenie wyświetlanych powiadomień według rodzaju aktywności
    • Przypisane do mnie
    • Uczestniczę w jakikolwiek sposób (obserwuję, skomentowałem itp.)
    • Zostałem oznaczony (wzmiankowany)
    • Zespół, którego jestem członkiem, został oznaczony (wzmiankowany)
    • Zostałem poproszony o recenzję (code review)
  3. Lista repozytoriów, z których pochodzą powiadomienia, możemy dzięki temu w szybki sposób ograniczyć wyniki do pojedynczych repo
  4. Filtr umożliwiający ograniczanie powiadomień według kryteriów. Co ciekawe, w tym widoku można korzystać z podpowiedzi 🤷‍♂️
  5. Rodzaj elementu, którego dotyczy powiadomienie. Dzięki temu widać wyraźnie, czy powiadomienie dotyczy zgłoszenia, Pull Requestu, dyskusji czy nowej wersji wydanej w obserwowanym projekcie. Więcej: widać nawet czy zgłoszenie lub PR są otwarte, czy zamknięte.
  6. Metoda subskrypcji: pokazuje nam czy to my jesteśmy autorami, czy np. skomentowaliśmy
  7. Kontrolki kontekstowe: po najechaniu kursorem myszy na wybrany element pokazują nam się guziki akcji:
    • oznacz jako wykonane
    • zrezygnuj z subskrypcji
    • zapisz na później
  8. Czas ostatniej aktywności

Jak widać, mamy tu mnóstwo wartościowych informacji oraz wiele możliwości wyszukiwania tego, co jest nam potrzebne. Ja korzystam z tego widoku na bieżąco, reagując na nowe powiadomienia i podejmując odpowiednie akcje. Kiedy nie mogę się czymś zająć od ręki, zostawiam to sobie w skrzynce Inbox i wracam do tego w wolnej chwili. Dzięki temu widok powiadomień służy mi jednocześnie jako lista zadań (To Do).

GitHub w praktyce

W ostatnim czasie trochę więcej zacząłem używać GitHuba, ponieważ kontrybuowałem do różnych projektów Open Source. Nie było to oczywiście użytkowanie w dużej skali — jest mnóstwo osób, które utrzymują/wspierają znacznie więcej repozytoriów i muszą śledzić ogromną ilość aktywności, zatem moja perspektywa może nie być do końca obiektywna i miarodajna. Jednak wciąż może okazać się przydatna 😉

W przypadku GitHuba powiadomienia mailowe traktuję tylko jako dodatkowy kanał, który w pewnych sytuacjach może przyspieszyć moją reakcję — jakby nie było, telefon mam praktycznie cały czas przy sobie, więc jest dużo większa szansa, że zauważę tego rodzaju powiadomienie szybciej niż w UI GitHuba (szczególnie w godzinach popołudniowych i wieczornych). W takim wypadku, gdy podejmę akcję po otrzymaniu maila, od razu w widoku powiadomień oznaczam taki element jako wykonany.

Staram się dążyć do “0 Inbox”, czyli pustej skrzynki odbiorczej w widoku powiadomień. Nie jest to oczywiście sztywna zasada, dlatego że czasem świadomie zostawiam tam sobie elementy, z którymi już się zapoznałem (i nawet zareagowałem), po to, by móc łatwo do nich wrócić. Z kolei jeśli chciałbym móc łatwiej odnaleźć elementy, które uważam za istotne, ale które już zostały zakończone (np. zmerdżowany PR), to oznaczam je sobie jako zapisane.

Uważam, że kluczem do dobrej organizacji w kontekście śledzenia aktywności jest jak najszybszy dispatching — nie można sobie pozwolić na zbyt dużą górkę powiadomień, bo wtedy coraz trudniej jest z nimi pracować, co może doprowadzić do “znieczulicy” i zupełnego zaprzestania korzystania z tego widoku. Jeśli dochodzi do sytuacji, że powiadomień jest więcej, niż możemy udźwignąć, należy się zastanowić nad zmianami ustawień powiadomień w poszczególnych projektach — być może niektóre nie są na tyle istotne, by musiały nam zasypywać skrzynkę.

Można też oczywiście stworzyć jakieś wewnętrzne ustalenia w organizacjach/projektach i dzielić pracę między wiele osób. Jest też oczywiście kwestia automatyzacji z użyciem botów, ale to już zupełnie inna historia 😉

Praca z Gitlab

Obserwowane obszary

W Gitlabie górne menu dostarcza nam trzy guziki, które kierują nas do dedykowanych widoków:

  • Zadania, do których jesteśmy przypisani
  • Merge Requesty (menu rozwijane):
    • przypisane do nas
    • w których poproszono nas o recenzję (code review)
  • To-Do lista

W dalszej części przybliżę widok zadań i Merge Requestów w innych kontekstach, niż te, które podlinkowane są w górnym menu. Po pierwsze dlatego, że nie mogę użyć tutaj zrzutów ekranu z firmowych instancji Gitlaba, a po drugie dlatego, że w publicznie dostępnym Gitlabie w tych widokach mam pustki z racji tego, że nie jestem nigdzie przypisany 😉. Jednak informacje wyświetlane na tych widokach będą dokładnie takie same, jedyną różnicą będzie wybrany filtr.

Moje zadania

Przyjrzyjmy się liście zadań w Gitlabie:

Lista zadań w Gitlab
  1. Konteksty: otwarte, zamknięte, wszystkie
  2. Różnego rodzaju pomniejsze kontrolki: kanał RSS, subskrypcja kalendarza, import/export, tworzenie nowego zgłoszenia
  3. Wyszukiwarka (filtry)
  4. Wybór sposobu sortowania wyników
  5. Data ostatniej modyfikacji
  6. Liczniki reakcji i komentarzy
  7. Etykiety
  8. Milestone, do którego przypisane jest zadanie

Widok jest schludny, jednak robi się ciężki przy dużej ilości etykiet (wystarczy spojrzeć na issue tracker Gitlaba).

Moje merge requesty

Widok merge requestów jest bardzo podobny, różni się detalami:

Lista Merge Requestów w Gitlab

Są trochę inne konteksty, trochę mniej kontrolek, a w każdej pozycji na liście dodatkowo mamy:

  1. Stan MRa (widoczny tylko w kontekście All)
  2. Stan ostatniego pipeline
  3. Osoby przypisane (assignee) oraz recenzenci (reviewer)
  4. W przypadku stosowania Approval Rules mamy również informację o tym, czy MR został zaakceptowany

Prośby o recenzję

Widok próśb o recenzję zasadniczo nie różni się od innych widoków z listą Merge Requestów, polega po prostu na tym, że kryterium wyszukiwania jest ustawione tak, byśmy widzieli, gdzie jest wymagane nasze code review (i ewentualnie approval). Widok ten ma jeden, ale to zasadniczy mankament — jest absolutnie nieużyteczny.

Powód jest prosty: w Gitlabie nie istnieje (póki co) koncepcja “oczekiwanych zmian”, czyli sytuacji, gdy kończymy code review, nie dajemy approve, ale zostawiliśmy komentarze i chcielibyśmy, aby taki MR zniknął nam z listy aż do czasu wprowadzenia zmian i ponownego żądania recenzji. Obecnie wygląda to tak, że gdy jesteśmy recenzentami, to widzimy taki MR cały czas na liście, co przy większej ilości MRów bardzo utrudnia kontrolowanie tego, gdzie wymagana jest nasza akcja.

Jakiś czas temu Gitlab pracował nad koncepcją “Merge Requestów wymagających mojej uwagi”, która wyglądała obiecująco, jeśli chodzi o śledzenie aktywności w MRach. Niestety, pomysł został zarzucony, a prace skupiły się nad koncepcją “rund recenzenckich”. W obu tematach starałem się brać aktywny udział, przedstawiając perspektywę użytkownika (tutaj, tutaj, tutaj, tutaj, tutaj i różnych innych miejscach).

Niestety, w tym kontekście GitHub znacznie lepiej wspiera śledzenie miejsc, które wymagają naszej akcji. Liczę na to, że w Gitlabie zostanie wprowadzona trójstanowość recenzji (zaakceptowane; oczekiwane zmiany; odrzucone), co umożliwi wygodniejszą pracę z narzędziem.

To-Do lista

Widok To-Do grupuje nam działania, jakie powinniśmy podjąć. Zawarte w nim dane są bardzo czytelne:

Lista ToDo w Gitlab
  1. Konteksty: do zrobienia, zrobione
  2. Filtry umożliwiające zawężenie kryteriów
  3. Rodzaj sortowania

Muszę przyznać, że widok To-Do odwiedzam rzadko. Dzieje się tak dlatego, że zawarte w nim informacje nie są dla mnie pomocne, albo po prostu pozostałe widoki zapewniają mi to, czego potrzebuję.

Elementy pojawiają się na liście w różnych momentach: gdy zostaniemy dodani jako recenzenci, gdy ktoś nas wzmiankuje (@mention) w komentarzu itp. Mam jednak wrażenie, że dzieje się to w sposób chaotyczny — np. gdy sam siebie dodam jako recenzenta w MR, element pojawia się wprawdzie na liście To-Do, ale w kontekście Done 🙄. I nawet gdy elementy pojawią się w prawidłowym kontekście To Do, to znikają z niego automatycznie po wykonaniu akcji (np. skomentowaniu MR, a przecież to nie oznacza, że recenzja została skończona).

Jak widać na powyższym obrazku, jednak znalazłem jakieś zastosowanie dla tego widoku — dodaję sobie tam elementy, które obserwuję i do których chcę mieć szybki dostęp. W tym celu klikam “Add a to do” w bocznym, prawym menu w widoku issue/MR.

Używam Gitlaba od wielu lat, a mimo to do dzisiaj nie udało mi się wycisnąć więcej z tego widoku. Może powinienem poświęcić mu trochę uwagi i jednak może mi pomóc? Chętnie poznam opinie i porady 🙂

Wyszukiwarka

Wyszukiwarka w Gitlabie jest przyjemna w użytkowaniu ze względu na podpowiadanie możliwych filtrów, operatorów (rodzajów porównań) i wartości. Wizualnie wygląda to dobrze i pomaga w użyciu, jednak niestety jest kilka rzeczy, do których mogę się przyczepić:

  • filtrów jest mało, zwłaszcza gdy się porówna z mnogością filtrów wspieranych przez GitHub
  • jeśli wybierzemy z listy błędną wartość, to jej kasowanie jest niewygodne: używając backspace, możemy ją skasować (ale nie za jednym zamachem, tylko jako edytowany tekst), podczas gdy guzik ❌ usuwa wartość wraz z operatorem i filtrem
  • Nie ma możliwości stworzenia uniwersalnego filtru opartego o aktualnie zalogowanego użytkownika, przez co nie da się w prosty sposób współdzielić linków do widoków z wstępnie uzupełnionymi kryteriami wyszukiwania. Zgłosiłem takie zapotrzebowanie, ale nie ma raczej co liczyć na wdrożenie w niedalekiej przyszłości…

Powiadomienia… email

Gitlab nie posiada wbudowanego widoku powiadomień, więc niestety śledzenie aktywności w obserwowanych zadaniach i merge requestach jest mocno utrudnione. Opisane wcześniej widoki raczej tego nie ułatwiają. Sortowanie według daty ostatniej modyfikacji może nieznacznie pomóc w odnalezieniu rzeczy do przejrzenia, niemniej jednak trzeba wtedy mocno polegać na swojej pamięci, lub rutynowo sprawdzać codziennie wszystko, by nie musieć się zastanawiać co już było sprawdzane, a co nie.

Osobiście wypracowałem sobie proces oparty o powiadomienia mailowe. Jest on bardzo zbliżony do tego, jak pracuję z widokiem powiadomień w GitHub, tylko robię to w kliencie poczty. I to jest podstawowa wada tego rozwiązania – wymaga przeskoków między narzędziami. Mój proces wygląda następująco:

  • wszystkie powiadomienia z Gitlaba są włączone i spływają do dedykowanego folderu na poczcie (filtr)
  • mail nieprzeczytany = powiadomienie do zapoznania się lub takie, do którego chcę wrócić
  • mail przeczytany = aktywność zweryfikowana, ale wciąż czekam na akcję po drugiej stronie (np. poprawki po mojej recenzji)
  • mail usunięty = powiadomienie nie wymaga mojej reakcji

Celem jest zachowanie pustego folderu “Gitlab” w skrzynce pocztowej, zatem maile usuwane są na bieżąco – albo gdy nie wymagają mojej reakcji, albo gdy taką reakcję wykonam. To doskonale wpisuje się także w sprawny proces code review, ponieważ szybkie przetwarzanie powiadomień pomaga w szybkiej integracji kodu. Im szybciej podejmę działanie wynikające z powiadomienia, tym szybciej odblokuję osobę “po drugiej stronie procesu” 🙂.

W skrzynce zostawiam tylko maile, do których chcę wrócić (np. gdy widzę, że do MR doszły nowe commity i trzeba wykonać kolejną iterację code review). Jeśli coś jest ważne i chcę do tego wrócić wcześniej, pozostawiam wiadomość oznaczoną jako nieprzeczytaną. Takie podejście, w połączeniu z widokami MRów (gdzie jestem autorem lub recenzentem) pozwala mi być na bieżąco z tym, za co jestem odpowiedzialny.

Nie oznacza to jednak, że proces ten jest wygodny i optymalny… Jest to raczej obejście problemu, a nie jego rozwiązanie 🤷‍.

Gitlab w praktyce

Jak można zauważyć powyżej, mój sposób pracy z Gitlabem to miks wykorzystania predefiniowanych widoków z podejściem tzw. email-driven. Nie jest to może optymalne wykorzystanie potencjału Gitlaba, ale taki system wypracowałem sobie przez lata pracy z tym systemem i wydaje mi się, że całkiem dobrze mi się to sprawdza. Co nie znaczy oczywiście, że nie ma w Gitlabie nic, co by można poprawić.

Co naprawdę utrudnia pracę z perspektywy recenzenta, to brak wspomnianej wcześniej trójstanowości. Doszło nawet do tego, że stworzyłem sobie user script, który dodaje mi w górnym menu dodatkową pozycję — kieruje do listy MRów, w których jestem recenzentem, ale których jeszcze nie zaakceptowałem. Jako że stosujemy zasadę, że każdy push kasuje approval, wiem, że po zaakceptowaniu MR wróci mi na tę listę tylko, gdy pojawią się w nim nowe zmiany. To minimalnie poprawia komfort pracy, ale wciąż nie rozwiązuje scenariusza, gdy jako recenzent oczekuję zmian (skończyłem code review, ale nie zaakceptowałem MR); w takiej sytuacji zostaje śledzenie maili lub żmudne sprawdzanie widoku “Review requests for you” i weryfikowanie dat ostatniej modyfikacji.

W przypadku Gitlaba również celuję w “0 inbox”, ale bardziej w kontekście nieprzeczytanych wiadomości, niż ogólnie wiadomości w skrzynce (czyli staram się, by nie było żadnych wiadomości, na które powinienem zareagować). Najchętniej celowałbym również w “0 To-Do”, ale w związku z brakiem sensownego widoku powiadomień używam tego widoku jako “notatnika”, więc w menu ciągle widzę niezerowy licznik 🤷‍♂️.

GitHub vs Gitlab: wady i zalety

W ogólnym rozrachunku muszę przyznać, że w kwestii śledzenia aktywności bardziej odpowiada mi GitHub, co jest trochę smutne w kontekście tego, że więcej czasu spędzam na Gitlabie 😉.

Widok powiadomień znacznie ułatwia mi bycie na bieżąco z nowymi aktywnościami oraz powrót do śledzonych przeze mnie tematów. I nawet jeśli uważam, że Gitlab w górnym menu ma linki, które bardziej mnie interesują (kierują do widoków, gdzie potrzebne jest moje działanie, podczas gdy w GitHubie kierują do widoków z moimi aktywnościami), to zaleta ta szybko okazuje się mało istotna, gdy okazuje się, że w tych widokach trudno jest odnaleźć to, czego potrzebuję. Tym bardziej, że w GitHubie wystarczy zmienić kontekst jednym kliknięciem i błyskawicznie przejść np. do widoku Pull Requestów, w którym realnie potrzebna jest moja recenzja.

Podziel się swoim doświadczeniem i opinią!

Bardzo jestem ciekaw jak inni widzą GitHub i Gitlab w kontekście śledzenia aktywności i jak technicznie modelują swój proces pracy z tymi narzędziami. Będę zatem wdzięczny za każdą opinię, sugestię, czy pytanie otwierające dyskusję. Zachęcam do zostawiania komentarzy lub interakcji na Twitterze 🙂