Assembléia Versioning com TeamCity

https://stackoverflow.com/questions/1223245

11-07-2019
|

Pergunta

Eu estou trabalhando em um C # / VB.Net projeto que usa servidor SVN e construção TeamCity. Uma dúzia de conjuntos são produzidos por meio da formação. Eu quero controlar as versões de montagem de modo que todos eles correspondem para cima e também corresponder ao rótulo TeamCity construção.

Eu configurei TeamCity usar uma etiqueta de construção de

Major.Minor. {Desenvolver}. {Revisão}

Onde Maiores e Menores são constantes que eu definidos manualmente, {Revisão} é determinada pela versão do repositório SVN no check-out e {Desenvolver} é um auto-incremento contador de construção TeamCity. Assim, uma etiqueta de exemplo de construção seria

2.5.437.4423

Quais as técnicas que você sugeriria para garantir que todas as versões de montagem corresponder ao rótulo TeamCity construção?

Solução

Estamos usando CruiseControl.net e SVN. Nós dirigi-lo para o outro lado. Estamos usando a MSBuildCommunityTasks tarefa Versão em um script MSBuild para incrementar o número de versão para CI constrói e usar essa versão número para marcar o código fonte.

EDIT: pediu mais detalhes sobre alvos MSBuild ...
Nós usamos um script separado que é para a construção CI e não é usado para o desenvolvedor cria. Tentamos usar diferentes alvos no MSBuild arquivos que usos estúdio como arquivos de projeto, mas isso tem que ser uma dor de cabeça e necessária a inserção manual de arquivos que estúdio estava gerando.
A estrutura do arquivo MSBuild é bastante simples:

Importar peças extra

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />

<Import Project="Properties.msbuild"/>
BeforeBuild: definir novo número de versão e reescrever o arquivo AssemblyInfo

<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>


<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' " />
Constituição: construir o próprio script MSBuild arquivo de projeto no modo de versão
AfterBuild: corremos nossos projetos de teste da unidade (como um guarda contra a criação de etiquetas para quebrado constrói nas próximas etapas), use as tarefas SvnInfo e algumas tarefas REGEXREPLACE para definir algumas variáveis ??com caminhos e nomes de marcas, e usar a tarefa SvnCopy para criar a tag.

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

Outras dicas

Eu sugiro usar recurso patcher construção AssemblyInfo do TeamCity:

http://confluence.jetbrains.net/display/TCD65/AssemblyInfo+Patcher

Basta criar seus projetos de VisualStudio, configurar o recurso de construção na página BuildSteps (veja http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ), e, enquanto você manter o arquivo AssemblyInfo.cs padrão, ele vai trabalhar.

Esta abordagem está a funcionar muito bem para mim.

Vantagens:

Os desenvolvedores podem construir a solução em suas máquinas.
Você não precisa tocar o .sln ou csproj arquivos. Ele simplesmente funciona.
Usando variáveis ??TeamCity você pode facilmente fazer o número da versão coincidir com a versão de algum outro projeto, etc.

Desvantagens:

Você não pode facilmente mudar para outro servidor CI de TeamCity, porque você não tem um script de construção (mas comutação servidores CI é como mudar ORM ou banco de dados: é muito improvável e vai exigir muito trabalho de qualquer maneira).

Estou deixando a resposta de Hamish como a resposta aceita, mas para ser completo eu pensei que valeria a pena documentar a abordagem que definitivamente aprovado.

Eu mantenho 2 configurações de compilação separadas em TeamCity, uma é a construção CI e outro é uma compilação que é executado semanalmente quando houver qualquer alteração (ou manualmente) e é a nossa compilação de lançamento oficial. Eu fui para a abordagem de dois construir porque a construção leva talvez 40 minutos end-to-end e eu queria que os desenvolvedores obter um feedback rápido sobre quaisquer problemas de compilação quando eles cometem mudanças. portanto, a construção CI é um subconjunto da compilação de lançamento completo, mas ele faz construir todo o código. As difere de versões também entre as duas versões:

A construção CI tem números de versão {Major.minor.BuildCounter.SvnRevision}
- BuildCounter começa a partir de 0
- não marcar o svn repositório
A construção Weekly / Lançamento tem um sistema de controle de versão semelhante, mas
- o contador de construção começa em (Principais * 1000), por isso, se o major é '8', o contador de construção começa a partir de 8000.
- Cria uma tag chamada 'build_ {versão}' no svn repositório

A razão para esta escolha um tanto arbitrária é permitir-nos de forma clara e simplesmente distinguir entre CI constrói e compilações Release.

Temos um arquivo de toda a solução chamada AssemblyVersionInfo que está incluído (soft ligado) em cada projeto na solução. O arquivo contém (em essência) o seguinte:

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)

Assim desenvolvedor cria todos usam o mesmo estática e número da versão prontamente identificáveis, que é maior do que qualquer coisa produzida pelo servidor de compilação de modo que em um conflito de versões, vitórias de arquivo do desenvolvedor.

No servidor construímos, nós nos Tarefas MSBuild comunitários para gerar um novo arquivo AssemblyVersionInfo que substitui o conteúdo padrão. Nós usamos a string TeamCity construção como a nova versão. Desta forma, podemos facilmente distinguir entre as 3 situações seguintes:

A compilação particular realizado na estação de trabalho do desenvolvedor
A CI construção realizada no servidor de compilação, mas que não deve ser liberado
Uma compilação de lançamento oficialmente sancionada, o que é marcado no repositório SVN

Em outra reviravolta, nota que estou a criação AssemblyFileVersion, não AssemblyVersion. Forçamos nossas versões de montagem para ser uma estática, corda versão fixa do 'Major.Minor.0.0'. Fazemos isso para que nós somos capazes de emitir correção de bug lançamentos sem ter que se preocupar com versões questões. O AssemblyFileVersion nos permite descobrir o que construir um usuário tenha instalado sem que seja parte da identidade da montagem.

Mesmo que isso já está a ter uma resposta aceita, eu gostaria de acrescentar uma idéia que temos utilizado.

Para projetos grandes pode haver muitas informações assembly arquivos para atualização, e com constante de re-factoring, há sempre o risco de que o script de construção não tem conhecimento de novos arquivos que precisa ser atualizado.

Por isso, criamos um arquivo de código simples que define uma constante para a versão atual e, em seguida, todos os projetos de herdar esse constante e nós no arquivo de informações de montagem. Em seguida, a necessidade script de construção única atualizar um arquivo.

Outra vantagem aqui é que isso também está acelerando o processo de construção um pouco uma vez que não precisa passar por muitos arquivos e mudança.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow