Montage Versionierung mit Teamcity

https://stackoverflow.com/questions/1223245

11-07-2019
|

Frage

Ich arbeite an einem C # / VB.Net Projekt, das SVN und Teamcity Build-Server verwendet. Ein Dutzend oder so Baugruppen werden von der Build hergestellt. Ich möchte die Montage Versionen steuern, so dass sie alle zusammenpassen und auch die Teamcity Build-Label entsprechen.

Ich habe Teamcity konfiguriert ist, ein Build-Label von

zu verwenden,

major.minor. {} Erstellen. {Revision}

Wo Dur- und Moll-Konstanten sind, die ich manuell eingestellt, {} Revision vom SVN-Repository-Version an der Kasse bestimmt wird, und {} Erstellen Sie ist ein Teamcity mit automatischer Erhöhung Zähler bauen. So ein Beispiel Build-Label wäre

2.5.437.4423

Welche Techniken würden Sie, um sicherzustellen, deuten darauf hin, dass alle Montagevarianten der Teamcity Build-Label übereinstimmen?

Lösung

Wir verwenden CruiseControl.net und SVN. Wir fahren es andersrum. Wir sind mit der MSBuildCommunityTasks Version Aufgabe in einem MSBuild-Skript die Versionsnummer zu erhöhen, für CI baut und die Verwendung dieser Version Anzahl, den Quellcode zu markieren.

EDIT: für weitere Einzelheiten auf die Frage MSBuild Ziele ...
Wir verwenden ein separates Skript, das für das CI-Build ist und verwendet wird, nicht für die Entwickler bauen. Wir haben versucht, mit verschiedenen Zielen in der MSBuild-Dateien, die Studio verwendet als Projektdateien, aber das bekam Kopfschmerzen zu sein und die erforderliche manuelle Bearbeitung von Dateien, die Studio wurde zu generieren.
Die Struktur der MSBuild-Datei ist ziemlich einfach:

Import zusätzliche Stücke

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

<Import Project="Properties.msbuild"/>
Before: set neue Versionsnummer und schreiben Sie die Assembly Datei

<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' " />
Körperbau: baut die eigentliche Projektdatei MSBuild-Skript im Release-Modus
Afterbuild: wir unsere Unit-Test-Projekte (als Schutz gegen Tags für gebrochene baut in den nächsten Schritten erstellen) ausführen, verwenden Sie die svninfo Aufgaben und einige RegExReplace Aufgaben einige Variablen einzurichten mit Pfaden und Tag-Namen und verwenden Sie die SvnCopy Aufgabe, den Tag zu erstellen.

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

Andere Tipps

Ich würde vorschlagen, mit Teamcity der Assembly Patcher Build-Funktion:

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

Erstellen Sie einfach Ihre Projekte von Visual Studio, konfigurieren Sie die Build-Funktion in der BuildSteps Seite (siehe http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ), und solange Sie die Standard-Datei AssemblyInfo.cs halten, wird es funktionieren.

Dieser Ansatz gut für mich funktioniert.

Vorteile:

Entwickler können die Lösung in ihre Maschinen bauen.
Sie brauchen nicht die SLN oder CSPROJ Dateien zu berühren. Es funktioniert einfach.
Teamcity Variablen Durch die Verwendung können Sie ganz einfach die Versionsnummer machen einige andere Projekt-Version übereinstimmen, etc.

Nachteile:

Sie können nicht einfach wechseln zu einem anderen CI-Server von Teamcity, weil Sie nicht über einen Build-Skript (aber Servern CI Schalt ist wie ORM oder Datenbank vermittlungs es sehr unwahrscheinlich ist, und wird eine Menge Arbeit ohnehin erforderlich).

Ich bin Hamish Antwort als akzeptierte Antwort zu verlassen, aber der Vollständigkeit halber dachte ich, es würde sich lohnen den Ansatz dokumentieren wir schließlich angenommen.

I 2 separate Build-Konfigurationen in Teamcity halten, ist eine der CI Build und ein anderer ist ein Build, die wöchentlich läuft, wenn es irgendwelche Änderungen gibt (oder manuell) und ist unsere offizielle Release-Build. Ich ging für den Zwei-Build Ansatz, weil der Bau vielleicht 40 Minuten dauert End-to-End, und ich wollte Entwickler ein schnelles Feedback zu allen Build-Problemen bekommen, wenn sie Änderungen. Der CI-Build ist daher eine Teilmenge des vollständigen Release-Build aber es hat die gesamten Code zu bauen. Die Versionierung unterscheidet sich auch zwischen den beiden baut:

Die CI Build hat Versionsnummern {Major.minor.BuildCounter.SvnRevision}
- BuildCounter beginnt bei 0
- -Tag nicht die SVN-Repository
Die Weekly / Veröffentlichung Build hat ein ähnliches Versionierungssystem, aber
- der Build-Zähler beginnt bei (Major * 1000), also wenn Dur '8' ist, beginnen die Build-Zähler von 8000.
- Erstellt einen Tag 'Build_ {Version}' im SVN-Repository

Der Grund für diese etwas willkürliche Wahl ist, uns zu erlauben, einfach und klar zu unterscheiden zwischen CI baut und Releasebuilds.

Wir haben eine Lösung weite Datei AssemblyVersionInfo dass genannt enthalten (soft verbunden ist) in jedem Projekt in der Lösung. Die Datei enthält (im Wesentlichen) folgt aus:

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)

So Entwickler baut alle verwenden die gleiche statische und leicht identifizierbar Versionsnummer, die von der Build-Server erzeugt höher als alles andere ist, so dass in einem Versionskonflikt, der Entwickler-Datei gewinnt.

Auf dem Build-Server, wir uns MSBuild Community-Aufgaben eine neue AssemblyVersionInfo-Datei zu erzeugen, die den Standardinhalt überschrieben. Wir verwenden die Teamcity Build-String als die neue Version. Auf diese Weise können wir leicht zwischen den folgenden drei Situationen unterscheiden:

Ein privater Build auf der Entwickler-Workstation ausgeführt
Ein CI Build auf dem Build-Server durchgeführt, aber die freigegeben werden sollen, nicht
Ein offiziell sanktioniert Release-Build, die im SVN-Repository

In einer weiteren Wendung, beachten Sie, dass ich AssemblyFileVersion setze, nicht AssemblyVersion. Wir zwingen unsere Montage Versionen eine statische, feste Version Zeichenfolge von ‚Major.Minor.0.0‘ zu sein. Wir tun dies, damit wir in der Lage sind Bugfix Releases auszustellen, ohne sich um Versionsproblemen zu kümmern. Der Assembly lässt uns herausfinden, was bauen ein Benutzer installiert hat, ohne sie Teil der Versammlung, die Identität zu sein.

Auch wenn dies bereits eine akzeptierte Antwort haben, ich möchte eine Idee fügen wir verwendet haben.

Bei großen Projekten kann es viele Montag Info-Dateien zu aktualisieren und mit konstantem Refactoring besteht immer die Gefahr, dass der Build-Skript nicht bewusst neuer Dateien, die aktualisiert werden muss.

Aus diesem Grunde haben wir eine einfache Code-Datei erstellt, die für die aktuelle Version eine Konstante definiert und dann alle Projekte erben diese Konstante und uns in der Montage-Info-Datei. Dann muss der Build-Skript nur eine Datei aktualisieren.

hier Ein weiterer Vorteil ist, dass dies auch ein wenig den Build-Prozess beschleunigt wird, da sie nicht durch viele Dateien und ändern gehen muss.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow