Jak właściwie zarządzać zatwierdzeniami, zapobiegać konfliktom funkcji i zarządzać zależnościami za pomocą VCS?

9

Stało się to irytującym czynnikiem w pracy z dużymi zespołami: jak zarządzać meldowaniami i zapobiegać konfliktom funkcji oraz odpowiednio zarządzać zależnościami z kontrolą źródła?

Obecnie w moim miejscu pracy korzystamy z TFS 2008 i migrujemy do TFS 2010 na początku grudnia. Po pierwsze, jakakolwiek kontrola źródła jest lepsza niż żadna, ale jakie podejście okazało się przydatne, aby zapobiec wielu kontrolom i cofnięciu całej historii kontroli źródła? Czy lotny pień jest najlepszym sposobem na przejście lub rozgałęzienie, gdy wdrażasz nową funkcję, a gdy będziesz szczęśliwy, wrócisz do pnia?

Naprawdę chciałbym usłyszeć doświadczenia innych ludzi i być może najlepsze praktyki zarządzania kontrolą źródła.

version-control

— Nickz
źródło

2

Możliwy duplikat programmers.stackexchange.com/questions/5540/… , programmers.stackexchange.com/questions/15730/...

— Adam Lear

3

Najlepszym rozwiązaniem, jakie znalazłem, aby poradzić sobie z TFS, było posiadanie własnego prywatnego GIT, w którym mogłem przeszukiwać wszystkie potrzebne rozgałęzienia i wykonywać zatwierdzenia TFS na drobne kamienie milowe (mała funkcja, funkcja częściowa) im mniejsze, tym lepiej, ale musisz także upewnij się, że kod jest prawidłowy podczas zatwierdzania. W jednej gałęzi na funkcję / poprawkę / iterację chciałbym zatwierdzić TFS na końcu „gałęzi”. Jednak wewnętrznie dość często mam wiele gałęzi dla różnych prób i eksploracji. Narzędzia TFS Power tutaj są całkiem przydatne do zautomatyzowania scalania z powrotem

— Newtopian

1

Więcej informacji na temat tego, co rozumiesz przez „wielokrotne meldowanie” i „naruszanie łącza”. Naprawdę mam nadzieję, że każdy z moich inżynierów robi więcej niż jedno zgłoszenie, podczas gdy członkowie mojego zespołu.

— Manfred

Strategia rozgałęziania kontroli źródła jest dużym tematem. programmers.stackexchange.com/questions/107884/…

— gnat

@John - Myślę, że „naruszenie” było literówką dla „niestabilnego”

— ChrisF

7

TFS? Biegnij na wzgórza! Odejdź tak szybko, jak to możliwe. Robi wiele różnych rzeczy, ale żadna z nich nie jest tak dobra, jak dostępne narzędzia najlepszych ras.

Ale poważnie:

Gdy masz już przyzwoity system kontroli wersji (SVN, GIT itp.), Zaleciłbym ustawienie reguł zarządzania oddziałami, np. Kiedy tworzyć oddziały, po co, kiedy łączyć, kto i wiele więcej.

Do niedawna używaliśmy jednej gałęzi do nowego rozwoju („trunk”). W celu wydania utworzymy gałąź z pnia. Ostateczna kontrola jakości zostanie przeprowadzona w tym oddziale, a po jej zakończeniu wydamy (jesteśmy w wersji miesięcznej).

Przestawiliśmy się na koncepcję „bez śmieci w bagażniku”, aby zmniejszyć ryzyko związane z harmonogramem. Ta koncepcja zasadniczo zawiera regułę, według której należy tworzyć gałęzie do prac programistycznych oddzielnie od pnia. Na przykład możesz mieć oddzielną gałąź dla funkcji, dla małego zespołu programistów lub podobnego. Używamy „epików”, aby opisać małą cechę lub dającą się uwolnić część cechy i stworzyć gałąź dla każdej epiki. Co najmniej raz dziennie wszystkie zmiany z pnia są łączone w epicką gałąź. Kluczem jest dobra obsługa scalania przez kontrolę wersji lub oddzielne narzędzie (np. Scalanie trójstronne). Kontrola jakości eposu zostanie wykonana na gałęzi epickiej. Po przejściu epicka gałąź zostanie połączona w pień i zostanie uruchomiony test integracji. Wciąż mamy oddziały na wydania.

Dzięki epickim gałęziom znacznie zmniejszyliśmy ryzyko harmonogramu, ponieważ jesteśmy teraz w stanie uwolnić się z pnia i uwzględnić wszystkie epopeje, które zostały pomyślnie połączone w pień. Eposy, które nie są kompletne, tęsknią za autobusem i pojawią się w kolejnej wersji (w przyszłym miesiącu).

To oczywiście może działać tylko w naszym środowisku. Bardzo prawdopodobne, że będziesz mieć czynniki inne niż nasze, które wpłyną na wybór najlepszych opcji zarządzania oddziałami.

Na przykład, jeśli masz zespół z wieloma osobami pracującymi zdalnie i nie zawsze podłączonymi do serwera kontroli wersji, wtedy chciałbyś użyć systemu kontroli wersji, który obsługuje model rozproszony. GIT i kilka innych należałoby do tej kategorii. Według mojej najlepszej wiedzy TFS wymaga połączenia z serwerem, aby pliki były zapisywalne (naprawione w wersji 2010?).

Mam nadzieję, że udało mi się pokazać, że nie ma „jednego rozmiaru dla wszystkich”. Zacznij od procesów w konkretnym zarządzaniu oddziałami, określ wymagania i na koniec wybierz narzędzie, które najlepiej odpowiada Twoim potrzebom. Może to TFS, a może nie.

— Manfred
źródło

2

„TFS? Biegnij na wzgórza!” - Kusi mnie utworzenie drugiego konta, aby dwukrotnie go głosować.

— Ant

Dobrze słyszeć, że to działa dla Ciebie. Byłem w podobnych projektach, w których było to wymagane. Ale sposób, w jaki łączysz „epickie” gałęzie, sprawia, że brzmi to łatwo. Chciałbym powiedzieć, że za każdym razem jest to okropny ból.

— Lionel

1

@Lionel: Zgadzam się, to może się zdarzyć. W przeszłości widziałem też coś bardzo złego. Z mojego doświadczenia wynika, że kluczem do udanego zastosowania tego podejścia jest utrzymanie jak najmniejszej różnicy między gałęziami trunk i feature. Co najmniej raz dziennie musisz połączyć się z bagażnikiem. Równie opłaca się mieć tak małe, jak to możliwe epiki / funkcje, np. Więcej w skali dni / tygodni niż wiele miesięcy. Niezwykle korzystna jest również czysta architektura i projekt oraz (w pełni) zrekonstruowany kod.

— Manfred

@John Całkowicie zgadzam się z twoim ostatnim komentarzem. Głównym problemem, z jakim miałem do czynienia w przeszłości, jest to, że „nowe funkcje” są zwykle duże, skomplikowane i zawierają zmiany projektowe w istniejącym kodzie w bagażniku. Wdrożenie i przetestowanie może potrwać miesiące. Scalenie ich w bagażniku byłoby koszmarem, gdy więcej niż jeden zespół pracuje nad różnymi funkcjami.

— Lionel

4

Opowiadam się za jedną gałęzią za funkcję, ponieważ pozwala ona na dużą elastyczność przy podejmowaniu decyzji, które funkcje wysłać i które odłożyć.

To, jak dobrze to działa w twojej sytuacji, zależy od tego, jak dobrze Twój VCS obsługuje oddziały i, co ważniejsze, łączenie. DVCS, takie jak Git & Mercurial, sprawiają, że jest to stosunkowo trywialne ćwiczenie. SVN mniej. Udało mi się ominąć TFS, chociaż dużo o tym czytałem, w większości obawiam się, że są nieuprzejma. Jeśli utkniesz w TFS, zrób małą wersję pilotażową w oparciu o jedną funkcję dla każdego oddziału i sprawdź, jak dobrze idzie ci połączenie.

— Mcottle
źródło

2

Po pierwsze, wyłączenie odpowiedzialności. Trudno powiedzieć, jaki jest najlepszy sposób zarządzania Twoim źródłem, ponieważ nie jesteśmy świadomi tego, jak Twój zespół lub zespoły pracują na co dzień.

Ogólnie lepiej jest pracować na bagażniku. Dla każdego głównego wydania należy go rozgałęzić - tak, aby poprawki błędów dla wersji wydania znajdowały się w gałęzi, którą można ponownie połączyć z bagażnikiem. Wszyscy programiści pracują na linii głównej i regularnie zatwierdzają kod (minimum raz dziennie).

Regularne scalanie nowego kodu minimalizuje ból związany z łączeniem dużych fragmentów kodu w fazie ogromnej integracji. Rozprzestrzeniając ból, poczujesz go mniej. Im częściej członkowie zespołu zatwierdzają kod, tym mniej będą musieli się łączyć - ponieważ zawsze będą mieli najnowsze źródło.

— Lionel
źródło

2

Całkowicie nie zgadzam się na pracę nad bagażnikiem. Jeśli bagażnik się zepsuje, wszyscy to ucierpią. Nie zgadzam się również na rozgałęzianie po wydaniu głównym, a jeśli błąd dotyczy dwóch lub więcej wydań, naprawiasz go w każdej gałęzi?

— Trasplazio Garzuglio

@ marco-dinacci: To, co mówisz, może być poprawne, jeśli w dowolnym momencie utrzymywana jest więcej niż jedna wersja. Jednak ignorujesz fakt, że poprawki tych błędów zostałyby scalone z powrotem w bagażniku. Inne wydania mogłyby następnie wprowadzić zmiany. Odnośnie pęknięcia tułowia. Zanim przekażesz kod do pnia, powinieneś upewnić się, że masz wszystkie najnowsze źródła i że twoja zmiana nie zepsuła pnia. Jeśli jest zepsuty, nie powinieneś zatwierdzać, dopóki nie zostanie naprawiony. Oczywiście istnieją różne zalety i wady różnych podejść.

— Lionel,

1

Nigdy nie korzystałem z TFS 2008/2010, ale z tego, co przeczytałem na różnych forach, jest wiele negatywnych opinii na temat używania TFS do kontroli wersji. To sprawiło, że do tej pory trzymałem się z dala od TFS.

Obecnie używam SVN i Gita, uważam, że oba są dobre dla małych zespołów lub dla pojedynczego zespołu, ale osobiście nie poleciłbym SVN dla dużego zespołu.

Miałem oczy na PlasticSCM i spróbuję tego w najbliższej przyszłości.

Przepraszam, że nie odpowiedziałem na konkretne pytanie, opublikowałbym komentarz, gdyby moje uprawnienia na to pozwoliły.

— Filip
źródło

1

Myślę, że git sprawia, że wszystkie inne programy do kontroli źródeł stają się przestarzałe. Rozgałęzianie i łączenie jest łatwe, a jeśli występują problemy, zostaje ono ograniczone, ale można uniknąć wielu problemów, ponieważ zachęca ono do bardzo częstych zatwierdzeń, rozgałęziania i scalania. Każdy użytkownik otrzymuje pełną kopię repozytorium (można to przyciąć, ale pracuję z dość dużą bazą kodu i nie stanowi to problemu), więc jest coś z automatyczną kopią zapasową. Zatwierdzanie / push / pull jest szybkie, a jedną z najważniejszych rzeczy jest to, że przerywa sprzężenie między nazwą pliku a śledzeniem. Dane pliku, w tym nazwa i ścieżka, to obiekt blob danych, do którego odwołuje się węzeł drzewa, który jest niezależny od ścieżek. Jest to nie tylko bezpieczniejsze, ale niektóre rodzaje problemów „nigdy nie rób tego” w przypadku czegoś takiego jak SVN nie stanowią problemu. Może być używany jako tradycyjna konfiguracja koncentratora lub peer-to-peer, a te zastosowania można dowolnie mieszać w tej samej konfiguracji. Jest kryptograficznie zabezpieczony przed nieudokumentowanymi wstawkami. I to jest bardzo szybkie.

Uważam, że używam go teraz w domu przez cały czas, aby śledzić dokumenty i synchronizować je między komputerami, ponieważ łatwiej jest zatwierdzić i wypchnąć serwer plików niż wykonać kopię zapasową na serwerze lub zapisać tam.

Wada jest trochę stromą krzywą uczenia się, ponieważ łamie ona wszystkie zasady, do których ludzie są przyzwyczajeni z kontrolą źródła, w subtelny sposób, ale jest to krótka stroma krzywa uczenia się.

— Kylben
źródło

1

Git jest naprawdę dobry, ale (tak jak wszystko) nie jest najlepszym rozwiązaniem dla wszystkich i wszystkiego. programmers.stackexchange.com/questions/111633/…

— Rook

4

W jaki sposób Git sprawia, że Mercurial staje się przestarzały? Zwłaszcza w środowisku programistycznym Windows. Lepiej byłoby powiedzieć, że DVCS sprawia, że inne VCS stają się przestarzałe, niż rzucanie bombą benzynową i rozpoczynanie świętej wojny.

— Mcottle,

@mcottle - nie posunąłbym się nawet tak daleko. Na przykład SVN jest doskonałym przykładem jakości nierozproszonego VCS. Można powiedzieć, że SVN sprawia, że CVS staje się przestarzały, ale na tym poprzestałbym. Git w żaden sposób nie powoduje, że SVN staje się przestarzałe - jest to zupełnie inne podejście, które jest dobre dla niektórych, ale złe dla niektórych innych podejść (więcej patrz link powyżej). Na przykład zarówno Git, jak i Hg stosunkowo „zasysają” pliki binarne.

— Rook

@ldigas: W jaki sposób git i hg „ssą” gorzej z plikami binarnymi niż svn? Żadne z nich nie może śledzić zmian w plikach binarnych poza ziarnistością dla poszczególnych plików, ze wszystkimi powiązanymi konsekwencjami. Poza tym oba powodują, że svn staje się w większości przestarzały, widząc, jak każdy może zrobić dokładnie to, co robi svn (oprócz kilku niejasnych funkcji), a potem niektóre; po prostu musisz to tak skonfigurować. Najlepszym powodem używania svn, o którym mogę myśleć, jest to, że już go używasz, a migracja byłaby zbyt bolesna / ryzykowna / droga.

— tdammers

@tdammers - Nie interesuje mnie trollingowa dyskusja. W przypadku powyższych punktów, Google trochę, a natkniesz się na coś dość szybko.

— Wież

1

Niektóre z dobrych praktyk, które naprawdę przestrzegamy i bardzo nam pomogły:

1) Upewnij się, że nie masz zapisywalnej kopii pliku w swoim lokalnym i zawsze sprawdź, aby edytować. (Jeśli czasami musisz pracować lokalnie, spróbuj połączyć je w kontrolę źródła przed EOD).

2) Oznaczaj swoje pliki okresowo, po niewielkich znaczących kamieniach milowych.

3) Daj dobre komentarze kasowe lub meldujące się. Pomoże to podczas przeglądania, czasami nie trzeba otwierać i porównywać wersji.

— franklins
źródło

1

w jaki sposób zarządzasz meldowaniami i zapobiegasz konfliktom funkcji oraz odpowiednio zarządzasz zależnościami z kontrolą źródła?

Z mojego POV jest to dwuskładnikowe zadanie: musisz to zrobić po stronie technicznej (dobre i łatwe i kuloodporne rozgałęzianie | łączenie | audyt itp.) I zarządzania (dobrze ugruntowane zasady „co”, „kiedy”, jak). Dwie lub nawet trzy warstwy kodu separacji w ALM: coś w rodzaju „stabilny” (zaliczone testy jednostkowe), „niestabilny” (każda zawarta funkcja została zakończona, ale aplikacja jako produkt ma pytania po integracji / tak, może się zdarzyć /) i „ Praca w toku". W ten sposób właściwy Project Manager może zmniejszyć zakłócenia wspólnej pracy programisty.

TFS (którego nie używałem, używam i nie będę używać) ma pewne, AFAIK, podstawowe problemy w swoim aspekcie zarządzania kontrolą źródeł. Po prostu odsyłam tutaj do niektórych tekstów Jamesa McKaya:

— Leniwy Borsuk
źródło

1

Naprawdę ładny i niedawny artykuł, który w jasny i zwięzły sposób porównuje i kontrastuje kilka różnych sposobów pracy z kontrolą źródła, znajduje się tutaj: Kontrola źródła została wykonana poprawnie .

Nie sądzę, aby istniała jedna strategia / najlepsza praktyka dotycząca korzystania z kontroli źródła. Dojrzałe zespoły, które od dawna współpracują, odczuwają znacznie mniej „bólu” w tej dziedzinie, nawet jeśli nie przestrzegają popularnych „najlepszych praktyk”.

Jeśli chodzi o narzędzia ... To prawie nie ma znaczenia. Najważniejsze jest to, aby wszyscy w zespole byli na tej samej stronie pod względem wykorzystania. Oznacza to, że każdy musi zrozumieć, w jaki sposób zarządzana jest linia kodu i czego się od niej oczekuje. Zresztą w praktyce zazwyczaj NIE masz wyboru, którego narzędzia użyć. Wykorzystaj wszystko, czego używasz.

— Angelo
źródło