Metryki inżynieryjne GitHub vs GitLab: co można porównać?
Zbuduj model wspólnego dostarczania dla wszystkich dostawców, nie udając, że ich koncepcje przeglądu, planowania i tożsamości są identyczne.
Normalizuj typowy cykl życia dostaw
Żądania ściągania GitHub i żądania scalania GitLab mają ten sam użyteczny rdzeń: repozytorium, autor, stan, czas utworzenia, czas scalania, docelowa gałąź, etykiety, osoby przypisane, żądani recenzenci, zatwierdzenia i adres URL dostawcy. Znormalizowany model może obsługiwać otwartą pracę, czas scalania, przepustowość, nieaktualne zmiany, udział współautorów i aktywność repozytorium u obu dostawców. Zachowaj dostawcę i identyfikator rekordu dostawcy w każdym wierszu, aby użytkownicy mogli otworzyć źródło, a dzięki temu powtarzane synchronizacje aktualizują prawidłowy rekord zamiast tworzyć duplikaty.
Zachowaj różnice, zamiast je spłaszczać
Dostawcy różnią się zasadami zatwierdzania, przypisaniem recenzentów, zachowaniem wersji roboczej, interfejsami API zdarzeń, hierarchią projektu, etykietami, kamieniami milowymi, iteracjami i sposobem wyświetlania tożsamości w grupach lub organizacjach. Pole, którego nie ma, nie jest automatycznie zerem. Normalizuj to, co ma równoważne znaczenie, a resztę zachowaj metadanych specyficznych dla dostawcy. W interfejsie, jeśli to możliwe, należy używać języka neutralnego dla dostawcy – na przykład w przypadku zmian lub żądań ściągnięcia i łączenia – jednocześnie pokazując oryginalną terminologię i łącze, gdy użytkownik sprawdza rekord.
Traktuj wskaźniki recenzji jako zależne od zasięgu
Zmiana mogła wymagać recenzentów bez zakończonego zdarzenia recenzji, komentarzy od botów, zatwierdzeń, które są później odrzucane, lub zdarzeń dyskusji, które nie są wyraźnie mapowane pomiędzy interfejsami API. Zdefiniuj pierwszy przegląd jako znaczący przegląd dokonany przez człowieka po przygotowaniu zmiany, a następnie zapisz zastosowane dowody i typ zdarzenia. Konsekwentnie wykluczaj znane boty. Opublikuj, ile zmian ma wymierne dane dotyczące recenzji. Porównanie median dostawców bez porównywalnego zasięgu zdarzeń może dać precyzyjnie wyglądający, ale fałszywy wniosek.
Koncepcje planowania mapy celowo
Iteracje GitLab często należą do grup rytmu i reprezentują datowane okno dostawy. Kamienie milowe stanowią odrębną koncepcję i mogą opisywać wydania lub szersze cele. Kamienie milowe GitHub mogą zapewniać okno planowania, a zachowania przypominające sprint mogą znajdować się w projektach lub etykietach. Nie zmieniaj nazwy każdego kamienia milowego na iterację ani nie wnioskuj o zespole na podstawie daty. Przechowuj typ dostawcy, tytuł, daty, nadrzędną kadencję lub projekt i źródłowy adres URL. Oferuj oddzielne filtry, gdy koncepcje obsługują różne pytania związane z zarządzaniem.
Porównuj decyzje, a nie liczbę funkcji dostawcy
Raportowanie między dostawcami jest najbardziej przydatne, gdy odpowiada na wspólne pytanie: gdzie rośnie liczba oczekujących na recenzję? Które strumienie pracy się zmieniają? Gdzie koncentruje się własność? Przed porównaniem zastosuj to samo okno czasowe, zakres repozytorium, zasady botów i dopasowanie tożsamości. Pokaż zasięg każdego dostawcy i pozwól użytkownikom zagłębić się w źródło. Celem nie jest szybsze zadeklarowanie jednej platformy; polega na zapewnieniu organizacji składającej się z wielu dostawców jednego spójnego stanowiska, przy jednoczesnym poszanowaniu semantyki, która sprawia, że dowody są godne zaufania.
Zobacz wyraźnie swój system dostawy.
Poznaj przypominającą produkcję przestrzeń roboczą Troodo i zobacz, jak dowody dostawy stają się szczegółowymi wytycznymi kierownictwa.
Zapoznaj się z demonstracją na żywo