Zalecany proces recenzji kodu za pomocą rtęci

Zazwyczaj korzystaliśmy z Perforce i SmartBear's Code Collaborator, Big Corpa teraz będziemy również używać Mercurial do niektórych projektów.

Code Collaborator obsługuje Mercurial (używamy wersji 5) i staram się ustalić, kiedy najlepszy czas (podczas procesu zatwierdzania / przekazywania do serwera) jest najlepszy / efektywny czas na sprawdzenie kodu

dzięki

Ostatnio przeszliśmy prawie dokładnie to samo w mojej firmie. Oto co zrobiliśmy:

• Przechowujemy centralną ostateczną kopię wszystkich naszych repozytoriów na jednym serwerze. Gdy programiści chcą „wypisać” kod, przechodzą do tego serwera i klonują go z repozytoriów. Podobnie, gdy cykl programowania zostanie zakończony, kod jest również wypychany do odpowiedniego repozytorium.

• Oddzielamy repozytoria stabilne od repozytoriów programistycznych . Wymagamy sprawdzenia kodu przed wypchnięciem go do stabilnego repozytorium. (Jest to znaczące, ponieważ wymagamy również, aby nasze stabilne repozytoria zawierały kod, który jest obecnie uruchomiony w produkcji, różniąc się jedynie oczekującymi promocjami kodu).

Aby wymusić weryfikację kodu, napisaliśmy pretxnchangegrouphaczyk (udokumentowany w HG Book ). Wykorzystujemy fakt, że po uruchomieniu tego haka, repozytorium może widzieć repozytorium tak, jakby zmiany kodu były trwałe, ale daje nam również możliwość zapobiegania wypychaniu. Zasadniczo proces wygląda następująco:

1. Deweloper inicjuje wypychanie do stabilnego repozytorium (tak, to naprawdę pierwszy krok)
2. Hak działa i pobiera listę wszystkich zestawów zmian zawartych w transakcji (uruchamiając dziennik HG). Następnie wysyła zapytanie do bazy danych, którą zbudowaliśmy, aby sprawdzić, czy te zestawy zmian zostały uwzględnione w przeglądzie kodu. (Tabela pasuje do skrótu zestawu zmian z identyfikatorem recenzji kodu).
   • Jeśli po raz pierwszy zaobserwowano którykolwiek z tych zestawów zmian, tworzymy nowy Przegląd kodu (przy użyciu wiersza polecenia Code Collaborator), a następnie zapisujemy te zestawy zmian w bazie danych z identyfikatorem przeglądu kodu.
   • Jeśli widzieliśmy niektóre (ale nie wszystkie) zestawy zmian, uruchamiamy polecenie (Code Collaborator), aby dołączyć nowe zestawy zmian do istniejącej recenzji i zapisać te nowe zestawy zmian w bazie danych.
   • Jeśli wszystkie zmiany zostały znalezione w bazie danych (tj. Wszystkie zostały dodane do recenzji kodu), sprawdzamy, czy status recenzji kodu jest zakończony. Jeśli jednak pojawią się jakieś nowe zestawy zmian (lub przegląd kodu nie jest zakończony), hak kończy działanie z niezerowym kodem stanu (powodując wycofanie transakcji przez Mercurial) i wyświetla przyjazny komunikat o błędzie standardowym wyjaśniający deweloperowi że przegląd kodu musi zostać zakończony.

W gruncie rzeczy zapewnia to deweloperowi całkiem usprawniony proces (wystarczy, że pchnie hg) i całkowicie zautomatyzuje tworzenie recenzji kodu (i przesyłanie dodatkowych zmienionych plików do recenzji), zapewniając jednocześnie, że cały kod zostanie sprawdzony .

Uwaga: Jest to dość prosty proces (i stosunkowo nowy dla nas), więc może nie działać dla wszystkich i mogą występować pewne błędy projektowe, na które jeszcze nie natrafiliśmy. Ale do tej pory działało całkiem nieźle.

To zależy od tego, jak masz strukturę repozytorium i co próbujesz osiągnąć. Wolimy robić recenzje „przed zatwierdzeniem”, co w świecie DVCS naprawdę oznacza „wstępne zatwierdzenie”. DVCS są ładniejsze w tym środowisku (w porównaniu do tradycyjnych SCM), ponieważ mają wbudowaną funkcję zapisywania lokalnych zmian i przywracania przestrzeni roboczej, dzięki czemu możesz pracować nad czymś innym.

Jeśli chcesz zrobić recenzje po wypchnięciu, idealny przepływ pracy zależy w dużej mierze od struktury repozytorium. Załóżmy na przykład, że struktura repozytorium wygląda jak ta omówiona w tym artykule na temat układów repozytorium Git . W takim przypadku możesz przejrzeć zmiany, które są scalane develop. Poszczególne zatwierdzenia w gałęziach funkcji mogą nie mieć sensu sprawdzać. Oczywiście wszystkie hotfixesmuszą zostać również przejrzane wraz z połączeniami master.

Jeśli zamiast tego masz jedną gałąź integracji, w której ludzie meldują się bezpośrednio, powinieneś przejrzeć wszystkie wypychania do tej gałęzi. Jest to prawdopodobnie nieco mniej wydajne, ale może nadal działać. W tym środowisku należy upewnić się, że wszystkie wprowadzone zmiany zostały przejrzane przed wycięciem wersji. To może być trudniejsze.

Co do b) jedyne, co sugerowałbym, to bezpośrednie wysłanie e-maila do pomocy technicznej SmartBear (support@smartbear.com). Będziemy (tak, pracuję dla SmartBear) chętnie pomożemy Ci rozwiązać problemy ze ścieżką, ale w tym pytaniu nie ma wystarczających informacji, aby rozwiązać problem. Normalnym procesem jest po prostu uruchomienie instalatora i wszystko po prostu działa. Najwyraźniej coś poszło nie tak w tym procesie.