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.
Odpowiedzi:
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.
źródło
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ę ...
... 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 ).
źródło
edytować
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ę
źródło
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
git
myślą o tym, ale nie ma powodu, dla którego nie mogłobymercurial
tak dobrze działać . Zdaję sobie sprawę, że nie używasz żadnego z nich, ale jest to również problem, który powinieneś rozważyć.źródło
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 development
takich 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:
źródło
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).
źródło
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
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ć
Ctrl+Shift+F
polecenie 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.źródło