Team Foundation Server 모범 사례 "지점" "프로젝트"또는 권한 부여?

Question

좋아, 설치가 간단합니다.

은/우리가 TFS $에서 다음 소스 제어 계층 구조를 가지고 가정 :

/Common 
    /Library1 
    /Library2 
/ProductA 
/ProductB 

지금 소스 제어에 따라서 모든 제품에 대한 팀 거기 권한에 대한 액세스 권한을 부여하기 위해 각 "제품"폴더에 있습니다 해당 특정 팀 (제품 A 팀이 "/ Product A"에 대한 사용 권한을 제공하는 등).

이제 어떤 주어진 제품 (A, B, ...)도 공통 라이브러리를 사용할 수 있습니다. /Common/LibraryX에 대한 기여 (또는 읽기) 권한을 부여합니까? 아니면 LibraryX 용 사본을 ProductY로 분기합니까?

/Common 
    /Library1 
    /Library2 
/ProductA 
    /Library1-ProductA (branched) 
/ProductB 
    /Library1-ProductB (branched) 
    /Library2-ProductB (branched) 

이 "제품 그룹"에서 프리랜서 또는 다른 사람이있을 수 있습니다. 따라서 나는 그들이 볼 수있는 것과 수정할 수있는 것에 대해 엄격하게 통제하고 싶습니다.

가지를 선호합니다. 그러나 배포가 다른 응용 프로그램을 손상시키지 않도록 추가 작업이 많이 필요할 수도 있습니다.

예. Library1이 SharePoint 프로젝트이고 ProductA와 ProductB의 일부가 될 경우 최신 버전을 배포해야합니다 (GAC 배포가 하나 일 수 있기 때문에!). 아무 것도 깨뜨리지 않습니다.

Library1을 배포 프로세스에서 제거하면 더 이상 자동 빌드가 작동하지 않습니다. 좋지도.

Answer 1

NuGet을 사용하는 것이 가장 좋습니다. 공통 라이브러리 각각에 대해 NuGet 패키지를 만들고이를 사용하려면 패키지 관리자를 사용하십시오. 이런 식으로 공통 라이브러리의 "릴리스"가 공식화됩니다. 공용 라이브러리에 기능을 추가하는 경우 릴리스 버전을 증가시키려는 의도적 인 결정을 내릴 수 있으며 클라이언트는 업그레이드 여부를 결정할 수 있습니다.

이 경로를 사용하는 경우에는 각 공용 라이브러리의 분기를 구분하는 것이 가장 좋습니다.