Nasz zespół chce wykorzystać Team Foundation Server v.11 (2012) do zarządzania naszymi projektami. Obecnie zarządzamy projektem w arkuszach kalkulacyjnych. Nasz zespół opracowuje oprogramowanie wyłącznie dla klientów wewnętrznych i jest dużo dll między projektami. Używamy także SVN do kontroli wersji kodu źródłowego.Projekt TFS z wieloma rozwiązaniami Visual Studio
Mamy Rozwiązania dla różnych części naszych aplikacji: Wspólna Biblioteka, Biblioteki Aplikacji (reguły biznesowe itp. Oto, co nasza struktura SVN wygląda
SVN
-CommonLibrary (VS Solution)
-Source
-CommonLibrary.Core (VS Project)
-CommonLibrary.Security (VS Project)
-CommonLibrary.Web (VS Project)
-OurCompanyLibrary (VS Solution)
-Libraries (Projects within this solution reference these)
-CommonLibrary.Core.dll
-CommonLibrary.Security.dll
-Source
-OurCompanyLibrary.Application1 (VS Project)
-...
-OurCompanyLibrary.ApplicationN (VS Project)
-OurCompanyIntranet (VS Solution) (MVC framework)
-Libraries (Projects within this solution reference these)
-CommonLibrary.Core.dll
-CommonLibrary.Security.dll
-CommonLibrary.Web.dll
-OurCompanyLibrary.Application1.dll
-Source
-OurCompanyIntranet.Application1 (VS Class Library Project)
-...
-OurCompanyIntranet.ApplicationN (VS Class Library Project)
OurCompanyIntranet.UI (VS Web Project)
-OurCompanyInternet (VS Solution) (MVC framework)
-Libraries (Projects within this solution reference these)
-CommonLibrary.Core.dll
-CommonLibrary.Security.dll
-CommonLibrary.Web.dll
-OurCompanyLibrary.Application1.dll
-Source
-OurCompanyInternet.Application1 (VS Class Library Project)
-...
-OurCompanyInternet.ApplicationN (VS Class Library Project)
-OurCompanyInternet.UI (VS Web Project)
Powodem podziału kodu na wiele rozwiązań, dlatego możemy ponownie użyć biblioteki aplikacji w różnych sytuacjach (aplikacje Intranet, aplikacje internetowe, aplikacje winform). Ponadto rozwiązania intranetowe i internetowe zawierają wiele aplikacji. To jest nasza obecna struktura. Nie jestem pewien, czy to najlepsza struktura organizacyjna, ale działa dla nas.
Problem z przełączeniem na TFS polega na tym, że jeden projekt zespołowy nie może zawierać części w wielu rozwiązaniach VS. Na przykład utworzymy projekt zespołu TFS dla aplikacji 1, abyśmy mogli mieć zaległe produkty dla tej aplikacji. Aplikacja 1 wymaga zmian w OurCompanyLibrary, OurCompanyIntranet i OurCompanyInternet, aby ukończyć aplikację, ale przy użyciu TFS będzie tylko jedno rozwiązanie VS dla aplikacji1.
Oto przykład, w jaki sposób tworzymy aplikację. Cały model domeny i reguły biznesowe są przechowywane w rozwiązaniu VS Our Library VS. Kiedy tworzymy aplikację, nazywamy ją Application1, najpierw rozpoczynamy tworzenie modelu domeny i reguł biznesowych w projekcie OurCompanyLibrary.Application1 VS w ramach rozwiązania VS OurCompanyLibrary. Po opracowaniu modelu domeny przechodzimy do programowania strony interfejsu użytkownika w usługach OurCompanyIntranet i OurCompanyInternet VS Solutions. Rozwiązania te są witryną w stylu MVC. OurCompanyIntranet zawiera projekt Web VS OurCompanyIntranet.UI, który zawiera wszystkie widoki (pliki .aspx), css, javasciprt itp. OurCompanyIntranet zawiera również wszystkie modele i kontrolery oddzielone przez aplikację (w tym przypadku OurCompanyIntranet.Application1). Zorganizowanie tego w TFS staje się problemem, ponieważ chcemy Team Project for Application1, ale ta aplikacja może obejmować wiele rozwiązań i nie chcemy mieć duplikatów wszędzie, dodając ten sam OurCompanyIntranet i OurCompanyInternet VS Solutions do kontroli źródła.
Jak zorganizowałbyś to w TFS? Czy istnieje inny sposób, w jaki powinniśmy zorganizować naszą strukturę kodu, która miałaby więcej sensu? Wszelkie artykuły lub strony, które prowadzą nas we właściwym kierunku, bardzo by pomogły.
Jak obsługiwałbyś wersje zespołów? Nasza strategia polega na udostępnianiu wspólnego pliku informacji o montażu dla rozwiązania, więc OurCompanyLibrary będzie mieć inną wersję niż CommonLibrary i tak dalej. Czy masz teraz tylko jedną wersję zespołu dla całego projektu zespołu? Rozumiem, że możesz mieć różne numery wersji, ale czy jest to najlepszy sposób na zrobienie tego lub najlepszy sposób na uzyskanie jednego numeru wersji dla całego projektu zespołu? – awilinsk
Jeśli produkt końcowy jest monolityczny, wszystkie zestawy mogą mieć ten sam numer wersji, a ten numer będzie używany do rozróżniania dwóch różnych wersji produktu. Załóżmy teraz, że opracowujesz dwa produkty (na przykład dwie niepowiązane strony internetowe) oparte na tym samym komponencie (zespoły podstawowe/biznesowe firmy), a wersjonowanie zestawów ma tutaj inne znaczenie, ponieważ te dwie witryny mogą wykorzystywać inną wersję zestawów podstawowych/biznesowych i możesz mieć inny cykl rozwoju dla trzech z nich (core/business, site 1, site2). Jeśli wszystko jest monolityczne, nie przejmuj się. – Nock
Dzięki za poradę. To nie jest monolityczne. Mamy dwie różne strony internetowe, które nie korzystają z tych samych zestawów biznesowych, ale intranet korzysta z tych samych zestawów biznesowych, co witryny publiczne.Myślę, że miałbym różne wersje dla każdej witryny i biblioteki. Jak rozgałęziałbyś się na takie rzeczy? Czy powinienem mieć gałąź główną i deweloperską jak zwykle, a następnie gałąź wydania dla każdej z różnych stron? – awilinsk