Czy coś jest nie tak z tym, jak przeprowadzamy kontrolę wersji?

53

Współpracuję z zespołem programistów jako analityk biznesowy. Właśnie wydaliśmy wersję 2.0 naszego produktu i pracujemy nad kolejną wersją, która zostanie wydana za 3 miesiące (jest to wewnętrzny produkt programowy). Niestety w wersji 2.0 występują pewne problemy, które musieli naprawić, a my zamierzamy je wdrożyć za kilka tygodni. Problem polega na tym, że nie chcemy również wdrażać zmian, nad którymi wciąż pracujemy i nie zostaną wydane na kolejne 3 miesiące.

Programiści zdecydowali, że sposobem na zarządzanie tym będzie sprawdzenie, że tylko kod wad będzie rejestrowany, a kod nowych ulepszeń będzie przechowywany na lokalnych komputerach programisty, dopóki nie zostaną wykonane. Będę musiał pobrać lokalne kompilacje z ich maszyn do przetestowania, ponieważ jeśli sprawdzą kod i będziemy musieli wypchnąć kolejną łatkę, aby naprawić defekty, nie chcemy jeszcze uwzględniać tych ulepszeń. Istnieje również problem polegający na tym, że ten sam plik kodu zawiera zarówno poprawki defektów, jak i ulepszenia, więc muszą skopiować plik kodu lokalnie, a następnie wprowadzić zmiany, aby naprawić błąd i sprawdzić, czy jeden z nich, a następnie wznowić pracę nad ulepszeniami, biorąc zrobili lokalną kopię.

Wydaje się to dość skomplikowane - czy istnieje lepszy sposób radzenia sobie z tego typu scenariuszem? Używamy Team Foundation Server i Visual Studio 2010.

Ryan
źródło
113
Zwolnij programistów.
Bernard,
11
Każdemu z nich daj gałąź. Egzekwuj codzienne meldowanie.
16
@Ryan Jedynym możliwym usprawiedliwieniem, jakie mogliby wymyślić, byłby, gdyby był to stary projekt na czymś takim jak SourceSafe. Team Foundation Server 2010 jest jednak naprawdę dobrym rozwiązaniem do kontroli źródła, które nie powinno mieć problemów z zarządzaniem wieloma gałęziami i wykonywaniem połączeń tych gałęzi z głównym. Jeśli tego nie wiedzą, są nieprzyzwoicie niekompetentni i powinni zostać zwolnieni. Bardziej prawdopodobne jest jednak to, że w rzeczywistości są zbyt leniwi lub apatyczni, aby czuć się zaniepokojonymi gałęziami i łączeniem się, więc karmią cię linią.
maple_shaft
10
@Jan_V Nic w SourceSafe nie jest łatwe.
maple_shaft
30
Nie znam TFS, ale to pytanie brzmi jak reklama Mercurial lub GiT.
Jim In Texas

Odpowiedzi:

77

Wersja 2.0 powinna była mieć to, co używaliśmy, zwane „oddziałem stanu ustalonego” (używaliśmy Perforce, a nie TFS), stworzone dla niego po wydaniu. Wszelkie poprawki do wersji 2 zostałyby wprowadzone do tej gałęzi, a następnie propagowane z powrotem do gałęzi programowania v3, podczas gdy również pracowano nad funkcjami wersji 3, tj. Wada w wersji 2 spowodowałaby wadę również w wersji 3.

Długotrwałe zmiany na komputerach programistów prawdopodobnie spowodują koszmar integracji.

James
źródło
6
MS ma białą księgę na ten temat (która obejmuje rzeczy o wiele bardziej szczegółowo): vsarbranchingguide.codeplex.com/releases/view/38849
Richard
2
I nadal mogą utworzyć gałąź wersji w TFS na podstawie kompilacji datetime v2.0.
DaveE
2
Przekazałem ten post na blogu, myślę, że jest bardzo dobrze napisany. (Odnosi się do git, ale nadal jest istotny) nvie.com/posts/a-successful-git-branching-model
BZink
50

Cóż, istnieje wiele sposobów radzenia sobie z takimi problemami, zwykle objętymi tagiem „rozgałęzienia” , każdy z własnym zestawem zalet i wad.

Ale podejście wybrane przez twoich programistów ... rany zacytuję to ustnie, aby upewnić się, że nie pomyliłem się ...

kod ... będzie przechowywany na lokalnych komputerach programisty, dopóki nie zostaną zakończone ...

... sposób jak wyżej jest prawdopodobnie jedynym, który jest całkowicie, całkowicie błędny!

Dla mnie przestępstwem jest to, że dla TFS istnieje doskonały, łatwy do zrozumienia, Microsoft Team Foundation Server Branging Guidance - ogromny i szczegółowy dokument z zaleceniami strategii rozgałęziania, starannie dostosowanymi i objaśnionymi do różnego rodzaju projektów ( wersja HTML tutaj ).

komar
źródło
6
Poważnie, programiści muszą przeczytać i zapoznać się ze wskazówkami dotyczącymi rozgałęziania się serwera Team Foundation Server, a nie pisać kolejnej linii kodu, dopóki tego nie zrozumieją, nie zrozumieją i nie utworzą oddzielnych gałęzi dla poprawek 3.0 dev i 2.0.
Carson63000,
@ Carson63000 zgadza się, że warto czytać nawet dla facetów spoza TFS (takich jak ja). Sposób, w jaki pracownicy Microsoftu klasyfikują projekty, a zwłaszcza sposób, w jaki określają czynniki, które należy wziąć pod uwagę przy wyborze odpowiedniej strategii rozgałęziania, są niezależne od narzędzi i dają całkiem niezłe do myślenia.
komara
40
  1. Twój deweloper ma fundamentalne nieporozumienie dotyczące korzystania z kontroli wersji.
  2. Nie wdawaj się w dyskusję na temat „właściwego” oprogramowania do kontroli wersji. To nie jest problem.
  3. Każda poprawka kodu utrudnia naprawienie problemu.
  4. KIEDY wszyscy zdecydujecie się postępować właściwie, nie możecie kontynuować zmian w kodzie podczas naprawy. MUSISZ zatrzymać wszelkie prace rozwojowe i przekazać kod do kontroli wersji.
  5. Dev musi odczuwać ból na tyle, aby przynajmniej usiąść i porozmawiać o tym.
  6. Całe oprogramowanie do kontroli wersji obsługuje podstawowe pojęcia:
    • Cały kod trafia do repozytorium kontroli wersji.
    • Wszystkie pliki kodu mają numery wersji. Liczby te zwiększają się automatycznie, gdy kod jest ponownie rejestrowany.
    • TAG oznacza wszystkie pliki kodu określonej wersji. W ten sposób możemy na przykład TAGować wersję oprogramowania 1.
    • ODDZIAŁ to „odwrócenie się” od głównego pnia .
      • Wszelkie zmiany dokonane w gałęzi nie wpływają na pień.
      • W pewnym momencie możesz opcjonalnie scalić zmiany gałęzi z powrotem do głównego pnia.
      • W ten sposób możemy eksperymentować bez obawy o zepsucie „dobrych rzeczy”.
  7. Wszyscy musicie uzyskać kontrolę wersji „skok wiary”, jak to nazywam. ZAUFAJ, że przestrzeganie podstawowych zasad sprawi, że wszystko będzie proste. Brak doświadczenia każe nam myśleć inaczej, zaufaj mi.
  8. Oto przyzwoity samouczek. Jest ogólny i na tyle kompletny, że nie musisz przeszukiwać wielu innych źródeł

edytować

  • Umieść kontrolę wersji na swoim komputerze roboczym.
    • Możesz to zrobić teraz bez koordynacji zespołu
    • Nawet z kontrolą wersji zespołu, bardzo to polecam
    • Jeśli Twój zespół korzysta z Git lub Mercurial, korzystasz z niezależnego lokalnego repozytorium. Tak działa rozproszona kontrola wersji.
    • Możesz używać innego oprogramowania VC ze swojego zespołu. Nasz zespół używa Subversion, ja używam Mercurial lokalnie. Metapliki oprogramowania VC („.svn”, „.mg”, ukryte foldery) nie powodują konfliktów.

Nie działasz jako de facto repozytorium zespołu. Służy do zarządzania własną pracą, refaktoryzacji itp. Oraz CYAingowania się, gdy zespół nadal FUBAR bazy kodu.

zakończ edycję

radarbob
źródło
3
Nitpick: „Wszystkie pliki kodu mają numery wersji. Numery te zwiększają się automatycznie” Niektóre VCS (np. Subversion, Git) mają identyfikatory wersji na repo zamiast na plik, a identyfikatory wersji niekoniecznie są numeryczne (Git). Oczywiście podstawowa kwestia nadal obowiązuje.
sleske
Wersje „na plik / na repozytorium”. Tak. Jest to podstawowe zróżnicowanie oprogramowania VC. Użyłem obu rodzajów - „country AND western” (+1 do kogokolwiek, kto zna to odniesienie). Bardziej podoba mi się model „per repo”.
radarbob
13

To, co opisujesz, jest okropnym sposobem korzystania z kontroli wersji. Powinna istnieć gałąź utworzona dla wydania 2.0, tag lub jakiś identyfikator. W ten sposób można wprowadzić modyfikacje do tego wydania i kontynuować rozwój.

W tym artykule znajdziesz kilka pomysłów. Zostało napisane z gitmyślą o tym, ale nie ma powodu, dla którego nie mogłoby mercurialtak dobrze działać . Zdaję sobie sprawę, że nie używasz żadnego z nich, ale jest to również problem, który powinieneś rozważyć.

jdl
źródło
9
Co jest złego w korzystaniu z TFS?
Bernard,
2
Zależy od tego, co próbujesz osiągnąć. Plusy i minusy są częstym tematem na SO. To dobry punkt wyjścia. stackoverflow.com/questions/4415127/…
jdl
4
Rozproszone systemy kontroli wersji nie zawsze mają sens.
maple_shaft
3
-1: Pomimo tego, co twierdzą ewangeliści, rozproszona kontrola wersji nie jest odpowiedzią na każdy problem i nie rozwiązałaby tego.
mattnz
3
@Ant: Być może masz rację, ale w kontekście pierwotnego pytania nie sądzę, aby miało znaczenie, czy TFS jest używany do kontroli źródła. Tak długo, jak TFS obsługuje rozgałęzianie, powinien być wykorzystywany przez zespół programistów PO.
Bernard,
7

Szybka Odpowiedź: Zespół Rozwoju powinna mieć oddzielny oddział produkcyjny do utrzymania wdrożonego kodu bazowego V2.0 oddzielone od głównego pnia.

Wszystkie poprawki błędów muszą być najpierw wykonane w tej gałęzi, a następnie przetestowane i wdrożone w innych gałęziach, aby zachować synchronizację kodu .

Twój projekt powinien mieć także kilka środowisk, for health developmenttakich jak Prod, Staging, QA i Dev (czasami UAT). Te środowiska należy skonfigurować przed przejściem do wersji produkcyjnej.

Podsumowując, gotowość na błędy i modyfikacje to sposób na wsparcie wydanej aplikacji.

Ponieważ TFS został wspomniany jako kontrola wersji, skompilowałem również listę artykułów, które będą pomocne w ustawianiu środowiska programistycznego:

EL Yusubov
źródło
4

Nie, ponieważ podczas korzystania z VCS nie kontrolujesz wersji.

Główną koncepcją kontroli wersji jest śledzenie różnic w czasie, PLANUJESZ na rejestrowanie pewnych różnic, ale w tej chwili większość twoich zmian nie jest rejestrowana.

Jak powiedzieli inni, powinieneś używać gałęzi. Kiedy już to skonfigurujesz, powinieneś sprawdzać wszystkie zmiany funkcjonalne (tj. Nie każde naciśnięcie klawisza, ale za każdym razem, gdy naprawisz błąd, dodasz funkcję, usuniesz funkcję lub w inny sposób dokonasz zmiany, tak aby nadal się kompilowała i działała).

jmoreno
źródło
0

Jestem programistą i otrzymujemy inny kod oddziału i bazę danych dla poprawek bieżącej wersji, a inny dla ulepszeń i późniejszych kolejnych wersji.

Po zakończeniu naszych poprawek są one łączone z produkcją i wdrażane, otrzymujemy nowy świeży oddział, aby znów mógł pracować z ulepszeniami.

Ponadto postępujemy zgodnie z praktyką, jeśli mam 10 poprawek do mojej bieżącej wersji

Piszę jako

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Podobnie w przypadku innych poprawek, po prostu robię to dla każdej linii, którą zmieniam lub dodaje do naprawy. I po prostu porównaj i zatwierdź. Podobnie, jeśli robią równolegle na tej samej gałęzi, mogą użyć

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fpolecenie i typ //Start Iteration 2, Fix No-1, Branch No-"ABC" do przeszukiwania całego rozwiązania bardzo pomaga znaleźć dokładne lokalizacje, pliki, w których kod jest zmieniany, i pobrać nowy kod tylko ta część może zostać zatwierdzona.

Shilpa
źródło