Zalecany proces recenzji kodu za pomocą rtęci


18

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


Prawdopodobnie powinieneś rozdzielić dwa pytania. (a) należy tutaj, ale (b) prawdopodobnie należałby do stackoverflow lub serverfault
blueberryfields

Dzięki @blueberryfields. Naprawdę naprawiłem problem, problem polegał na tym, że plik bin / hg.cmd znajdował się na ścieżce i nie ma exe.
cbrulak

Odpowiedzi:


22

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.


Czy wyjaśniłbyś swoją decyzję o sprawdzeniu w stabilnym środowisku przed przeglądem kodu? Dla mnie stabilny wydaje się być mylącym.
Jordan

1
Odpowiedź prawdopodobnie nie była jednoznaczna, ale tak naprawdę nie trafia do repozytorium, chyba że wszystkie zmiany zostały dodane do recenzji kodu i przegląd jest kompletny. Jeśli hak kończy działanie z niezerowym kodem wyjścia, Mercurial wycofuje wszystkie zmiany, które zostały wprowadzone. Tak więc ten konkretny haczyk zapewnia bardzo wygodne miejsce nie tylko do uzyskania różnic do recenzji, ale także do egzekwowania recenzji, zanim zmiany zostaną dopuszczone do repozytorium.
Ryan

1
Łał. Czy mogę przyjść dla ciebie pracować?
Rich

@Ryan - Jak zaimplementować hook pretxnchangegroup, podany przez ciebie link nie zawiera szczegółowych wyjaśnień na temat tego, jak można go zaimplementować, nie podaje rodzaju szablonu funkcji, za którym powinniśmy podążać, gdzie umieścić zaczep. Nie mam doświadczenia w Pythonie. Czy możesz przekierować mnie do właściwego źródła lub szablonu haka pretxnchangegroup. Ta
Simple-Solution

2

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.