TFS 및 여러 솔루션의 공유 프로젝트

Question

.NET 팀은 고유 한 범주에 속하는 우리 회사의 프로젝트에서 작동합니다. 일부는 내부 웹 응용 프로그램이고 일부는 외부 (공개) 웹 응용 프로그램이며 우리는 회사 사무실 사용자를위한 내부 Windows 응용 프로그램과 소매점 (상점)을위한 Windows Forms 응용 프로그램도 가지고 있습니다. 물론 코드 재사용을 싫어하기 때문에 다양한 응용 프로그램간에 공유되는 많은 코드가 있습니다.

인터넷 폴더의 OurCompany.com 솔루션은 웹 사이트가있는 것 ..

- = folder, | = Visual Studio Solution 
-SVN 
    - Internet 
     | Ourcompany.com 
     | Oursecondcompany.com 
    - Intranet 
     | UniformOrdering website 
     | MessageCenter website 
    - Shared 
     | ErrorLoggingModule 
     | RegularExpressionGenerator 
     | Anti-Xss 
     | OrgChartModule etc... 

정도 : 현재 우리는 우리의 소스 제어로 SVN을 사용하고, 우리는 우리의 저장소는 다음과 같이 배치있어 또한 공유 디렉터리에서 ErrorLoggingModule, RegularExpressionGenerator 및 Anti-Xss 프로젝트가 포함됩니다.

마찬가지로 UniformOrdering 웹 사이트 솔루션은 이러한 각 프로젝트를 솔루션에 포함시킵니다.

우리는 OurCompany.com 웹 사이트에서 작업하는 동안 ErrorLoggingModule에 함수를 추가하거나 수정해야하기 때문에 .dll 참조에 대한 프로젝트 참조를 선호합니다. 바로 거기에 있습니다. 또한이를 통해 각 솔루션을 빌드하고 공유 코드의 변경으로 인해 다른 애플리케이션이 중단되는지 확인할 수 있습니다. 올바른 경우 빌드 서버에서 잘 작동합니다.

SVN에서는 문제가 없습니다. SVN과 Visual Studio는 TFS의 소스 제어 방식에 함께 묶여 있지 않습니다. TFS에서 TFS 프로젝트는 항상 Visual Studio Solution에 묶여 있었기 때문에 TFS에서이 유형의 구조를 사용하는 방법을 알지 못했습니다. 소스 코드 저장소는 TFS 프로젝트의 하위 프로젝트 였으므로이를 수행하려면 각 TFS 프로젝트의 소스 코드 저장소에 공유 코드를 복제해야했습니다. 제 동료가 말했듯이, "코드 재사용과 단순성에 관해 알려진 모든 우수 사례를 깨뜨립니다". 우리가 SVN으로 전환 한 것은 거래 차단기로 충분했습니다.

그러나 지금 우리는 개발 프로세스를 진정으로 수정해야하며 TFS의 응용 프로그램 수명주기 관리는 정확히 우리가 원하는 것과 정확히 비슷하고 우리가 일하기를 원합니다. 우리가 당면하는 가장 중요한 점은 공유 된 코드 문제입니다.

우리는 다른 상업용 및 오픈 소스 솔루션을 평가하고 있지만 우리는 이미 MSDN Subscription으로 TFS를 지불하고 있으며 TFS는 우리가 원하는 것입니다. 우리는이 문제를 해결하기위한 방법을 찾고 싶습니다. 발행물.

다른 사람이이 문제에 직면하여 해결 방법을 찾았습니까?

나에게 공유 할 수있는 기사 나 게시물을 본 적이 있다면 도움이 될 것입니다. 언제나

, 나는 당신이 그것을보고있어 "와 같은 답변에 열려있어 모든 잘못, 돌대가리 야, 여기가 수행해야하는 방법이다. 내가 여기에 몇 가지 오해 있다고 생각

Answer 1

. 첫째, 당신은 할 수 있습니다 단일 TFS 프로젝트에서 여러 개의 (원하는만큼) 솔루션을 사용할 수 있습니다. 또한 하나의 Visual Studio 프로젝트에 여러 가지 솔루션이 포함될 수 있습니다.

둘째, 사용중인 TFS 버전은 무엇입니까? 2005/08에서 TFS 프로젝트를 처리하는 방법

2008 년 한 해 동안 원하는 방식에 따라 여러 가지 방법으로 접근 할 수 있습니다. 그것에서 벗어나십시오. 여러 개의 TFS 프로젝트 또는 단일 TFS 프로젝트를 가질 수 있습니다.

여러 개부터 시작하겠습니다.

공유 라이브러리 유형 코드 용 TFS 프로젝트와 보유하고있는 정규 프로젝트마다 다른 TFS 프로젝트를 설정하십시오. 이 공유 라이브러리의 개발 프로세스의 일부로 완성 된 어셈블리를 체크인하십시오. 그런 다음 해당 어셈블리를 사용하려는 다른 TFS 프로젝트로 분기하십시오. 공유 라이브러리에 대한 기능 업데이트 또는 버그 수정을 수행 할 때 해당 분기를 업데이트를 원하는 다른 TFS 프로젝트에 병합하기 만하면됩니다.

이 기능을 사용하면 단일 앱을 모두 푸시하지 않고 공유 할 수 있습니다.

모든 것을 담은 단일 TFS 프로젝트를 원한다면 원하는 각 Visual Studio 프로젝트에 폴더를 추가하기 만하면됩니다. Visual Studio 솔루션은 문제없이 기본 트리 외부의 프로젝트를 다시 참조 할 수 있습니다. 이제 각 솔루션의 빌드와 같은 것을 구성 할 때 빌드 서버가 가져 오는 디렉토리를 제한해야합니다. 그렇게하면 외부 사이트가 변경되었을 때 내부 사이트 중 하나를 구축하지 않아도됩니다.

Answer 2

언젠가 다른 사람에게 도움이되기를 바라는이 기록 만 남겨두면 나는 원래의 질문에 너무 늦을 까봐 두려워합니다.) 우리는 매우 비슷한 상황에 처해 있습니다. 우리가 TFS를 적절히 설정하기가 매우 쉬워졌습니다. 이 작품은 (우리의 경우 SaaS는 애플 리케이션입니다) 팀 프로젝트 중 하나에 (SharePoint의 스크럼 템플릿을 사용하여) 할당 할 수 있음을 의미

# = Project Collection, > = Team Project, | = VS project 
# SVN 
    > Internet 
     | OurCompany 
     | OurCompany2 
    > Intranet 
     | UniformOrdering 
     | MessageCentre 
    > Shared 
     | ErrorLogging 
     | RegularExpression 

:

우리의 설정을 설명하기 위해 예제를 사용하려면 개발자는 VS 프로젝트 중 일부 또는 전부를 열어 작업을 완료 할 수 있습니다.

대부분의 수석 개발자 (여러 제품에 걸쳐있는 개발자)는 다른 VS 프로젝트가 모두 포함 된 하나의 VS 솔루션 (예 : "WholeEnterprise.sln"을 사용하여 비유를 계속할 수 있음)을 가지고 있기 때문에 언제든지 그들. 우리는 또한 프로젝트를 올바르게 빌드하고 업데이트를하기 전에 모든 종속성을 최신 상태로 유지할 수 있습니다.

운영체제에서 선택한 구조는 전적으로 귀하에게 달려 있습니다! 우리 중 일부는 TFS의 구조를 복제했으며, 다른 일부는 완전히 평평한 계층 구조를 가지고 있습니다 ... 이것은 하루가 끝나면 변화를 가져 오지 않습니다.