Versiones de ensamblaje con TeamCity

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

Pregunta

Estoy trabajando en un proyecto C # / VB.Net que usa SVN y el servidor de compilación TeamCity. La construcción produce una docena de ensamblajes. Quiero controlar las versiones de ensamblaje para que todas coincidan y también coincidan con la etiqueta de compilación de TeamCity.

He configurado TeamCity para usar una etiqueta de compilación de

  

Major.Minor. {Build}. {Revision}

Cuando Major y Minor son constantes que configuro manualmente, {Revisión} está determinada por la versión del repositorio SVN al finalizar la compra y {Build} es un contador de compilación de incremento automático de TeamCity. Entonces, una etiqueta de compilación de ejemplo sería

  

2.5.437.4423

¿Qué técnicas sugeriría para garantizar que todas las versiones de ensamblaje coincidan con la etiqueta de compilación de TeamCity?

¿Fue útil?

Solución

Estamos usando CruiseControl.net y SVN. Lo manejamos hacia el otro lado. Estamos utilizando la tarea MSBuildCommunityTasks Versión en un script MSBuild para incrementar el número de versión para las compilaciones de CI y usar esa versión número para etiquetar el código fuente.

EDITAR: solicitó más detalles sobre los objetivos de MSBuild ...
Usamos un script separado que es para la compilación de CI y no se usa para las compilaciones de desarrollador. Intentamos usar diferentes objetivos en los archivos MSBuild que Studio usa como archivos de proyecto, pero esto resultó ser un dolor de cabeza y requirió la edición manual de los archivos que Studio estaba generando.
La estructura del archivo MSBuild es bastante sencilla:

  1. Importar piezas adicionales

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

  2. BeforeBuild: establezca un nuevo número de versión y reescriba el archivo 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>

    <!--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. Build: construye el archivo de proyecto real MSBuild script en modo de lanzamiento

  4. AfterBuild: ejecutamos nuestros proyectos de prueba unitaria (como protección contra la creación de etiquetas para compilaciones rotas en los siguientes pasos), usamos las tareas SvnInfo y algunas tareas RegexReplace para configurar algunas variables con rutas y nombres de etiquetas, y use la tarea SvnCopy para crear la etiqueta.

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

Otros consejos

Sugeriría utilizar la función de compilación del parche AssemblyInfo de TeamCity:

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

Simplemente cree sus proyectos desde VisualStudio, configure la función de compilación en la página BuildSteps (consulte http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ), y siempre que mantenga el archivo AssemblyInfo.cs predeterminado, funcionará.

Este enfoque funciona muy bien para mí.

Ventajas:

  • Los desarrolladores pueden construir la solución en sus máquinas.
  • No necesita tocar los archivos .sln o .csproj. Simplemente funciona.
  • Al usar las variables de TeamCity, puede hacer que el número de versión coincida fácilmente con la versión de otro proyecto, etc.

Desventajas:

  • No puede cambiar fácilmente a otro servidor CI desde TeamCity porque no tiene un script de compilación (pero cambiar los servidores CI es como cambiar ORM o base de datos: es muy poco probable y requerirá mucho trabajo de todos modos).

Dejo la respuesta de Hamish como la respuesta aceptada, pero para completar, pensé que valdría la pena documentar el enfoque que finalmente adoptamos.

Mantengo 2 configuraciones de compilación separadas en TeamCity, una es la compilación de CI y otra es una compilación que se ejecuta semanalmente cuando hay cambios (o manualmente) y es nuestra compilación de lanzamiento oficial. Elegí el enfoque de dos compilaciones porque la compilación lleva unos 40 minutos de principio a fin y quería que los desarrolladores recibieran una respuesta rápida sobre cualquier problema de compilación cuando cometan cambios. La compilación de CI, por lo tanto, es un subconjunto de la compilación de lanzamiento completo, pero construye todo el código. El control de versiones también difiere entre las dos compilaciones:

  • La compilación de CI tiene números de versión {Major.minor.BuildCounter.SvnRevision}
    • BuildCounter comienza desde 0
    • no etiqueta el repositorio svn
  • La versión semanal / Release tiene un sistema de versiones similar, pero
    • el contador de compilación comienza en (Major * 1000), por lo que si Major es '8', el contador de compilación comienza en 8000.
    • Crea una etiqueta llamada 'Build_ {Version}' en el repositorio svn

La razón de esta elección algo arbitraria es permitirnos distinguir clara y simplemente entre las compilaciones de CI y las compilaciones de lanzamiento.

Tenemos un archivo de toda la solución llamado AssemblyVersionInfo que se incluye (enlace suave) en cada proyecto de la solución. El archivo contiene (en esencia) esto: 

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)

Por lo tanto, las compilaciones de desarrolladores utilizan el mismo número de versión estático y fácilmente identificable, que es más alto que cualquier otro producido por el servidor de compilación, de modo que en un conflicto de versiones, el archivo del desarrollador gana.

En el servidor de compilación, usamos MSBuild Community Tasks para generar un nuevo archivo AssemblyVersionInfo que sobrescribe el contenido predeterminado. Usamos la cadena de compilación de TeamCity como la nueva versión. De esta manera, podemos distinguir fácilmente entre las siguientes 3 situaciones:

  • Una compilación privada realizada en la estación de trabajo del desarrollador
  • Una compilación de CI realizada en el servidor de compilación pero que no debe publicarse
  • Una versión de lanzamiento oficialmente sancionada, que está etiquetada en el repositorio Svn

En otro giro, tenga en cuenta que estoy configurando AssemblyFileVersion, no AssemblyVersion. Obligamos a nuestras versiones de ensamblaje a ser una cadena de versión estática y fija de 'Major.Minor.0.0'. Hacemos esto para poder emitir versiones de corrección de errores sin tener que preocuparnos por los problemas de versiones. AssemblyFileVersion nos permite descubrir qué compilación ha instalado un usuario sin que sea parte de la identidad del ensamblado.

Aunque esto ya tiene una respuesta aceptada, me gustaría agregar una idea que hemos usado.

Para proyectos grandes puede haber muchos archivos de información de ensamblaje para actualizar, y con la refactorización constante siempre existe el riesgo de que el script de compilación no esté al tanto de los nuevos archivos que deben actualizarse.

Por esta razón, hemos creado un archivo de código simple que define una constante para la versión real y luego todos los proyectos heredan esta constante y nosotros en el archivo de información de ensamblaje. Luego, el script de compilación solo necesita actualizar un archivo.

Otro beneficio aquí es que esto también está acelerando el proceso de compilación, ya que no necesita pasar por muchos archivos y cambios.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top