Korzystanie z testowania gałęzi w Git

Mamy kogoś (nazwijmy go Ted), który jest odpowiedzialny za testowanie nowych funkcji i poprawek błędów.

Używamy Git i GitHub . masterpowinno być / jest zawsze możliwe do wdrożenia i developmenttam, gdzie zatwierdzamy / łączymy nowe funkcje lub poprawki błędów, ale dopiero po ich przetestowaniu przez Ted.

Projekt jest w języku PHP.

Chciałbym, aby proces testowania przebiegał tak:

1. Deweloper chce pracować nad nową funkcją (powiedzmy funkcja / błąd nr 123, jak Ted udokumentował w narzędziu do śledzenia problemów), więc przyciąga się origin/developmentdo developmentswojego lokalnego repozytorium i tworzy od tego miejsca nową gałąź (powiedzmy issue-123).
2. Kiedy jest zadowolony ze swojej pracy, zobowiązuje się i przenosi swój nowy oddział do origin.
3. Ted łączy się test.ourproject.com/choose-branchz listą rozgałęzień i widzi, że originje włącza issue-123(powinno to być możliwe za pośrednictwem strony internetowej). Następnie kontynuuje test.ourproject.comtestowanie aplikacji internetowej (jest naprawdę bezlitosny), a po kilku rozmowach z deweloperem jest zadowolony z tej funkcji.
4. Ted mówi deweloper, który potrafi scalić issue-123na developmentna origin.
5. Wypłukać i powtórzyć.

W trzecim kroku mogłem zhakować coś, co wykonuje zadanie (wyświetlanie i przełączanie gałęzi z określonej strony), ale wydaje mi się, że to, co opisałem, jest bardzo powszechnym wzorcem.

Więc moje pytanie brzmi: czy jest to dobry / zrównoważony / możliwy do utrzymania przepływ pracy dla rozgałęzień? Czy możesz wykonać kopię zapasową swojej odpowiedzi, przytaczając przykłady innych projektów po tym przepływie pracy?

Przepływ pracy w oddziale przypomina bardzo gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow, a wokół niego znajdują się narzędzia wsparcia. Jest wysoce zalecane.

Jeśli jest tylko jeden tester, przepływ pracy podczas testowania brzmi dobrze, ale jeśli jest wiele osób, programowanie może przebiegać od początku do końca, a testowanie powinno być w pełni przeprowadzone po każdym scaleniu. W tym przypadku automatyczne testowanie może naprawdę pomóc lub powolny (dokładny) tester może nigdy się nie skończyć!

Innym problemem jest to, że w przypadku wielu funkcji i gałęzi staje się kuszące, aby mieszać i dopasowywać funkcje do wydania (lub wybrać eksmisję po zaakceptowaniu i scaleniu) lub być może jeśli funkcje są od siebie zależne. Problem polega na tym, że zaczniesz mieć ochotę przepisać historię (zmienić bazę / usunąć zatwierdzenie lub scalić) w PUBLIKOWANEJ gałęzi, co oznacza, że ​​została wypchnięta do repozytorium wielodeviewnego. To przepisywanie historii publicznej. Można tego dokonać dla dobra lub zła, a nawet jeśli dla dobra może powodować problemy nieostrożnym, a najlepszą praktyką jest unikanie go, aby pytanie nigdy nie pojawiło się. Jednak niektóre przepływy pracy gałęzi integracji sprawiają, że jest to bardzo kuszące, więc jeśli masz silną ochronę takich gałęzi (np. Gitolite na ograniczenia gałęzi użytkownika) i ludzie oczekują takiej aktywności, więc zawsze bazuj kod na takiej gałęzi, kontynuuj - ostrożnie!

Chciałbym również polecić przeczytanie http://sethrobertson.github.com/GitBestPractices/, który omawia wszystkie te kwestie i ma wiele dobrych referencji.

Nie jestem pewien, czy sama strona przełączania jest częstym wzorcem. W większości projektów prawdopodobnie tester sprawdza to po prostu za pomocą polecenia git.

Ogólne podejście zdecydowanie brzmi rozsądnie.

Google napisał nawet Gerrit, aby wspierać podobny styl; chodzi bardziej o sprawdzenie kodu, ale zatwierdzenie integracji zwykle obejmuje zarówno sprawdzenie, jak i przetestowanie. Zwykle jest on również połączony z serwerem ciągłej integracji, który najpierw tworzy wszystkie zgłoszenia (nie jestem pewien, czy używają Jenkins w Google, ale wydaje mi się, że gdzieś widziałem odpowiednie złącza).

Sam Git używa niewielkich zmian w temacie. Jego opiekun ma skrypt, który scala wszystkie oczekujące zgłoszenia w gałęzi o nazwie pu(przypuszczalnie w przypadku „proponowanych aktualizacji”; gałąź jest usuwana i ponownie tworzona za każdym razem, ponieważ oczekujące zgłoszenia są często zmieniane). Jest to następnie testowane przez różne osoby. Jeśli wszystko jest w porządku, zgłoszenia przesłane jako kompletne zostaną scalone next(to samo co twoje development). Jeśli nie, to ktoś testuje poszczególne zgłoszenia, aby zobaczyć, które z nich jest zepsute. Ułatwia to testerowi, ponieważ przez większość czasu nie muszą oni zmieniać gałęzi; po prostu informują, czy integracja testowa działa.

Jeśli testowanie odbywa się automatycznie, a nie ręcznie, myślę, że Travis (system CI dla GitHub) zrobi wszystko, co chcesz - automatycznie uruchamia testy dla wszystkich żądań ściągania. ( Więcej informacji o tym procesie, w tym zrzuty ekranu ).

Zauważ, że testy nie są uruchamiane na gałęzi, ale na gałęzi po scaleniu w master. (tzn. co uzyskasz po scaleniu gałęzi w master - masz gwarancję, że testy będą nadal działały poprawnie po scaleniu).

Jeśli do oddziału zostaną dodane zatwierdzenia, testy zostaną ponownie uruchomione. (Chociaż z jakiegoś powodu dodanie zatwierdzeń do wzorca nie wydaje się ponownie uruchamiać testów.)