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

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.

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.

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 ).

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ł
   • Kontrola wersji, lepiej wyjaśnione

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ę

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ć.

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:

• Wdrażanie Team Foundation Server z małym zespołem programistów
• Witamy na platformie integracyjnej TFS!
• Rozwój zespołu z przewodnikiem TFS
• Konfigurowanie środowiska programistycznego

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).

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.