Assemblaggio delle versioni con TeamCity

Question

Sto lavorando a un progetto C # / VB.Net che utilizza server di build SVN e TeamCity. Una dozzina di assiemi sono prodotti dalla build. Voglio controllare le versioni dell'assembly in modo che corrispondano tutte e corrispondano anche all'etichetta di build di TeamCity.

Ho configurato TeamCity per utilizzare un'etichetta build di

  

Major.Minor. {Build}. {} Revisione

Laddove Major e Minor sono costanti che ho impostato manualmente, {Revision} è determinato dalla versione del repository SVN al momento del pagamento e {Build} è un contatore di build con incremento automatico di TeamCity. Quindi un esempio di etichetta di costruzione sarebbe

  

2.5.437.4423

Quali tecniche suggeriresti per garantire che tutte le versioni dell'assieme corrispondano all'etichetta di build di TeamCity?

Answer 1

Stiamo usando CruiseControl.net e SVN. Lo guidiamo dall'altra parte. Stiamo usando l'attività MSBuildCommunityTasks in uno script MSBuild per incrementare il numero di versione per build CI e usare quella versione numero per taggare il codice sorgente.

MODIFICA: richiesto per maggiori dettagli sugli obiettivi di MSBuild ...
Usiamo uno script separato che è per la build CI e non è usato per le build sviluppatore. Abbiamo provato a utilizzare target diversi nei file MSBuild che Studio utilizza come file di progetto, ma questo doveva essere un mal di testa e richiedeva la modifica manuale dei file che Studio stava generando.
La struttura del file MSBuild è piuttosto semplice:

1. Importa pezzi extra

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

2. BeforeBuild: imposta il nuovo numero di versione e riscrivi il file 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: crea il file di progetto attuale MSBuild script in modalità di rilascio

4. AfterBuild: eseguiamo i nostri progetti di unit test (come protezione contro la creazione di tag per build non funzionanti nei passaggi successivi), utilizziamo le attività SvnInfo e alcune attività RegexReplace per impostare alcune variabili con percorsi e nomi di tag e utilizzare l'attività SvnCopy per creare il tag.

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

Answer 2

Suggerirei di utilizzare la funzione di creazione del patcher AssemblyInfo di TeamCity:

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

Crea i tuoi progetti da VisualStudio, configura la funzione di compilazione nella pagina BuildSteps (vedi http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ) e finché manterrai il file AssemblyInfo.cs predefinito, funzionerà.

Questo approccio funziona alla grande per me.

I vantaggi:

• Gli sviluppatori possono creare la soluzione nei loro computer.
• Non è necessario toccare i file .sln o .csproj. Funziona e basta.
• Usando le variabili di TeamCity puoi facilmente far corrispondere il numero di versione alla versione di qualche altro progetto, ecc.

Svantaggi:

• Non è possibile passare facilmente a un altro server CI da TeamCity perché non si dispone di uno script di compilazione (ma cambiare server CI è come cambiare ORM o database: è molto improbabile e richiederà comunque molto lavoro).

Answer 3

Lascio la risposta di Hamish come risposta accettata, ma per completezza ho pensato che valesse la pena documentare l'approccio che abbiamo finalmente adottato.

Mantengo 2 configurazioni di build separate in TeamCity, una è la build CI e un'altra è una build che viene eseguita settimanalmente in caso di modifiche (o manualmente) ed è la nostra build ufficiale di rilascio. Ho optato per l'approccio a due build perché la build richiede forse 40 minuti end-to-end e volevo che gli sviluppatori ricevessero un rapido feedback su eventuali problemi di build quando commettono modifiche. La build CI è quindi un sottoinsieme della build di rilascio completo ma crea tutto il codice. Il controllo delle versioni differisce anche tra le due build:

• La build CI ha numeri di versione {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter inizia da 0
  • non tagga il repository svn
• La build Weekly / Release ha un sistema di versioning simile, ma
  • il contatore di build inizia da (Maggiore * 1000), quindi se Major è '8', il contatore di build inizia da 8000.
  • Crea un tag chiamato 'Build_ {Version}' nel repository svn

Il motivo di questa scelta alquanto arbitraria è consentirci di distinguere chiaramente e semplicemente tra build CI e build Release.

Abbiamo un file a livello di soluzione chiamato AssemblyVersionInfo che è incluso (soft link) in ogni progetto nella soluzione. Il file contiene (in sostanza) questo:

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)

Quindi tutte le build degli sviluppatori usano lo stesso numero di versione statico e facilmente identificabile, che è superiore a qualsiasi cosa prodotta dal server di build in modo che in un conflitto di versione vince il file dello sviluppatore.

Sul server di compilazione, usiamo MSBuild Community Task per generare un nuovo file AssemblyVersionInfo che sovrascrive il contenuto predefinito. Usiamo la stringa di build di TeamCity come nuova versione. In questo modo, possiamo facilmente distinguere tra le seguenti 3 situazioni:

• Una build privata eseguita sulla workstation dello sviluppatore
• Una build CI eseguita sul server build ma che non deve essere rilasciata
• Una build di rilascio sanzionata ufficialmente, che è taggata nel repository Svn

In un'altra svolta, nota che sto impostando AssemblyFileVersion, non AssemblyVersion. Forziamo le nostre versioni di assembly in modo che siano una stringa di versione fissa statica di "Major.Minor.0.0". Facciamo così in modo che siamo in grado di emettere rilasci di bug fix senza doversi preoccupare di problemi di versioning. AssemblyFileVersion ci consente di capire quale build ha installato un utente senza far parte dell'identità dell'assembly.

Answer 4

Anche se questa ha già una risposta accettata, vorrei aggiungere un'idea che abbiamo usato.

Per i progetti di grandi dimensioni potrebbero essere disponibili molti file di informazioni sull'assembly da aggiornare e con il costante factoring c'è sempre il rischio che lo script di build non sia a conoscenza di nuovi file che devono essere aggiornati.

Per questo motivo abbiamo creato un semplice file di codice che definisce una costante per la versione attuale e quindi tutti i progetti ereditano questa costante e noi nel file di informazioni dell'assembly. Quindi lo script di build deve aggiornare solo un file.

Un altro vantaggio qui è che questo sta anche accelerando un po 'il processo di compilazione poiché non ha bisogno di passare attraverso molti file e cambiare.