Die Versionierung ist etwas, das mich sehr begeistert und ich habe lange versucht, ein einfach zu verwendendes Versionierungssystem zu entwickeln. Aus dem, was Sie bereits in Ihrer Frage gesagt haben, geht hervor, dass Sie einen wichtigen Punkt verstanden haben: Die Versionsnummern der Baugruppe sind nicht gleichbedeutend mit der Produktversion. Einer ist technisch und der andere vom Geschäft bestimmt.
Im Folgenden wird davon ausgegangen, dass Sie eine Form der Quellcodeverwaltung und einen Build-Server verwenden. Für den Kontext verwenden wir TeamCity und Subversion / Git. TeamCity ist für eine kleine (10) Anzahl von Projekten kostenlos und ein sehr guter Build-Server, aber es gibt andere, von denen einige völlig kostenlos sind.
Was eine Versionsnummer bedeutet
Was eine Version für eine Person bedeutet, kann für eine andere Person etwas anderes bedeuten. Die allgemeine Struktur ist Dur, Moll, Makro, Mikro. Ich betrachte eine Versionsnummer so, dass sie in zwei Teile zerlegt wird. In der ersten Hälfte werden die Hauptversion (Major) und alle wichtigen Aktualisierungen (Minor) beschrieben. Die zweite Hälfte zeigt an, wann es erstellt wurde und wie die Quellcodeversion war. Versionsnummern bedeuten je nach Kontext auch unterschiedliche Dinge, sei es eine API, eine Web-App usw.
Major. Minor. Build.Revision
Revision Dies ist die Nummer, die der Quellcodeverwaltung entnommen wurde, um zu identifizieren, was tatsächlich erstellt wurde.BuildDies ist eine ständig wachsende Zahl, mit der ein bestimmter Build auf dem Build-Server gefunden werden kann. Dies ist eine wichtige Zahl, da der Build-Server möglicherweise dieselbe Quelle zweimal mit einem anderen Parametersatz erstellt hat. Durch die Verwendung der Build-Nummer in Verbindung mit der Quellennummer können Sie identifizieren, was und wie erstellt wurde.MinorDies sollte sich nur ändern, wenn die öffentliche Schnittstelle erheblich geändert wurde. Wenn es sich beispielsweise um eine API handelt, kann der konsumierende Code dennoch kompiliert werden? Diese Nummer sollte auf Null zurückgesetzt werden, wenn sich die Hauptnummer ändert.MajorGibt an, auf welcher Version des Produkts Sie sich befinden. Beispielsweise ist der Major aller VisualStudio 2008-Assemblys 9 und VisualStudio 2010 10.
Die Ausnahme von der Regel
Es gibt immer Ausnahmen von der Regel und Sie müssen sich anpassen, wenn Sie auf sie stoßen. Mein ursprünglicher Ansatz basierte auf der Verwendung von Subversion, aber kürzlich bin ich zu Git gewechselt. Quellcodeverwaltung wie Subversion und Source Safe, die ein zentrales Repository verwenden, verfügen über eine Nummer, mit der ein bestimmter Satz von Quellen aus einer bestimmten Zeit identifiziert werden kann. Dies ist bei einer verteilten Quellcodeverwaltung wie Git nicht der Fall. Da Git verteilte Repositorys verwendet, die sich auf jedem Entwicklungscomputer befinden, gibt es keine automatisch inkrementierende Nummer, die Sie verwenden können. Es gibt einen Hack, der die Anzahl der Check-Ins verwendet, aber hässlich ist. Aus diesem Grund musste ich meinen Ansatz weiterentwickeln.
Major. Minor. Macro.Build
Die Versionsnummer ist jetzt weg, der Build wurde an die Stelle verschoben, an der sich die Revision befand, und das Makro wurde eingefügt. Sie können das Makro so verwenden, wie Sie es für richtig halten, aber die meiste Zeit lasse ich es in Ruhe. Da wir TeamCity verwenden, können die aus der Versionsnummer verlorenen Informationen im Build gefunden werden. Dies bedeutet, dass es sich um einen zweistufigen Prozess handelt, aber wir haben nichts verloren und sind ein akzeptabler Kompromiss.
Was einstellen
Das erste, was zu verstehen ist, ist, dass die Assembly-Version, die Dateiversion und die Produktversion nicht übereinstimmen müssen. Ich befürworte nicht, unterschiedliche Zahlengruppen zu haben, aber es erleichtert das Leben erheblich, wenn kleine Änderungen an einer Assembly vorgenommen werden, die keine öffentlichen Schnittstellen betreffen, die Sie nicht gezwungen sind, abhängige Assemblys neu zu kompilieren. Ich gehe damit um, indem ich nur die Haupt- und Nebenzahlen in der Assembly-Version, aber alle Werte in der Dateiversion festlege. Beispielsweise:
- 1.2.0.0 (AssemblyVersion)
- 1.2.3.4 (FileVersion)
Auf diese Weise können Sie Hotfixes bereitstellen, die den vorhandenen Code nicht beschädigen, da die Assemblyversionen nicht übereinstimmen. Sie können jedoch die Revision / den Build einer Assembly anhand der Versionsnummer der Datei anzeigen. Dies ist ein gängiger Ansatz, der bei einigen Open Source-Assemblys zu sehen ist, wenn Sie sich die Assemblydetails ansehen.
Sie als Teamleiter müssten dafür verantwortlich sein, die untergeordnete Zahl zu erhöhen, wenn jemals eine Änderung erforderlich ist. Eine Lösung, um eine erforderliche Änderung an einer Schnittstelle einzuführen, ohne den vorherigen Code zu beschädigen, besteht darin, die aktuelle als veraltet zu markieren und eine neue Schnittstelle zu erstellen. Dies bedeutet, dass vorhandener Code gewarnt wird, dass die Methode veraltet ist und jederzeit entfernt werden kann, Sie jedoch nicht sofort alles beschädigen müssen. Sie können dann die veraltete Methode entfernen, wenn alles migriert wurde.
Wie man es zusammen verdrahtet
Sie können alle oben genannten Schritte manuell ausführen, dies wäre jedoch sehr zeitaufwändig. Im Folgenden wird der Prozess automatisiert. Jeder Schritt ist ausführbar.
- Entfernen Sie die Attribute
AssemblyVersionund AssemblyFileVersionaus allen AssemblyInfo.cs-Projektdateien.
- Erstellen Sie eine allgemeine Assembly-Info-Datei (nennen Sie sie VersionInfo.cs) und fügen Sie sie allen Ihren Projekten als verknüpftes Element hinzu.
- Hinzufügen
AssemblyVersionund AssemblyFileVersionAttribute zur Version mit den Werten "0.0.0.0".
- Erstellen Sie ein MsBuild-Projekt, das Ihre Lösungsdatei erstellt.
- Fügen Sie vor dem Build eine Aufgabe hinzu, die die VersionInfo.cs aktualisiert. Es gibt eine Reihe von Open Source-MsBuild-Bibliotheken, die eine AssemblyInfo-Task enthalten, mit der die Versionsnummer festgelegt werden kann. Stellen Sie es einfach auf eine beliebige Zahl ein und testen Sie es.
- Fügen Sie eine Eigenschaftsgruppe hinzu, die eine Eigenschaft für jedes der Segmente der Build-Nummer enthält. Hier stellen Sie Dur und Moll ein. Die Build- und Revisionsnummer sollte als Argument übergeben werden.
Mit Subversion:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
Hoffentlich war mir klar, aber es geht um viel. Bitte stellen Sie Fragen. Ich werde jedes Feedback nutzen, um einen prägnanteren Blog-Beitrag zusammenzustellen.