TeamCity를 통한 어셈블리 버전

StackOverflow https://stackoverflow.com/questions/1223245

문제

SVN 및 TeamCity 빌드 서버를 사용하는 C#/vb.net 프로젝트에서 작업하고 있습니다. 빌드에 의해 수십 개 정도의 어셈블리가 생산됩니다. 어셈블리 버전을 제어하여 모두 일치하고 TeamCity 빌드 레이블과 일치하도록합니다.

TeamCity를 구성하여 빌드 레이블을 사용했습니다

major.minor. {build}. {개정}

메이저와 미성년자가 수동으로 설정 한 상수 인 경우 {개정}은 체크 아웃시 SVN 저장소 버전에 의해 결정되며 {build}는 TeamCity 자동 증가 빌드 카운터입니다. 따라서 예제 빌드 레이블이 될 것입니다

2.5.437.4423

모든 어셈블리 버전이 TeamCity 빌드 레이블과 일치하도록하는 기술은 무엇입니까?

도움이 되었습니까?

해결책

우리는 cruisecontrol.net 및 svn을 사용하고 있습니다. 우리는 그것을 다른 방식으로 운전합니다. 우리는 사용 중입니다 MSBuildCommunityTasks MSBuild 스크립트의 버전 작업 CI 빌드의 버전 번호를 증가시키고 해당 버전 번호를 사용하여 소스 코드를 태그합니다.

편집하다: MSBuild 대상에 대한 자세한 내용을 요청했습니다 ...
우리는 CI 빌드를위한 별도의 스크립트를 사용하고 개발자 빌드에 사용되지 않는 별도의 스크립트를 사용합니다. 우리는 Studio가 프로젝트 파일로 사용하는 MSBuild 파일에서 다른 대상을 사용하려고 시도했지만 스튜디오가 생성 한 파일의 두통과 수동 편집이 필요했습니다.
MSBuild 파일의 구조는 매우 간단합니다.

  1. 추가 조각을 가져옵니다

    <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
    <!-- contains some variables that set project names, paths etc. -->
    <Import Project="Properties.msbuild"/>

  2. 이전 건물 : 새 버전 번호 설정 및 어셈블리 인포 파일을 다시 작성하십시오.

    <Version VersionFile="$(VersionFile)" BuildType="None" RevisionType="Increment">
    <Output TaskParameter="Major" PropertyName="Major" />
    <Output TaskParameter="Minor" PropertyName="Minor" />
    <Output TaskParameter="Build" PropertyName="Build" />
    <Output TaskParameter="Revision" PropertyName="Revision" />
    </Version>

    <!--Modify Assembly Info-->
    <AssemblyInfo CodeLanguage="CS"
    OutputFile="Properties\AssemblyInfo.cs"
    AssemblyTitle="$(TargetAssembly)"
    AssemblyDescription="$(AssemblyDescription) svn:@(SanitizedSvnUrl) revision:$(SvnRevision)"
    AssemblyCompany="Your company name"
    AssemblyProduct="Name of product"
    AssemblyCopyright="Copyright © your company 2009"
    ComVisible="false" Guid="$(WindowGuid)"
    AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)"
    AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)"
    Condition="$(Revision) != '0' " />

  3. 빌드 : 릴리스 모드에서 실제 프로젝트 파일 MSBuild 스크립트 구축

  4. 애프터 빌드 : 우리는 단위 테스트 프로젝트를 실행하고 (다음 단계에서 깨진 빌드에 대한 태그 생성에 대한 가드로서), svninfo 작업 및 일부 RegexReplace 작업을 사용하여 경로 및 태그 이름으로 일부 변수를 설정하고 SVNCopy 작업을 사용하여 생성합니다. 태그.

<SvnCopy UserName="username"
Password="password"
SourcePath="@(SvnTrunkPath)"
DestinationPath="@(SvnTagsPath)/BUILD-$(TargetAssembly)-$(Major).$(Minor).$(Build).$(Revision)" Message="Tagging successful build" />

다른 팁

TeamCity의 AssemblyInfo Patcher 빌드 기능을 사용하는 것이 좋습니다.

http://confluence.jetbrains.net/display/tcd65/assemblyinfo+patcher

VisualStudio에서 프로젝트를 만들고 BuildSteps 페이지에서 빌드 기능을 구성하십시오 (참조 http://confluence.jetbrains.net/display/tcd65/adding+build+features), 그리고 기본 조립 정보를 유지하는 한 작동하면 작동합니다.

이 접근법은 저에게 훌륭하게 작동합니다.

장점 :

  • 개발자는 기계에 솔루션을 구축 할 수 있습니다.
  • .sln 또는 .csproj 파일을 터치 할 필요가 없습니다. 그것은 단지 작동합니다.
  • TeamCity 변수를 사용하면 버전 번호가 다른 프로젝트의 버전 등을 쉽게 일치시킬 수 있습니다.

단점 :

  • 빌드 스크립트가 없기 때문에 TeamCity에서 다른 CI 서버로 쉽게 전환 할 수 없습니다 (그러나 CI 서버를 전환하는 것은 ORM 또는 데이터베이스를 전환하는 것과 같습니다. 매우 가능성이 높고 어쨌든 많은 작업이 필요합니다).

나는 Hamish의 답변을 받아 들인 답변으로 남겨두고 있지만 완전성을 위해 우리가 마침내 채택한 접근 방식을 문서화 할 가치가 있다고 생각했습니다.

TeamCity에서 2 개의 별도 빌드 구성을 유지합니다. 하나는 CI 빌드이고 다른 하나는 변경 사항이있을 때 매주 실행되는 빌드이며 공식 릴리스 빌드입니다. 빌드는 아마도 40 분이 걸리기 때문에 2 구매 방식으로 갔으며 개발자가 변경 사항을 충족시킬 때 빌드 문제에 대한 빠른 피드백을 얻기를 원했습니다. 따라서 CI 빌드는 전체 릴리스 빌드의 하위 집합이지만 모든 코드를 빌드합니다. 버전은 두 빌드 간에도 다릅니다.

  • CI 빌드에는 버전 번호 {major.minor.buildcounter.svnrevision}이 있습니다.
    • BuildCounter는 0부터 시작합니다
    • SVN 저장소에 태그가 없습니다
  • 주간/릴리스 빌드에는 유사한 버전 관리 시스템이 있지만
    • 빌드 카운터는 (major * 1000)에서 시작되므로 메이저가 '8'인 경우 빌드 카운터는 8000에서 시작됩니다.
    • SVN 저장소에서 'build_ {version}'이라는 태그를 만듭니다.

이 다소 임의의 선택의 이유는 CI 빌드와 릴리스 빌드를 명확하고 구별 할 수 있기 때문입니다.

우리는 솔루션의 모든 프로젝트에 포함 된 (소프트 링크)라고 불리는 솔루션 전체 파일을 가지고 있습니다. 파일에는 다음과 같은 내용이 포함됩니다.

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)

따라서 개발자 빌드는 모두 동일한 정적 및 쉽게 식별 가능한 버전 번호를 사용합니다.이 버전 번호는 빌드 서버에서 생성 한 것보다 높아 버전 충돌에서 개발자의 파일이 승리합니다.

빌드 서버에서 우리는 MSBuild 커뮤니티 작업을 통해 기본 컨텐츠를 덮어 쓰는 새로운 어셈블리 버시 니노 포스 파일을 생성합니다. 우리는 TeamCity Build String을 새 버전으로 사용합니다. 이런 식으로, 우리는 다음 3 가지 상황을 쉽게 구별 할 수 있습니다.

  • 개발자의 워크 스테이션에서 수행 된 개인 빌드
  • 빌드 서버에서 수행되는 CI 빌드이지만 해제되지 않아야합니다.
  • SVN 저장소에 태그가 지정된 공식적으로 제재 된 릴리스 빌드

또 다른 비틀기에서, 내가 설정하고 있음에 유의하십시오 AssemblyFileVersion, 아니다 AssemblyVersion. 우리는 어셈블리 버전을 'major.minor.0.0'의 정적 고정 버전 문자열로 강요합니다. 버전 문제에 대해 걱정할 필요없이 버그 수정 릴리스를 발행 할 수 있도록이를 수행합니다. AssemblyFileVersion을 통해 사용자가 어셈블리의 신원의 일부가되지 않고 사용자가 설치 한 빌드를 파악할 수 있습니다.

이것은 이미 받아 들여진 답을 가지고 있지만, 우리가 사용한 아이디어를 추가하고 싶습니다.

대규모 프로젝트의 경우 업데이트 할 조립 정보 파일이 많을 수 있으며, 지속적인 재수인이 발생하면 빌드 스크립트가 업데이트 해야하는 새 파일을 인식하지 못할 위험이 항상 있습니다.

이러한 이유로 실제 버전에 대한 상수를 정의한 간단한 코드 파일을 만들고 모든 프로젝트는이 상수와 미국을 조립 정보 파일에 상속합니다. 그런 다음 빌드 스크립트는 하나의 파일 만 업데이트하면됩니다.

여기서 또 다른 이점은 많은 파일을 거쳐 변경할 필요가 없기 때문에 빌드 프로세스의 속도를 높이고 있다는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top