Jak utrzymać stabilność pnia, gdy testy trwają długo?

Mamy trzy zestawy pakietów testowych:

• „Mały” apartament, którego uruchomienie zajmuje tylko kilka godzin
• „Średni” apartament, który zajmuje wiele godzin, zwykle jest uruchamiany co noc (co noc)
• „Duży” pakiet, którego uruchomienie zajmuje tydzień +

Mamy też kilka krótszych pakietów testowych, ale nie skupiam się na nich tutaj.

Obecna metodologia polega na uruchomieniu małego pakietu przed każdym zatwierdzeniem do pnia. Następnie średni zestaw uruchamia się każdej nocy, a jeśli rano okaże się, że się nie udało, staramy się ustalić, które z wczorajszych zobowiązań było winne, wycofać się z zatwierdzenia i ponowić testy. Podobny proces, tylko co tydzień zamiast co noc, odbywa się w przypadku dużego zestawu.

Niestety średni zestaw dość często zawodzi. Oznacza to, że pień jest często niestabilny, co jest bardzo denerwujące, gdy chcesz wprowadzić modyfikacje i przetestować je. Jest to denerwujące, ponieważ kiedy wymeldowuję się z bagażnika, nie jestem pewien, czy jest stabilny, a jeśli test się nie powiedzie, nie jestem pewien, czy to moja wina, czy nie.

Moje pytanie brzmi: czy istnieje jakaś znana metodologia radzenia sobie z tego rodzaju sytuacjami w sposób, który sprawi, że bagażnik będzie zawsze w najlepszym stanie? np. „zatwierdzanie w specjalnej gałęzi przedwstępnej, która następnie okresowo aktualizuje pień za każdym razem, gdy noc przechodzi”.

I czy ma to znaczenie, czy jest to scentralizowany system kontroli źródła, taki jak SVN, czy rozproszony, jak git?

Nawiasem mówiąc, jestem młodszym programistą z ograniczoną zdolnością do zmiany rzeczy, po prostu próbuję zrozumieć, czy istnieje sposób na poradzenie sobie z tym bólem, którego doświadczam.

Jedynym sposobem naprawienia pierwotnej przyczyny niestabilności jest oddzielenie kodu, aby zmiany były bardziej izolowane, jak sugerują inne odpowiedzi.

Jednak jako indywidualny programista, jeśli chcesz bardziej stabilną kompilację, na której możesz osobiście pracować, jest to stosunkowo łatwe do rozwiązania. Zamiast pracować z końcówką, wyciągasz tylko ostatnią kompilację, która przekazała zestaw testów na noc do twojego drzewa roboczego. Jeśli możesz utworzyć gałęzie funkcji dla każdej zmiany, odejdź od ostatniej stabilnej wersji.

Tak, twoje drzewo będzie kilka dni w tyle, ale przez większość czasu to nie ma znaczenia. Wykonuj swoją pracę w stosunku do stabilnej wersji, abyś wiedział, że twoje zmiany przełamały wszelkie testy, a następnie, zanim się zalogujesz, zaktualizuj do najnowszej wersji i wykonaj normalną integrację. Następnie po odprawie wróć do ostatniej stabilnej wersji.

Nadal musisz wykonać nieporządną pracę integracyjną, ale to, co podoba mi się w tej metodzie, to to, że izoluje pracę integracyjną na czas bardziej dogodny dla mnie i daje mi stabilną bazę kodu do programowania, gdy nie jest to wygodne. Mam o wiele lepszy pomysł, kiedy moje zmiany prawdopodobnie złamały kompilację w porównaniu do czyjejś innej.

Wiem, że próbujesz tego uniknąć, ale prawdziwy wgląd tutaj polega na uświadomieniu sobie, że coś jest nie tak z twoją bazą kodu: musisz uruchomić pełny zestaw testów, który zajmie tydzień, aby upewnić się, że kod jest stabilny!

Najkorzystniejszym sposobem rozwiązania tego problemu jest rozpoczęcie rozdzielania bazy kodu i testów na (niezależne) podjednostki.
Są to ogromne zalety:

• Testy dla każdej z tych jednostek będą przebiegały szybciej (jest ich po prostu mniej) i nie ulegną one przerwaniu, jeśli coś pójdzie nie tak w jednej z niezależnych lub dalszych jednostek.
• Nieudany test zostanie wskazany na konkretnej jednostce, co znacznie ułatwi znalezienie źródła problemu.
• Możesz oddzielić lokalizacje VCS różnych jednostek, tak aby gałąź „stabilna” mogła być połączeniem najnowszej pomyślnie przetestowanej wersji każdej jednostki, tak aby jedna lub dwie uszkodzone jednostki nie zdestabilizowały twojej „stabilnej” wersji .

Z drugiej strony zarządzanie strukturą VCS stanie się bardziej skomplikowane, ale za cały tydzień pełnego testu, myślę, że możesz znieść ból!

Nadal zalecam stosowanie strategii gałęzi „stabilnej” i „programistycznej” w takiej lub innej formie, ale istnieje wiele sposobów, aby to zrobić i możesz wybrać ten, który najlepiej pasuje do Twojej organizacji (meta-repozytoria ze stałymi poprawkami wskazującymi na osobne repozytoria dla każdej jednostki, gałąź stabilna i gałąź programistów, gałęzie funkcji ....)

W przypadku SVN nie wiem o czymś takim, jak „wstępne zatwierdzenie”. Myślę, że prawdopodobnie spowoduje to zatwierdzenie i wycofanie, gdy test się nie powiedzie. Jak mówi doc-brown, jedynym sposobem jest zatwierdzenie tymczasowej gałęzi i połączenie jej z pniem później.

Używając rozproszonego takiego jak git lub merkurial, myślę, że byłoby to możliwe. Korzystanie z repozytorium „testującego” i repozytorium „stabilnego”. Naciskasz na przedstawiciela testowego, testujesz go co noc, a jeśli wszystko działa dobrze, przesuwasz się z testu na stabilny. W przeciwnym razie wycofasz przedstawiciela testującego. Nie jestem pewien, jak wyglądałaby historia wersji, kiedy przechodzisz od testowania do stabilnego, ale myślę, że można w ten sposób wykluczyć zepsute wycofane elementy. Najpierw najbezpieczniej byłoby trochę poeksperymentować.

Alternatywą byłoby również przetestowanie lokalnego bagażnika każdej osoby co noc. Następnie osoby, które przeszły pomyślnie testy, mogą wypchnąć go rano na serwer centralny.

IMHO nie ma to nic wspólnego z używanym VCS. Użycie „testowanego” oddziału może być rozwiązaniem, które można zrealizować również za pomocą scentralizowanego lub rozproszonego VCS. Ale szczerze mówiąc, myślę, że najlepszą rzeczą w twojej sytuacji jest próba zoptymalizowania średniego zestawu testów (wydaje się, że zawiera najważniejsze testy), aby działał znacznie szybciej, więc możesz go użyć do pre-commit-to-trunk testy, tak jak robisz to teraz z „małym pakietem”.

Testy średnich testów: Czy to prawda, że ​​w większości przypadków te same testy kończą się niepowodzeniem?

Jeśli wystąpi awaria, czy zawsze występują te same powiązane testy, które zawodzą?

Jeśli prawda: możliwe, że możesz selektywnie wybrać niektóre średnie testy, które często kończą się niepowodzeniem (jeden test dla każdej klasy błędu) i wykonać je w małym zestawie.

Czy większość testów-testów integracyjnych wykorzystujących prawdziwą bazę danych? Jeśli tak, to czy można je zastąpić najbardziej nieprzystosowanym, który ma próbną bazę danych?

Musisz przyspieszyć testy, nie ma innego sposobu na wyprostowanie tego koła.

Rozważ problem: chcesz mieć pewność, że przy kasie masz działający kod. Jasne, możesz opóźnić zatwierdzenia i rozgałęzić się przed wydaniem, ale opóźni to początek problemu do momentu integracji. Czy po każdym fuzji będziesz musiał uruchomić tygodniowy pakiet? Metodologia nie jest rozwiązaniem, rozwiązanie jest czysto techniczne.

Oto, co sugeruję:

1) Spraw, aby testy były jak najbardziej atmomiczne i zmaksymalizuj ponowne użycie środowiska.

2) Uzyskaj farmę z pakietem testów, aby je uruchomić. Jeśli zamiast 8 dużych modułów uzyskasz 50, możesz rozdzielić kilka instancji spotów Amazon EC2 i uruchomić cały pakiet równolegle. Jestem pewien, że będzie to kosztowało trochę pieniędzy, ale pozwoli zaoszczędzić ogromne ilości czasu programisty.

Kluczową rzeczą, którą bierzesz za oczywistość w swoim pytaniu, jest to, że wszystkie zatwierdzenia muszą przejść testy. Chociaż jest to miła zasada do naśladowania i wydaje się, że ma to jakiś sens, czasami nie jest praktyczna. Twój przypadek jest przykładem (chociaż MadKeithV ma rację) i mogę sobie wyobrazić utrzymanie oddziału VCS tak nieskazitelnego, co może być trudne, jeśli nie będzie wystarczającej współpracy między devloperami.

W rzeczywistości to, co chcesz, to dowiedzieć się, które zatwierdzenia kończą się pomyślnie. Jak sugerowałeś, gałąź „wstępnie zatwierdzająca” działałaby, ale może wymagać dodatkowego wysiłku ze strony programistów, którzy dokonują zatwierdzeń, co może być trudne do sprzedania.

Podobnym podejściem, które mogłoby być łatwiejsze, jest pozostawienie pnia, aby ludzie mogli złamać, jak chcą, i mieć oddział dla zatwierdzeń, które nie są zepsute. Zautomatyzowany skrypt może przechodzić przez zatwierdzenia, gdy są wykonywane do linii głównej, uruchamiać na nich testy i dodawać je do gałęzi, jeśli przejdą pomyślnie.

Lub możesz być absurdalnie uproszczony i mieć skrypt, który wyświetla zatwierdzające przekazywanie w pliku tekstowym (który może, ale nie musi, być kontrolowany w wersji).

Lub mieć system wsadowy, który przyjmuje żądania przetestowania gałęzi / wersji (z dowolnego miejsca w drzewie), i testuje je i zatwierdza do linii głównej (lub innej gałęzi), jeśli przejdą.