Kiedy należy zacząć korzystać z kolejnej wersji narzędzia podczas karmienia psów?

W szczególności pracuję nad narzędziem, które integruje DVCS i system kompilacji, ale wydaje mi się, że wyzwanie, przed którym stoję, pojawi się dla każdego, kto opracuje narzędzie „meta” (kompilator, VCS, system kompilacji, tester itp.), chcą rozwijać się poprzez „karmę dla psów” .

Moje pytanie brzmi: w procesie wydania w stylu Scrum z wykorzystaniem rozgałęzionego przepływu pracy , w którym momencie zacznę używać nowszej wersji narzędzia w cyklu rozwoju narzędzia?

Szukam procesu, aby stworzyć równowagę między:

• stale używam developwersji tego narzędzia: odkrywam, że wprowadzam zmiany w swoim rozwoju.

• stale korzystaj z masterwersji narzędzia: wszelkie problemy, które odkryłem podczas karmienia psów, są już rozwiązane.

Pierwszą rzeczą do zrobienia są bardzo dokładne automatyczne testy regresji offline. Spraw, aby zaliczenie tych testów było minimalnym wymogiem dla tego, czego oficjalnie używasz.

Po drugie, potrzebujesz śmiertelnie prostego sposobu na powrót do poprzedniej działającej wersji, w przypadku problemów, których nie wykryły twoje automatyczne testy.

Na przykład moje jądro Linuksa było przez jakiś czas łatane. Łatałem i kompilowałem jądro na tym samym komputerze, na którym zamierzałem go używać, co oznaczało, że mogłem stracić środowisko programistyczne, jeśli utworzyłem wadliwe jądro. Dlatego zawsze starałem się zachować znane dobre jądro w moim menu GRUB, więc jeśli popełniłem błąd, wróciłem do dobrego środowiska programistycznego z prostym restartem.

Koordynacja tego z zespołem jest trudna, ale przypuszczam, że w większości chodzi o to, by pozwolić komukolwiek zainicjować awarię i podać przyczyny. W kontroli wersji jednym ze sposobów na oznaczenie tego byłoby coś w rodzaju last_known_goodgałęzi, gdzieś pomiędzy developi masterw twoim przepływie pracy. Nic nie zostanie tam popchnięte, dopóki nie uda ci się nakarmić kompilacji.

Jeśli to narzędzie jest używane do tworzenia oprogramowania o jakości produkcyjnej (szczególnie jeśli jest używane rekurencyjnie, tj. Do samodzielnego rozwijania się), zwiększyłbym twoje wstępne wysiłki testowe i czekałem na dogfooding, aż wydanie będzie wystarczająco stabilne, abyś był całkiem pewny, że nie złamiesz kodu produkcyjnego, używając go.

Jeśli musisz poczekać, aż wersja główna uzyska ten poziom pewności, niech tak będzie.

Git jest również takim narzędziem i oczywiście również karmi dla psów. Ale robi to w różnym stopniu w różnych środowiskach. Publiczne serwery działają tylko w wersji, podczas gdy programiści zwykle pracują albo z next(to nazwa projektu git dla „rozwijania”) albo pu(jeszcze bardziej rozwijają niż rozwijają). Każdy programista, który jest zablokowany przez jakiś problem może wrócić do nextlub masterlub ostatniej wersji, gdy są one blokowane przez coś, a głównym repozytorium nie jest naruszona, więc problemy mogą być czyszczone, odwołując się do niego.

Model rozgałęziający jest podobny do powyższego z nieco innymi nazwami. masterjest to, z czego wykonywane są duże wydania, maintjest gałąź wydania dla następnego wydania punktowego, nextjest podobny do rozwijania z niewielką różnicą, że funkcje mogą być scalone w celu opanowania osobno po przejściu do następnego, zamiast całego następnego.

Jest dodatkowy oddział, pu. Jest to tworzone przez połączenie wszystkich gałęzi funkcji, które są rozważane do integracji next(gałąź jest odrzucana i odtwarzana za każdym razem). IIRC jest publikowany tylko wtedy, gdy przejdzie pakiet testowy. Ostatnio patrzyłem, że Junio, opiekun, uruchamiał skrypty, aby regularnie budować je ręcznie, ale takie skrypty można uruchamiać przez ciągłą integrację co noc i uważam, że Gerrit nawet tworzy je automatycznie.

Tak więc jest to odpowiedź. Dogfoodujesz największą wersję programistyczną, którą masz w środowiskach programistycznych, ale korzystasz z poprzedniej wersji do tworzenia wersji.

W oparciu o zaakceptowaną odpowiedź zamierzam rozwinąć przepływ pracy rozgałęziania, aby zachować gałęzie podobne do następujących:

• master: łączy się z release-*chwilą zamknięcia
• dogfood: oddziały z master; zawiera poprawki zidentyfikowane podczas karmienia psów; łączy się z momentem, developgdy oprogramowanie zostanie uznane za „stabilne” do użytku wewnętrznego; w razie potrzeby głowa tego oddziału może zostać cofnięta w czasie
• develop: oddziały z master; obejmuje bieżące zmiany, poprawki błędów oraz połączenia dogfoodi feature-*gałęzie
• feature-*: oddziały z develop; zawiera zmiany dla konkretnej nowej funkcji
• release-*: rozgałęzienia od dogfoodmomentu, gdy oprogramowanie zostanie uznane za „stabilne” do użytku zewnętrznego; zawiera aktualizacje dokumentacji i drobne poprawki błędów przed połączeniemmaster