Beste build-Prozess-Lösung zur Verwaltung von build-Versionen

Question

Ich führe ein ziemlich Komplexes Projekt mit mehreren unabhängigen Anwendungen.Diese verwenden jedoch ein paar von gemeinsam genutzten Komponenten.Also ich habe einen source-tree Suche etwas wie die unten.

• Mein Projekt
  • Anwendung
  • Freigabe1
  • Shared2
  • Anwendung B
  • Anwendung C

Alle Anwendungen haben Ihre eigene MSBuild-Skript, baut das Projekt und alle freigegebenen Ressourcen, die es braucht.Ich führe auch diese baut auf einem CruiseControl controlled continuous integration-build-server.

Wenn die Anwendungen bereitgestellt werden, bereitgestellt werden, die auf mehreren Servern zu verteilen, laden.Dies bedeutet, dass es extrem wichtig zu verfolgen, was build/revision bereitgestellt wird, auf jedem der anderen Server (wir müssen um die aktuelle version der DLL-version, für Beispiel "1.0.0.68").

Es ist auch wichtig, in der Lage sein, wieder eine revision/build, wurde gebaut, um in der Lage sein, zurück zu Rollen, wenn etwas nicht so klappt, wie gedacht (o ja, das happends ...).Heute sind wir mit SourceSafe für die Quellcodeverwaltung, aber das ändern, wenn wir könnten gute Gründe (SS es tatsächlich funktioniert ok für uns so weit).

Ein weiterer Grundsatz, den wir versuchen zu Folgen, ist, dass es nur code, gebaut und getestet von integration server, setzen wir weiter.

"CrusieControl Build-Label" - Lösung

Wir hatten mehrere Ideen zur Lösung der obigen.Die erste war die kontinuierliche integration server erstellen und lokal bereitstellen Sie das Projekt und testen Sie es (das jetzt).Wie Sie wahrscheinlich wissen, ein erfolgreiches bauen im CruiseControl erzeugt eine build-label, und ich denke, dass wir irgendwie verwenden könnte, dass, um die DLL-version von unsere ausführbaren Dateien (so bauen label 35 würde eine DLL erstellen wie "1.0.0.35" )?Die Idee war auch mit dieser build-label zu label die komplett Quelle Baum.Dann werden wir wohl überprüfen könnte sich von diesem label, und erstellen Sie das bauen, die später auf.

Der Grund für die Zuschreibung der komplette Baum ist nicht nur der eigentliche code der Anwendung (das ist, in einem Ort in den Quellcode), sondern auch alle freigegebenen Elemente (in verschiedenen Orten in den Baum).Also ein erfolgreicher build von "Antrag" würde Etikett ganzen Baum mit dem label "ApplicationA35" zum Beispiel.

Es könnte jedoch ein Problem sein, wenn Sie versuchen, neu zu erstellen, diese zu bauen und Einstellung der DLL-version vor der Bereitstellung als wir dann keinen Zugang zu den CruiseControl generierte build-label mehr.Wenn alle CrusieControl build-labels waren einzigartig für alle Projekte, die wir verwenden könnten nur die Anzahl für die Bezeichnung, aber das ist nicht der Fall (Anwendung A und B könnte zur gleichen Zeit werden auf build 35), so müssen wir noch den Namen der Anwendung in das Etikett.Daher SourceSafe-label "Application35". Wie kann ich dann neu aufbauen, 34, und legen 1.0.0.34 für die DLL-version zahlen einmal Bauten wir bauen 35?

"Revision number" Lösung

Jemand hat mir gesagt, dass Subversion schafft beispielsweise eine Revisionsnummer für den gesamten Quellcode auf jedem check-in – ist dies der Fall?Hat SourceSafe etwas ähnliches? Wenn dies korrekt ist, ist die Idee dann zu packen, die revision-Nummer, wenn Sie immer die Letzte und bauen auf den CruiseControl server.Die Revisionsnummer könnte dann verwendet werden, um die DLL-version number (z.B. "1.0.0.5678").Ich denke, wir könnten dann diese spezifische Version der Subversion, wenn nötig, und dass dann gehören würde, die Anwendung und alle freigegebenen Elemente werden in der Lage, wieder eine bestimmte version aus der Vergangenheit. Sollte das funktionieren, könnte dies auch in unseren Tests mit SourceSafe?

Zusammenfassen

So sind die zwei wichtigsten Voraussetzungen sind:

1. Können track build - /Revisionsnummer der bauen und bereitgestellt DLL.
2. Können Umbau einer letzten revision/bauen, setzen Sie die alten build - /Revisionsnummer auf die ausführbaren Dateien der build (zu erfüllen die mit Anforderung 1).

Wie würden Sie dieses Problem lösen? Was wäre Ihre bevorzugte Methode wie würden Sie es lösen können (oder haben Sie eine ganz andere Idee?)?**Gerne detaillierte Antworten geben.**

Bonus-Frage Was sind der Unterschied zwischen einer Revisionsnummer und einem build-Nummer und, wenn man braucht wirklich beides?

Answer 1

Ihr Schema ist vernünftig und erreichbar VSS (obwohl ich würde vorschlagen, Sie überlegen, eine alternative VSS ist wirklich ein veraltetes Produkt).

Für Ihre "CI" Build - Sie würde die Versionsverwaltung werfen Sie einen Blick auf MSBuild Community-Aufgaben-Projekt der hat eine "Version" Aufgaben.In der Regel haben Sie ein "Version.txt" in deinem source-tree und der MSBuild-task wird, erhöhen Sie die "Release" - Reihe, während der Entwickler die Kontrolle der Major.Minor.Release.Revision (, dass ist, wie ein Kunde von mir wollte).Sie verwenden können, revision, wenn Sie bevorzugen.

Sie hätte dann einen "FileUpdate" Aufgaben zu Bearbeiten, die AssemblyInfo.cs-Datei mit dieser version, und die EXE und "DLL" haben Sie die gewünschte version.

Schließlich die VSSLabel Aufgabe beschriften Sie alle Ihre Dateien entsprechend.

Für Ihre "neu erstellen" Erstellen - Bearbeiten Sie Ihr "Get", um Dateien aus, dass Label, offensichtlich nicht führen Sie die "Version" - Aufgabe (wie Sie AUSWÄHLEN, eine version zu erstellen) und dann die FileUpdate Aufgaben verwenden würden, die Versionsnummer.

Bonus-Frage:

Diese sind alle "wie Sie wollen, Sie zu benutzen" - ich würde verwenden Sie die build-Nummer, sowie die build-Nummer,, dass ist, was ich increment.Wenn Sie mit CI-haben Sie sehr viele builds, die meisten mit nicht die Absicht, jemals bereitstellen von überall.

Die Dur-und Moll sind selbstverständlich - aber die überarbeitung, die ich schon immer für eine "Hotfix" - Anzeige.Ich habe die Absicht, eine "1.3" Version - das wäre in der Realität ein Produkt mit sagen 1.3.1234.0 version.Während der Arbeit an 1.4 - ich habe einen bug gefunden und brauchen einen hot-fix als 1.3.2400.1.Dann, als 1.4 ist fertig - es würde sagen 1.4.3500.0

Answer 2

Ich brauche mehr Platz als Reaktion als Kommentare direkt ermöglicht...

Vielen Dank!Gute Antwort!Was wäre die Unterschied, was wäre besser die Lösung dieses über SubVersion Beispiel?Richard Hallgren (15 Stunden Woche)

Die Probleme mit VSS nichts zu tun haben mit diesem Beispiel (obwohl die "Kennzeichnung" Funktion, die ich glaube, ist ineffizient umgesetzt...)

Hier sind ein paar der Probleme mit VSS

1) Verzweigung ist grundsätzlich nicht möglich 2) Gemeinsame Kasse ist in der Regel nicht verwendet (ich kenne ein paar Leute, die haben mit Erfolg hatten) 3) die Leistung ist sehr schlecht - es ist exteremly "gesprächig" 4), es sei denn, Sie haben eine sehr kleine repository - es ist völlig unzuverlässig, auf den Punkt für die meisten Geschäfte, es ist eine tickende Zeitbombe.

4 - das problem ist, dass VSS wird implementiert, indem das gesamte repository repräsentiert wird, die als "flat files" in der Datei system.Wenn das repository wird über eine bestimmte Größe haben (ich glaube, 4GB, aber ich bin nicht überzeugt, dass die Abbildung), erhalten Sie eine chance für "Korruption".Wie die Größe erhöht die Chancen der Korruption wachsen, bis es beinahe zu einer Gewissheit.

So nehmen Sie einen Blick auf Ihre repository-Größe, und wenn Sie immer in der Gigabyte - würde ich dringend empfehlen, Sie beginnen mit der Planung zu ersetzen, VSS.

Unabhängig - ein google des "VSS Sucks" gibt 30K trifft...Ich denke, wenn Sie nicht über ein alterantive - werden Sie feststellen, es ist die Mühe Wert.

Answer 3

1. Haben CC.net label der erfolgreiche builds
2. jedes Projekt in der Lösung link zu einem gemeinsamen solutioninfo.cs-Datei, die enthält die Montage-und Datei-version-Attribute (entfernen von einzelnen Projekten assemblyinfo.cs)
3. Vor dem Aufbau haben, Tempomat führen Sie eine msbuild-regex ersetzen (von msbuild community-Aufgaben) zum aktualisieren der version Informationen über die cc.net build-label (übergeben als parameter an msbuild-Aufgabe)
4. erstellen Sie die Lösung, führen Sie tests durch, fx cop usw
5. Optional wiederherstellen der Lösung-info-Datei

Das Ergebnis ist, dass alle Assemblys in die cc.net veröffentlicht bauen, haben die gleichen Versionsnummern entsprechen label im Quellcode-repository

Answer 4

UppercuT, kann dies alles mit einer benutzerdefinierten Verpackung task Aufteilung der Anwendungen.Und Holen Sie sich die Versionsnummer der Quelle, könnten Sie denken über Subversion.

Es ist auch unglaublich einfach zu erhalten begonnen.

http://code.google.com/p/uppercut/

Einige gute Erklärungen hier: UppercuT