Zatrzymywanie programistów zobowiązujących się do niewłaściwej gałęzi DVCS

Problem

Jestem w projekcie oprogramowania, który ma około 10 programistów, udostępniamy kod źródłowy za pośrednictwem Mercurial. Posiadamy dział rozwoju i produkcji na wydanie. Wielokrotnie w trakcie projektu mieliśmy kod źródłowy z jednej gałęzi, tj. V1 wchodzącej do łatek i gałęzi serwisowych dla wcześniejszych wydań oprogramowania, tj. V2.

Powoduje to albo czas poświęcony na wycofanie niewłaściwego zatwierdzenia, albo niewłaściwy kod (prawdopodobnie nie-QAd) osiągający i wdrażany w niewłaściwej gałęzi, jeśli nie zauważymy, że kod znalazł się w niewłaściwej gałęzi.

Nasz projekt / metoda łączenia i łączenia

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

W związku z tym będziemy pracować nad gałęzią rozwoju wersji, dopóki nie zostanie uznana za gotową , należy ją rozgałęzić dla pojedynczego oddziału testującego / UAT / produkcyjnego, w którym wykonywane są wszystkie wydania i konserwacja. Tagi służą do budowania wydań tej gałęzi. Podczas testowania wersji 1 zostanie utworzona gałąź dla wersji 2, a programiści zaczną pracować nad nowymi funkcjami.

Często zdarza się, że programista podejmuje pracę z powodu rozgałęzienia v2-dev w v1-dev lub v1-prod, albo co gorsza, scala v2-dev w v1-prod (lub podobne błędy).

Mówimy większości programistów, aby nie uzyskiwali dostępu do gałęzi -prod , jednak kod wciąż się do nich wkrada. Grupa starszych programistów „opiekuje się” gałęzią -prod.

Należy zauważyć, że chociaż wersja v2 dopiero zaczęła opracowywać, nadal mogą pojawiać się całkiem spore łatki do wersji 1, aby naprawić problemy. Tj. V1 może nie tylko otrzymywać dziwną małą łatkę.

Co próbowaliśmy do tej pory

• Posiadanie osobnego oddziału-produktu z strażnikami. Oddział -produkt powinien wywoływać ostrzeżenia poprzez swoją nazwę, a większość programistów nie musi nigdy być w tej gałęzi. To tak naprawdę nie zmniejszyło problemu.
• Podniesiono świadomość tego problemu wśród programistów, aby zwiększyć ich czujność. Ponownie nie było to bardzo udane.

Widzę możliwe powody, dla których programiści wybierają niewłaściwy oddział

• Zbyt skomplikowany projekt gałęzi
• Aktywny rozwój w wielu gałęziach równolegle. (Projekt wykazuje objawy używania modelu lawinowego ).
• Programiści nie rozumieją DVCS wystarczająco dobrze

Pytania, które przeczytałem, były dość istotne

Przeczytałem to pytanie o tym, czy nie popełniłem niewłaściwej gałęzi, i uważam, że odpowiedzi dotyczące wskazówek wizualnych mogą być pomocne. Nie jestem jednak do końca przekonany, że napotykane przez nas problemy nie są objawami bardziej fundamentalnego problemu.

Dzięki wskazówkom wizualnym możemy łatwo włączyć je do linii poleceń, jednak około połowa zespołu używa zaćmień, co do których nie jestem pewien, jak zastosować wskazówki wizualne.

Pytanie

Jakich metod, w postaci oprogramowania, zarządzania projektami lub zarządzania, możemy użyć do ograniczenia (najlepiej zatrzymania) zatwierdzeń do niewłaściwej gałęzi, zajmując nam czas lub usuwając wdrożony kod?

Doceniony zostanie konkretny komentarz na temat przyczyn, które moim zdaniem mogą wnieść swój wkład, jak opisano powyżej, ale nie powinno to ograniczać twojej odpowiedzi.

Problem polega na tym, że zmieniasz znaczenie gałęzi w trakcie całego procesu.

Początkowo v1 devgałąź jest przeznaczona na rozwój. Wszystkie nowe funkcje są dostępne. W pewnym momencie w przyszłości stanie się oddziałem utrzymania dla v1 releaseoddziału. To jest sedno problemu.

Nie chodzi o to, że programiści są niechlujni, ale uprawnienia i role oddziału są niechlujne i mogą ulec zmianie.

To, co musisz zrobić, to ustalić rolę każdej gałęzi i utrzymać tę rolę. Jeśli rola ulegnie zmianie, gałąź.

Na przykład:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

W tym modelu programiści zawsze zobowiązują się do tworzenia. Jeśli budujesz łatkę, sprawdzasz łatkę w gałęzi tego wydania (lub jeszcze lepiej, rozgałęziasz gałąź wydania dla łatki, a następnie scalasz ją z powrotem z gałęzią wydania).

Jednym z artykułów, który powinieneś przeczytać (i prawdopodobnie jest to mało powiedziane dla „powinien”), są Zaawansowane Strategie Rozgałęziania SCM autorstwa Stephena Vance'a.

^{W tym artykule najpierw definiuję rozgałęzienia w sensie ogólnym. Następnie omawiam różne strategie rozgałęziania, zaczynając od oczywistych i przechodząc do kilku, które są bardziej odpowiednie dla większych wysiłków rozwojowych. Po drodze omawiam zalety i wady każdej strategii, używając ich do motywowania zmian, które składają się na bardziej złożone strategie ...}

W tym artykule wskazuje pięć ról, które mogą odgrywać oddziały. Czasami gałąź może pełnić dwie role, a role niekoniecznie potrzebują nowej gałęzi, o ile zasady ról nie zmieniają się w połowie gałęzi (czasami pojawia się wzmianka o „gałęzi o niezgodnych zasadach”).

Te role to:

1. Mainline. To tutaj powstają gałęzie. Zawsze rozgałęzienie od linii głównej ułatwia łączenie, ponieważ dwie gałęzie będą miały wspólnego przodka, który nie będzie rozgałęzieniem po rozgałęzieniu.
2. Rozwój. To tutaj programiści sprawdzają kod. Można mieć wiele gałęzi programistycznych, aby odizolować zmiany wysokiego ryzyka od rutynowych i przyziemnych.
3. Konserwacja. Poprawki błędów w istniejącym środowisku produkcyjnym.
4. Akumulacja. Łącząc dwie gałęzie, nie można ryzykować destabilizacji linii głównej. Więc rozgałęzić linię główną, połączyć gałęzie z akumulatorem i połączyć z powrotem z linią główną, gdy wszystko zostanie ustalone.
5. Opakowanie Pakowanie jest wydawane w branżach opakowań. Często staje się to wersją i służy do izolowania wysiłków związanych z wydaniem od rozwoju. Zobacz Jak radzić sobie z niepożądanymi zatwierdzeniami, które przerywają kompilacje wersji długo działających? na przykład, gdzie opakowanie jest sprzeczne z rozwojem.

W twoim przykładzie masz kaskadową linię główną (jest to problem - utrudnia to scalanie - co się stanie, jeśli chcesz scalić poprawkę dla v1 z v2 i v3?), Gałąź deweloperska, która staje się gałęzią utrzymania ( zmiana zasad, to jest problem).

Ok, mówisz, to świetnie, ale napisano to dla perforce, która jest scentralizowanym VCS - używam DVCS.

Przyjrzyjmy się modelowi git-flow i zobaczmy, jak ma on zastosowanie.

Gałąź główna (niebieska) to gałąź wydania - do oznaczania. To nie jest główna linia. Linia główna to właściwie gałąź rozwoju (żółta). Gałęzie wydania (zielone) pełnią rolę opakowania. Rozwój niskiego ryzyka odbywa się w linii głównej, rozwój wysokiego ryzyka występuje w gałęziach funkcji (różowy). W tym modelu akumulacja odbywa się w gałęzi developerskiej. Konserwacja jest uważana za „poprawkę”, która jest czerwona.

Chociaż zasady ról nie są dokładnie dopasowane (każdy produkt ma swój nieco inny cykl życia), są takie same.

Powinno to uprościć zasady rozgałęziania i ułatwić wszystkim zaangażowanym.

Podczas gdy próbowałeś użyć osobnej gałęzi -prod z gatekeepers, brzmi to tak, jakby jedno repozytorium było używane do wykonywania kompilacji produkcyjnych. Gdyby kompilacje produkcyjne były wykonywane tylko z repozytorium produkcyjnego, zapisywalnego tylko przez strażnika, deweloperzy nie byliby w stanie do niego naciskać. To obciąża strażnika, który naciska na repozytorium produkcyjne dopiero po sprawdzeniu. Oczywiście ludzie nadal będą mogli korzystać z repozytorium produkcyjnego w razie potrzeby.

Gdy ludzie zdobywają doświadczenie, należy je zmieniać w roli strażnika, aby uzyskać głębsze zrozumienie lub troskę, której im brakuje.

I z reguły stosuj Razor Razor: cała struktura repo powinna być tak prosta, jak to możliwe, aby wykonać swoje zadanie.

Zobacz także komentarz Seana.

Możliwe, że deweloperzy po prostu nie dostają DVCS wystarczająco dobrze, ale myślę, że jest o wiele bardziej prawdopodobne, że po prostu dzieje się za dużo, a deweloperzy nie mogą śledzić tego, co robią z chwili na chwilę. Zapominają, w jakiej branży mają pracować, a ich zmiany kończą się w niewłaściwym miejscu.

Sugeruję, że masz problem z tym, że wszyscy pracują regularnie we wszystkich tych branżach.

@ Sugestia @ andy256 dotycząca oddzielnego repozytorium dla prod z pewnością by pomogła, ale może być konieczne rozważenie paczkowania pracy w inny sposób, a może aranżowania rzeczy tak, aby żaden programista nie pracował w więcej niż jednej gałęzi w danym tygodniu.

Wygląda na to, że zidentyfikowałeś jednego z moich głównych niedźwiedzi. Większość narzędzi kontroli źródła to właśnie narzędzia kontroli źródła. Umożliwiają grupie programistów pracę nad tym samym katalogiem źródłowym, wprowadzanie zmian i rozwiązywanie konfliktów. Po drodze pojawiło się kilka ostrych krawędzi, ale cvs, subversion, git, mercural itp. Wszystko to zapewniają.

Następnie masz następny krok, kiedy musisz ustabilizować kod do wydania i wprowadzasz rozgałęzienie. To tutaj narzędzia zaczynają zawodzić programistów. Narzędzia są w stanie utworzyć gałąź, a nawet zidentyfikować zestawy zmian, które pojawiły się w gałęziach po ich rozgałęzieniu, ale nie jest to problem, z którym się teraz spotkałeś.

Narzędzia naprawdę słabo wybierają, które zmiany należy skopiować do innych gałęzi i kiedy to musi nastąpić. Git-flow próbuje rozwiązać ten problem, tworząc strategię rozgałęziania, która oznacza, że ​​kiedy gałęzie są scalane, wszystkie WSZYSTKIE zmiany są scalane, a następnie wymaga od programisty dokonania rozsądnego wyboru, kiedy i które gałęzie zostaną scalone.

Na jednym repozytorium, w którym wszyscy programiści pracują nad jednym projektem, który ma wątek pojedynczego wydania, git flow rozwiązuje problem, ale życie wielu firm nie jest takie proste.

Złożone środowisko to miejsce, w którym masz wiele zespołów odpowiedzialnych za różne aspekty całego rozwiązania, wykonując wewnętrzne wydania dla innych zespołów. git-flow po prostu nie jest w stanie rozwiązać tego rodzaju problemu.

Jedyny sposób, w jaki widziałem tę pracę, to to, że każdy zespół jest odpowiedzialny za zdefiniowanie swoich wydań i kontrolowanie, gdy zmieniają się ich zależności. Tylko dlatego, że zespół A wypuścił wersję 1.3, zespół B zaczyna używać wersji 1.3 A, gdy drużyna B wybierze.

W efekcie zespół programistów definiuje grupy zmian, które należy przenieść, a programiści otrzymujący zmiany określają, kiedy otrzymają grupę zmian.

Jedyne narzędzie kontroli źródła, jakie widziałem, które naprawdę to zapewnia, jest dokładne - i nawet wtedy większość programistów narzeka na to, ponieważ GUI jest dla nich zbyt mylące i nie zachowuje się jak subversion ...