Code review
Określenie reguł i wybór narzędzia do code review.
zebranie informacji od zespołów w jaki sposób robią review,
zebranie i porównanie narzędzi pod kątem przyjazności dla dewelopera, ale jednocześnie łatwości integracji z pipeline’ami.
Perspektywa zespołów
Korzystamy jedynie z GitLab’a - review na MR:
powiadomienia podpięte pod kanał na Teams (webhook określany z poziomu grupy projektów) - założenie / zamknięcie MRa,
MR w momencie zatwierdzenia przez innych członków zespołu (przycisk
Approve), dodatkowo jest opcja zablokowania go w przypadku, gdy powiązany z nim pipeline nie powiedzie się,Raczej nie narzekamy na filtrowanie komentarzy i rozwiązywanie potencjalnych problemów, znamy różne funkcje i możliwości więc chętnie się podzielimy i zderzymy to z wcześniejszymi “porównaniami”
Zestawienie
Zalety Crucible
obsługa wielu projektów w ramach jednego review,
automatyczne logowanie czasu w taskach,
pełna integracja z Jirą:
tworzenie review z poziomu zadania,
wyświetlanie stanu review oraz liczby osób, które je wykonały,
możliwość tworzenia zadania w Jirze z poziomu komentarza w Crucible’u (oraz powiązanie go z utworzonym komentarzem),
możliwość zmiany statusu zadania podczas zamykania review,
możliwość uwzględnienia kilku małych zadań w jednym review.
Wady Crucible
"Fisheye i Crucible są w pełni funkcjonalnym ofertami, które znajdują się w trybie podstawowego utrzymywania, co oznacza, że nie będziemy już wprowadzać nowych funkcji w ich przypadku."
“Wynalazek” wywołuje niechęć u nowych pracowników,
Ręczne dodawanie projektów, często powiązane problemy z uprawnieniami,
Powolne zaciąganie zmian
Zalety GitLaba
review oraz deployment w jednym miejscu,
możliwość integracji z sonarem, który wykonuje “połowę roboty”,
popularne narzędzie na zewnątrz (brak wymaganych szkoleń dla nowych pracowników),
GitLab w 100% wystarcza do dodawania komentarzy jak code review robi się zgodnie z sztuką w IDE,
automatyczne zaciąganie zmian z commitów dla danego brancha,
wpięcie w CI-CD,
możliwość integracji z MS Teams (wysyłanie powiadomień o nowych MR, komentarzach, statusach itd.),
Lepsze komentarze i możliwość umieszczania w nich bezpośrednio obrazków, bez wrzucania ich uprzednio do zadania.
Potwierdzanie anulowania dodawania komentarza, bez szukania w historii review wśród zapisanych wersji roboczych (na szczęście komentarze nigdy nie ginęły tylko trzeba było je odszukać).
Chyba lepsze kolorowanie składni, kwestia gustu.
Nie ma możliwości, że ktoś zapomniał dorzucić zmian do review, bo widoczny jest każdy commit.
Gdy develop zostanie zaktualizowany o zmiany, a nasz MR jest starszy to mamy możliwość z poziomu MR na domergowanie developa do naszego brancha(checkout) i dzięki temu nie bedzie konfliktu przy wdrażaniu
Widzimy wszystkie aktualne zmiany względem developa - nic nie umknie. W przypadku Crucible po dociągnięciu developa do naszego brancha i wystawieniu wszystkiego do review - Crucible głupiało i np. pokazywało pliki podwójnie. Dlatego często ludzie nie załączali commita mergującego z developem do review - więc nie był on sprawdzany, a co za tym idzie jeśli podczas tego merga rozwiązywane były konflikty i ktoś popełnił błąd - wpadało to do developa.
Informowanie o tym, że nasze zmiany się skonfliktowały.
System na bieżąco aktualizowany, bez limitu użytkowników - czego nie można powiedzieć o Crucible
Duże możliwości integracyjne z pipeline'ami
Możliwość zrobienia powiązań między merge requestami - Merge request dependencies - prawdopodobnie będzie kupiona wersja premium gitlaba, w której jest dostępna ta funkcjonalność