2012-06-13 13 views
7

Mam rozwiązanie o nazwie "Framework", które jest zbiorem C# dla mojej logiki biznesowej i transakcji danych.Rekomendacja rozgałęzienia TFS

Mam 4 aplikacje korzystające z programu ramowego, 1 witryny internetowej, 1 aplikacji konsolowej i 3 innych typów aplikacji.

$/TeamProject 
    /Framework 
     /Dev 
     /Main 
     /Release 
    /WebApp 
     /Dev 
     /Main 
     /Release 
    /WCFApp 
     /Dev 
     /Main 
     /Release 

Mam wszystko w jednym projekcie zespołowym z każdym zestawem/aplikacją pod własnym folderem.

Chcę użyć funkcji rozgałęzienia dla każdej aplikacji, które współdzielą zespół Framework, ale nie wiem, jaki jest najlepszy sposób na rozgałęzienie aplikacji wraz z Framework?

Wszelkie sugestie?

Wiem, jak działa rozgałęzianie i scalanie, ale wszystkie przykłady pokazują rozgałęzianie wszystkiego, co zawiera jeden folder.

+0

pokazane jak moje pliki w kontroli źródła obecnie wyglądają –

Odpowiedz

7

W świetle obraz reprezentujący katalog kontroli źródła, zrobię następujące założenia:

 
$/TeamProject 
    /Framework 
    /Console 
    /Web 
    /etc. 

Co trzeba zrobić w pierwszej kolejności, to stworzyć folder o nazwie Main w $/TeamProject (to będzie twój główny - aka trunk - branch) i przenieść do niego wszystkie foldery najwyższego poziomu.

Tak więc mamy:

 
$/TeamProject 
    /Main 
    /Framework 
    /Console 
    /Web 
    /etc. 

Teraz trzeba konwertować Main do oddziału, można to zrobić klikając prawym przyciskiem myszy na folderze Main i wybierz "Convert to oddział". TFS pozwoli teraz na rozgałęzienie $/TeamProject/Main na $/TeamProject/ConsoleV2 (na przykład) i pracę z funkcjami dla V2 Konsoli. Możesz modyfikować aplikację konsoli i środowisko, jeśli jest to wymagane w tej gałęzi. Po zakończeniu tej pracy można odwrócić integrację (scalić) zmiany z powrotem do Main.

Pamiętaj, aby kontynuować przeprowadzanie scaleń Forward Integration (scalanie) z Main z gałęzią funkcji i rozwiązywać konflikty, aby synchronizować bazy kodów.

Stosując takie podejście, można zmodyfikować dowolną część dowolnego z produktów w jednym sprawdzeniu atomowym, np. Zmienić interfejs API w ramce, dodając nowy parametr obowiązkowy do metody, można to zmienić w wszystkie twoje aplikacje w tym samym czasie, a kiedy RI scalą się w Main wszystko zostanie zaktualizowane.

+0

Zdaję sobie sprawę z tego apprach, problem z tym, jeśli chcę Brach mojej aplikacji Console wraz z Framework Mam do rozgałęzienia wszystko obok ... jest to zwykle podejście? Wygląda trochę na zabicie –

+0

Miejsce, w którym się znajdujesz w repozytorium źródłowym, nie zmieni rozmiaru tworzonej przez niego gałęzi. Zastosowaliśmy to podejście do rozgałęzienia kilku różnych części naszej aplikacji, które są niezależne od wersji, dzięki czemu możemy aktualizować zależne części w tym samym czasie. Możesz po prostu zignorować foldery, które nie działają. – DaveShaw

+0

Dodałem "wizualizację" tego, jak mój kod źródłowy jest obecnie ustrukturyzowany w moim projekcie zespołowym. –

-2

Jeśli chcesz mieć rozgałęzienia & łączenie dla poszczególnych projektów, jedynym sposobem na osiągnięcie tego w ramach TFS jest utworzenie oddzielnego projektu TFS dla każdego projektu w twoim rozwiązaniu. Mam nadzieję, że ma to sens. Kiedy to zrobisz, możesz odłączyć kod z każdego projektu do swojego katalogu roboczego.

Niedawno przenieśliśmy nasz kod z VSS na TFS. W tym czasie musieliśmy zdecydować, aby umieścić cały kod w jednym projekcie TFS lub je rozdzielić. Mamy więc stronę internetową, bibliotekę biznesową (która jest używana przez inne aplikacje na stronie internetowej), warstwę danych. Stworzyliśmy oddzielny projekt TFS dla biblioteki, strony internetowej i projektów warstwy danych. Każdy projekt miałby gałąź bagażnika. Każdy, kto potrzebuje najnowszego, oddzieliłby swoją kopię z bagażnika i wrócił tam.

Nadzieję, że pomaga.

+0

Więc jak ty łączących każdy zespół na 1 oddział? –

+0

Oto coś. Każdy programista musiałby przechowywać lokalny plik rozwiązania. Tak więc, jeśli potrzebuję biblioteki strony, biblioteki i dostępu do danych, chciałbym pobrać te gałęzie z TFS do rozwiązania na moim końcu i nigdy nie sprawdzać rozwiązania. – Skadoosh

+0

Spójrz na te: http://stackoverflow.com/questions/400517/tfs-structure-multiple-projects-lub-single-project i http://stackoverflow.com/questions/867628/merging-and-branching -shared-code-between-projects-in-tfs – Skadoosh

2

Twoje podstawowe pytanie, które rozumiem, brzmi: "Jaka jest najlepsza struktura rozgałęziania do rozgałęzienia moich aplikacji zależnych od Framework?" Jeśli zawsze budujesz i wersjonujesz/wypuszczasz je razem, to prostsze i mniej kosztowne jest rozgałęzienie ich wszystkich razem jak DaveShaw opisuje; jednak, jeśli każdy z nich jest tworzony przez różne zespoły, mają różne harmonogramy wydań, mają różne wersje, itp. ... niż chcesz stworzyć oddział MAIN pod każdym z nich. W takim przypadku powinno również być jasne, kto jest właścicielem zmian w Ramach. Zazwyczaj dobrym pomysłem jest kontrolowanie dostępu do zameldowania tylko dla tych, którzy potrzebują go do wspólnych projektów, takich jak Framework.

Jeśli ten drugi przypadek jest prawdziwy, to myślę, że twoja obecna grafika dobrze to obsługuje, ale chciałbym dokonać jednej zmiany; Utrzymuj Wydania na tym samym poziomie w hierarchii co gałąź MAIN, aby względna ścieżka pozostała taka sama dla tworzenia odniesień; to uprości mapowania obszaru roboczego:

$/TeamProject 
    /Framework 
     /Dev 
     /Main 
     /Release1 
     /Release2 
     /Release3 
     ... 
    /WebApp 
     /Dev 
     /Main 
     /Release 
      /Release1 
      /Release2 
      /Release3 
      ... 
    /WCFApp 
    ...