Assemblage de versions avec TeamCity

Question

Je travaille sur un projet C # / VB.Net qui utilise SVN et le serveur de compilation TeamCity. Une douzaine d'assemblages sont produits par la construction. Je souhaite contrôler les versions d'assemblage de sorte qu'elles correspondent toutes à l'étiquette de génération de TeamCity.

J'ai configuré TeamCity pour utiliser une étiquette de construction de

  

Major.Minor. {Construire}. {Révision}

Où Major et Minor sont des constantes que je définis manuellement, {Revision} est déterminé par la version du référentiel SVN à la caisse et {Build} est un compteur de construction à incrémentation automatique de TeamCity. Donc, un exemple de label de construction serait

  

2.5.437.4423

Quelles techniques proposeriez-vous pour vous assurer que toutes les versions d'assemblage correspondent au label de compilation TeamCity?

Answer 1

Nous utilisons CruiseControl.net et SVN. Nous le conduisons dans l'autre sens. Nous utilisons la tâche MSBuildCommunityTasks dans un script MSBuild pour incrémenter le numéro de version des générations de CI et utiliser cette version. numéro pour baliser le code source.

EDIT: vous avez demandé plus de détails sur les cibles MSBuild ...
Nous utilisons un script distinct, destiné à la génération de CI, et non utilisé pour les générations de développeur. Nous avons essayé d’utiliser différentes cibles dans les fichiers MSBuild que studio utilise en tant que fichiers de projet, mais il s’agissait là d’un casse-tête qui nécessitait l’édition manuelle des fichiers générés par studio.
La structure du fichier MSBuild est assez simple:

1. Importer des pièces supplémentaires

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

2. BeforeBuild: définit le nouveau numéro de version et réécrit le fichier 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: construisez le script MSBuild du fichier de projet actuel en mode édition

4. AfterBuild: nous exécutons nos projets de test unitaire (afin d'éviter la création de balises pour les constructions cassées dans les étapes suivantes), nous utilisons les tâches SvnInfo et certaines tâches RegexReplace pour définir certaines variables avec des chemins et des noms de balises, et utilisez la tâche SvnCopy pour créer la balise.

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

Answer 2

Je suggérerais d'utiliser la fonctionnalité de génération de correctif AssemblyInfo de TeamCity:

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

Créez simplement vos projets à partir de VisualStudio, configurez la fonctionnalité de construction dans la page BuildSteps (voir http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ), et tant que vous conservez le fichier AssemblyInfo.cs par défaut, cela fonctionnera.

Cette approche fonctionne très bien pour moi.

Avantages:

• Les développeurs peuvent créer la solution dans leurs machines.
• Vous n'avez pas besoin de toucher les fichiers .sln ou .csproj. Cela fonctionne.
• En utilisant les variables TeamCity, vous pouvez facilement faire correspondre le numéro de version à la version d'un autre projet, etc.

Inconvénients:

• Vous ne pouvez pas facilement basculer de TeamCity vers un autre serveur de CI, car vous n’avez pas de script de compilation (mais changer de serveur de CI revient à changer de gestionnaire ORM ou de base de données: c’est très improbable et il vous faudra de toute façon beaucoup de travail).

Answer 3

Je laisse la réponse de Hamish comme la réponse acceptée, mais pour être complet, je pensais qu'il serait utile de documenter l'approche que nous avons finalement adoptée.

Je conserve deux configurations de génération distinctes dans TeamCity, l'une est la version CI et l'autre, une version exécutée chaque semaine lorsque des modifications ont été apportées (ou manuellement) et correspond à notre version officielle. J'ai opté pour l'approche en deux versions, car la création prend peut-être 40 minutes de bout en bout et je souhaitais que les développeurs obtiennent un retour rapide sur tous les problèmes de construction lorsqu'ils commettent des modifications. La version de CI est donc un sous-ensemble de la version complète, mais elle construit tout le code. La gestion des versions diffère également entre les deux versions:

• La version de CI a des numéros de version {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter commence à 0
  • ne balise pas le référentiel svn
• La version Weekly / Release a un système de gestion de version similaire, mais
  • le compteur de construction commence à (Major * 1000), donc si Major est à 8, le compteur de construction commence à 8000.
  • Crée une balise appelée "Build_ {Version}" dans le référentiel svn

La raison de ce choix quelque peu arbitraire est de nous permettre de distinguer clairement et simplement les versions CI et les versions Version.

Nous disposons d'un fichier appelé AssemblyVersionInfo à l'échelle de la solution, qui est inclus (liaison logicielle) dans chaque projet de la solution. Le fichier contient (en substance) ceci:

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)

Ainsi, les versions de développement utilisent toutes le même numéro de version statique et facilement identifiable, ce qui est supérieur à tout ce qui est produit par le serveur de génération, de sorte que dans un conflit de gestion de version, le fichier du développeur l'emporte.

Sur le serveur de génération, nous utilisons MSBuild Community Tasks pour générer un nouveau fichier AssemblyVersionInfo qui écrase le contenu par défaut. Nous utilisons la chaîne de compilation TeamCity comme nouvelle version. De cette manière, nous pouvons facilement distinguer les 3 situations suivantes:

• Une version privée réalisée sur le poste de travail du développeur
• Une génération de CI effectuée sur le serveur de génération mais qui ne devrait pas être publiée
• Une version officiellement approuvée, étiquetée dans le référentiel Svn

Dans un autre ordre d'idées, notez que je suis en train de régler AssemblyFileVersion et non AssemblyVersion. Nous forçons nos versions d'assemblage à être une chaîne de version statique et fixe de 'Major.Minor.0.0'. Nous faisons cela pour pouvoir publier des correctifs de bogues sans avoir à nous soucier des problèmes de version. AssemblyFileVersion nous permet de déterminer la construction installée par un utilisateur sans que celle-ci fasse partie de l'identité de l'assembly.

Answer 4

Même si cette réponse a déjà été acceptée, j'aimerais ajouter une idée que nous avons utilisée.

Pour les projets volumineux, il peut y avoir beaucoup de fichiers d'informations d'assemblage à mettre à jour et, avec une refactorisation constante, le script de construction risque toujours de ne pas être informé des nouveaux fichiers à mettre à jour.

Pour cette raison, nous avons créé un fichier de code simple qui définit une constante pour la version actuelle. Tous les projets héritent de cette constante et de nous dans le fichier d’information de l’assemblage. Ensuite, le script de construction n'a besoin que de mettre à jour un fichier.

Un autre avantage ici est que cela accélère également un peu le processus de construction car il n’a pas besoin de parcourir beaucoup de fichiers et d’être modifié.