Scalanie projektów zespołowych

Question

W naszym bieżącym projekcie mamy cztery różne projekty zespołów TFS2010 w tej samej kolekcji Team Project. Powodem tego jest to, że różne części projektu chciały używać różnych szablonów projektów zespołowych (CMMI vs Agile).

Wszystkie projekty wykorzystują teraz ten sam szablon. Dlatego też doszliśmy do wniosku, że lepiej byłoby połączyć projekty w jeden zespół projektowy. Rodzi to kilka pytań:

1. Czy możliwe jest/możliwe wykorzystanie jednego z istniejących projektów jako projektu docelowego dla pozostałych trzech?
2. Jak przenieść nasze istniejące elementy pracy do nowego projektu, zachowując nasze drzewo obszaru? Mamy nadzieję utworzyć jeden obszar główny dla każdego z naszych istniejących projektów zespołowych i przenieść wszystkie elementy pracy/obszary pod ten węzeł główny.
3. Dzisiaj mamy łącza do elementów roboczych od jednego zespołu projektów do drugiego - jak zachowujemy te linki podczas łączenia?
4. Jaka jest najlepsza praktyka podczas przenoszenia kodu źródłowego? Jedno wyraźne podejście polega na skopiowaniu go do nowej lokalizacji oraz zablokowaniu i zachowaniu starych projektów zespołów, na wypadek, gdybyśmy potrzebowali dostępu do starszych wersji kodu. Ale czy jest możliwe użycie tego rozgałęzienia, np. rozgałęzienia całego istniejącego kodu do nowego projektu zespołu? Jakie problemy mogą powodować takie podejście?

Dzięki za pomoc!

Answer 1

Niestety, TFS 2010 nie pozwala na łączenie projektów zespołowych.

Stawianie projektów zespołowych i zespołów projektów zespołowych jest jedną z najważniejszych decyzji strategicznych przed rozpoczęciem korzystania z TFS. Niestety, wielu klientów, którym pomagamy, nie wymaga planowania z góry i nie rozumie niektórych ograniczeń w TFS dotyczących łączenia, przenoszenia, dzielenia itp. Projektów zespołowych, zanim zaczną nurkować w celu korzystania z TFS: (

Gdy mamy zlecenia konsultingowe, w których klienci chcą skonsolidować swoje projekty zespołowe, musimy wykonać wiele ręcznych prac, aby zmigrować artefakty. Zbudowaliśmy kilka narzędzi, które pomogą nam w tym procesie dla elementów pracy, ale w większości przypadków jest to żmudna praca konsultingowa, dlatego narzędzia migracji zawsze muszą być dostosowane do potrzeb każdego klienta, ponieważ zwykle mają różne reguły biznesowe dotyczące sposobu migracji. "nie kończy się przynosząc ponad Wszystkie informacje na ten temat, a na końcu pojawiają się inne problemy, takie jak data/godzina, które różnią się od oryginalnych. (Słyszałem, że dalej zagadnienie kompresji czasu z migracjami.)

Kilka przemyśleń dla każdego ze swoich oryginalnych pytań:

1. Jasne, to teoretycznie może skorzystać z jednej z istniejących projektów zespołu jak osoby cel migracji pozostałych trzech. Tak długo, jak podoba ci się nazwa projektu zespołowego i nie chcesz, aby rename the team project. :)
2. To tutaj stworzyliśmy niestandardowe narzędzia do migracji elementów pracy, aby pomóc naszym klientom konsultacyjnym. Prawdopodobnie musiałbyś zrobić to samo.
3. Jest to również możliwe z niestandardowym narzędziem do migracji elementów pracy. Możesz po prostu śledzić mapowania między starymi identyfikatorami elementów pracy a nowymi identyfikatorami elementów pracy, a następnie dodawać linki później, gdy wszystkie nowe elementy pracy zostaną utworzone w projekcie zespołu docelowego.
4. To wszystko zależy od Ciebie. Zrobiłbym "move" version control operation na kodzie źródłowym ze starego projektu zespołu do projektu nowego zespołu. To wszystko utrzymuje. Nie usunę jednak żadnego ze starych projektów zespołów, ponieważ spowoduje to również zniszczenie historii kontroli wersji.

To nie jest najlepsza historia dla ciebie, ale miejmy nadzieję, że pomoże ci to zaplanować!