Najlepszy sposób: zrestrukturyzuj istniejące rozwiązanie Team Foundation Server (TFS)

W moim dziale opracowujemy kilka mniejszych dodatków dla jakiegoś zunifikowanego serwera komunikacyjnego. Do tworzenia wersji i programowania rozproszonego używamy Team Foundation Server 2012.

Ale: istnieje tylko jedno duże rozwiązanie TFS dla wszystkich naszych aplikacji i bibliotek:

• Główne rozwiązanie
  • Aplikacje
    
    • Aplikacja 1
    • Aplikacja 2
    • Aplikacja 3
  • Pozory
  • Biblioteki
    
    • Lib 1
    • Lib 2
  • Przybory

Ścieżka „Aplikacja” zawiera wszystkie główne aplikacje. Nie zależą one od siebie, ale zależą od projektów bibliotek i zewnętrznych.

Ścieżka „Zewnętrzne” zawiera niektóre zewnętrzne biblioteki DLL wymienione w naszych aplikacjach i bibliotekach.

Ścieżka do bibliotek zawiera często używane biblioteki (szablony interfejsu użytkownika, klasy pomocnicze itp.). Nie zależą od siebie i są przywoływane w projektach Biblioteki i Narzędzia.

Ścieżka Narzędzia zawiera niektóre programy pomocnicze, takie jak pomocniki konfiguracji, aktualizacje usług internetowych itp.

Teraz jest kilka głównych powodów, dla których chciałbym zmienić tę strukturę:

• Nie możemy używać kompilacji serwerów.
• Zarządzanie TFS scrum za pomocą sprintu, przeszkód itp. Przy takiej strukturze rozwiązania jest niewygodne.
• Każdy programista ma zawsze dostęp do wszystkich projektów w rozwiązaniu.
• Pełna kompilacja trwa zbyt długo, jeśli przypadkowo trafi [F6] w Visual Studio ...

Co byś zmienił w tym rozwiązaniu? Jak podzieliłbyś te projekty na mniejsze Rozwiązania, jak powinna wyglądać struktura tych rozwiązań.

Moim pierwszym podejściem byłoby stworzenie jednego projektu TFS dla każdej aplikacji, biblioteki i narzędzia. Ale jak mogę się upewnić, że np. Aplikacja 2 zawsze zawiera najnowszą wersję Lib 1? Czy muszę monitorować zmiany w Lib 1 i ręcznie aktualizować aplikację 2, gdy tylko Lib się zmieni? Czy mogę w jakiś sposób zmusić program Visual Studio do korzystania z najnowszej wersji projektu zewnętrznego?

Edycja: W TFS istnieje tylko jedna kolekcja projektu TFS Team, zawierająca jeden projekt TFS Team. Team Project zawiera jedno duże rozwiązanie Visual Studio, które zawiera kilka folderów zawierających (patrz struktura powyżej), z których każdy zawiera wiele projektów VS.

Moje pytanie brzmi: w jaki sposób przeorganizowałbyś:

1. Projekty zespołu TFS
2. Projekty VS

Trzymaj się jednego Projektu Zespołowego TFS, ponieważ wielokrotność staje się uciążliwa podczas próby aktualizacji i ma pewne ograniczenia, jeśli chodzi o elementy pracy w ramach projektu zespołowego. Zamiast tego powinieneś intensywnie wykorzystywać obszary i iteracje.

Podziel swoje rozwiązanie VS na wiele rozwiązań, po jednym na główną aplikację. Przyspieszy to znacznie kompilacje lokalne, a także serwer kompilacji.

TFS2012 ma nową koncepcję o nazwie Teams, tworzy zespół dla każdej aplikacji i ustawia domyślne iteracje i zaległości dla każdej z nich. W ten sposób możesz zarządzać zaległościami dla każdego z nich lub wyświetlić zespół główny, aby zobaczyć zwinięte zaległości. Następnie możesz zarządzać sprintami na poziomie aplikacji lub ogólnie w zależności od tego, co Ci odpowiada.

Twórz pakiety NuGet dla wszystkich bibliotek, do których istnieją odniesienia, które jeszcze nie mają. Przechowuj je w prywatnym repozytorium (wspólny folder systemu Windows) i włącz funkcję przywracania pakietów dla NuGet, klikając prawym przyciskiem myszy każde rozwiązanie i włączając je (zezwól również na przywracanie pakietów, aby pobierać pakiety w ustawieniach vs).

Jeśli masz jakieś współużytkowane biblioteki wewnętrzne, utwórz dla nich również pakiety NuGet i utwórz rozwiązanie vs zawierające tę bibliotekę. Dodaj polecenie post build, aby utworzyć pakiet nuget lub rozszerz szablon kompilacji tfs, aby to zrobić (istnieje wiele szablonów, które już to robią).