tools team que online engineering code version-control build-automation teamcity

version control - que - Versiones de ensamblaje con TeamCity



teamcity online (4)

Estoy trabajando en un proyecto C # / VB.Net que usa SVN y el servidor de creación TeamCity. Una docena o más de ensamblajes son producidos por la construcción. 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}

Donde Major y Minor son constantes que configuro manualmente, {Revision} está determinada por la versión del repositorio de SVN al momento de la compra y {Build} es un contador de compilación de incremento automático de TeamCity. Así que 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?

A pesar de que 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 actualización constante de factores, siempre existe el riesgo de que el script de compilación no tenga conocimiento 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. Entonces el script de compilación solo necesita actualizar un archivo.

Otra ventaja aquí es que esto también está acelerando un poco el proceso de construcción, ya que no necesita pasar por muchos archivos y cambiar.

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 versión oficial. Me decidí por el enfoque de dos compilaciones porque la compilación toma quizás 40 minutos de extremo a extremo y quería que los desarrolladores obtuvieran una respuesta rápida sobre cualquier problema de compilación cuando comprometen los cambios. La compilación de CI, por lo tanto, es un subconjunto de la compilación de versión completa, pero sí compila todo el código. La versión también difiere entre las dos versiones:

  • 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 compilación semanal / de lanzamiento tiene un sistema de control de versiones similar, pero
    • el contador de compilación comienza en (Mayor * 1000), por lo que si Mayor es ''8'', el contador de compilación comienza desde 8000.
    • Crea una etiqueta llamada ''Build_ {Version}'' en el repositorio svn

El motivo de esta elección un tanto arbitraria es permitirnos distinguir clara y simplemente entre compilaciones de CI y compilaciones de lanzamiento.

Tenemos un archivo para toda la solución llamado AssemblyVersionInfo que se incluye (enlace flexible) 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, todas las compilaciones de desarrollador utilizan el mismo número de versión estática y fácilmente identificable, que es más alto que cualquier cosa producida por el servidor de compilación, por lo 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 TeamCity como la nueva versión. De esta manera, podemos distinguir fácilmente entre las siguientes 3 situaciones:

  • Una construcció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 se debe lanzar
  • Una versión de lanzamiento autorizada oficialmente, 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 fija y estática de ''Major.Minor.0.0''. Hacemos esto para que podamos emitir versiones de corrección de errores sin tener que preocuparnos por los problemas de versión. AssemblyFileVersion nos permite averiguar qué compilación ha instalado un usuario sin que sea parte de la identidad del ensamblado.

Estamos utilizando CruiseControl.net y SVN. Lo conducimos a la inversa. Estamos utilizando la tarea Versión de MSBuildCommunityTasks en una secuencia de comandos de MSBuild para incrementar el número de versión de las compilaciones de CI y usar ese número de versión para etiquetar el código fuente.

EDITAR: Se le pidió 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 utilizar diferentes objetivos en los archivos de MSBuild que Studio usa como archivos de proyecto, pero esto se convirtió en 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 extra

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

  2. BeforeBuild: establece un nuevo número de versión y vuelve a escribir 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. Compilación: genere el archivo de proyecto real MSBuild script en modo de lanzamiento

  4. AfterBuild: ejecutamos nuestros proyectos de prueba de unidad (como una protección contra la creación de etiquetas para compilaciones rotas en los próximos pasos), utilizamos las tareas SvnInfo y algunas tareas RegexReplace para configurar algunas variables con rutas y nombres de etiquetas, y usamos 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" />

Yo sugeriría usar 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 predeterminado de AssemblyInfo.cs , funcionará.

Este enfoque está funcionando 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 utilizar las variables de TeamCity, puede hacer que el número de versión coincida con la versión de otro proyecto, etc.

Desventajas:

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