Modular TeamBuilds

3 개의 TFS 빌드 (2 Dev 및 1 Cert)가 있습니다.Modular TeamBuilds

공통 항목을 변경할 때마다 3 개의 파일을 편집 할 필요가 없도록 빌드를 모듈화하고 싶습니다.

내가 가지고있는 문제는 팀 빌드에 의해 TeamBuildTypes 아래의 빌드 폴더에있는 항목 만 자동으로 검색된다는 것입니다. 내 빌드 프로세스에서 다른 파일을 가져 오는 코드를 넣을 수는 있지만 너무 늦었습니다.

여기에 내가 가진 시나리오가 있습니다. 필자는 공통 작업을위한 "공통"위치를 만듭니다. 나는 가서 그 파일을 수정했다. 빌드 프로세스가 다운로드로 알릴 때까지 파일이 다운로드되지 않기 때문에 너무 늦게 검색됩니다 (이미 가져 오기가 발생했으며 MSBuild 프로세스가 빌드 대상을 메모리에 구성했습니다).

빌드 작업 공간에 추가하는 방법에 대해 생각했지만 소스 가져 오기 대상 (너무 늦었습니다)에서 검색됩니다.

나는 나 파일을 복제 또는 소스 제어를 사용하지 않을 필요가 없습니다 솔루션을 볼 수 없습니다 ...

어떤 아이디어가?

출처

2009-06-10 Vaccano

팀 빌드 2008에서이 문제에 대한 "이상적인"해결책이 없기 때문에 가장 좋은 방법은 빌드 머신의 일반적인 내용을 에 저장하고 C:\Program Files\MSBuild으로 해결 한 다음 거기에서 참조하는 것입니다.

빌드 구성은 당신이 할 수 매우 비슷한 경우 :

포인트 단일 구성 폴더에 빌드 정의의 모든.
공통 빌드 논리를 TFSBuild.proj에 넣습니다.
TFSBuild.proj 하단에 <Import Project="TFSBuild.$(BuildDefinitionName).proj" />을 추가하십시오.
TFSBuild의 빌드 정의마다 다른 구성을 추가하십시오. <BuildDefinitionName>.proj. C로 확인

출처

2009-06-11 03:47:24

당신의 최선의 선택은 $에서 빌드 시스템에서 일반적인 물건을 넣어하는 것입니다 (MSBuildExtensionsPath) : \ 프로그램 파일 \ MSBuild를

나는 아이디어를 싫어한다 "마법"위치에 의존하는 것. 당신은 자동으로 팀 빌드로 검색됩니다 (TeamBuildTypes 아래) 빌드 폴더에

항목 만 ... 단지 동기화 빌드 스크립트를 유지하기 위해 2 차 배포 + QA 프로세스를 필요로 끝낸다.

는 일종의 절름발이, 인정 하듯이,하지만 난 그것을 실천의 주요 한계로 발견하지 않았습니다.

$/TeamProject 
    |- Dev 
     |- Module1 
     |- Module2 
     ... 
     Solution1.sln 
     Solution2.sln 
     |- TeamBuild 
      |- 3rdparty 
       MSBuild.Community.Tasks.dll 
       MSBuild.Community.Tasks.targets 
       RandomScriptOffTheWeb1.targets 
       ... 
      |- SrcSrv     
       srcsrv.ini 
       ... 
      |- SymStor 
       dbghelp.dll 
       ... 
      Common.targets 
      TFSBuild.proj 
      TFSBuild.Common.targets 
      TFSBuild.Config1.targets 
      ... 
      UtilityScript1.ps1 
      ... 
    |- Main   
     ... 
     |- TeamBuild 
     ... 
    |- Release 
     ...

Common.targets 모든 * .csproj (등) 파일을 가져옵니다 : 여기 내 TeamBuild 폴더에서 간단하게 살펴 보자.제 3 자 작업을 모두 가져오고 다양한 전역 속성/항목을 초기화하고 참조 경로를 설정합니다.

TFSBuild.proj는 $ (BuildDefinition)에 조절에 의해 다음 Common.targets, TFSBuild.proj, 설정 파일의 다음 하나를 가져옵니다. 그런 식으로 좀 더 구체적으로 작업/속성/등을 항상 덜 구체적인 파일에서 덮어 씁니다. 그럼에도 불구하고,이 짧은 파일은 내가 제한적이라고 느끼는 곳 중 하나입니다 : 빌드 이름을 프로그래밍 방식으로 파일 이름에 매핑하는 것이 훨씬 더 좋지만 MSBuild는 [런타임] 대상에 설정된 속성에 [선언적] 가져 오기를 의존하게하지 않습니다. .

TFSBuild.Config * .targets 파일은 대부분의 경우, 속성을 설정; "진짜"일은 없다. 이 팀은 (다른 곳에서 구현) 내 사용자 지정 대상이 작동하는 방법을 제어 내가 변수화 할 특성, 플러스 다른 빌드 포함한다.

TFSBuild.Common.targets은 크기 순서에 의해 가장 긴 파일입니다. 여기에서 나는 팀 모두 좋은 기본값을 가진 속성을 구축 AfterDropBuild 같은 목표를 무시하고 조건부로 구성 * 파일에 설정되어 무엇을 기반으로 실행 내 자신 만의 목표를 많이 정의 구성합니다.

참고 : 나는 분명히에 recursive download option을 가지고 있지만 그것이 반드시 필요한 것은 아닙니다. 빌드 depedencies를 하위 폴더로 구분하는 것은 무엇보다도 미학을위한 것입니다.

출처

2009-06-12 05:24:06

답변

관련 문제