Brauchen wir Assembly Versionsnummern in einem asp.net mvc Website-Projekt?

Question

Situation - Wir haben eine .net mvc-Lösung mit WCF-Schicht. die Lösung hat etwa 20 ungerade Projekte, die in DLL kompiliert werden. die Website läuft auf SQL Server 2008. wir pflegen die SQL-Skripte in der Lösung Ordner als Versionen. Wir haben also SQL-Skripte, z.B. Version 1.0.0.0 bis, sagen wir, die neueste Version, 3.0.0.1.

Die Lösung wird in TFS quellgesteuert, wir verwenden TFS auch für die Verwaltung der Work Items, Bugs usw. SQL-Skriptdateien befinden sich ebenfalls in TFS

Frage - die Frage ist, ob wir auch Versionsnummern für die assemblierten dlls benötigen. Unsere DLLS sind nicht in irgendeiner Weise ausgesetzt oder von der Außenwelt sind sie nur in der Laufzeit des mvc app. wir nicht die WCF nach außen Clients aussetzen, wieder seine nur von der mvc app verwendet.

der Bereitstellungsprozess ist einfach der neueste Code gegen die neueste Datenbank. Wenn wir also bereitstellen, prüfen wir, welche Version die Datenbank hat und führen ein Tool aus, um sie auf die neueste Version zu aktualisieren, die sich im Datenbankprojekt in der Lösung befindet.

Einer unserer leitenden Architekten ist der Meinung, dass wir die Versionsnummern auch in den Baugruppen beibehalten sollten. Ich sage, dass wir keine Versionsnummern im Code brauchen, weil TFS das verwaltet. Wenn wir etwas freigeben, stellen wir einfach den neuesten Code mit den neuesten Assemblies/Deploy-Paketen bereit.

Ich bin nicht auf die Assembly-Versionen gestoßen, es sei denn, die Assemblies wurden für die Außenwelt freigegeben (wenn Sie wissen, was ich meine).

bitte können Sie vorschlagen... Beachten Sie auch, dass wir keine Funktionsentwicklung betreiben, sondern nur Versionsnummern, damit wir wissen, welche Version eine bestimmte DB hat.

Answer 1

Ich ziehe die Sicherheit vor, die Versionen zu kennen und überprüfen zu können. Wenn es ein Problem mit dem Veröffentlichungsprozess gäbe oder ein Fehler aufträte, der ein Veröffentlichungsproblem zu sein scheint, würde ich das so schnell wie möglich ausschließen wollen. Ich denke auch, dass es so einfach zu implementieren ist, dass man mehr Zeit damit verbringt, darüber zu diskutieren und nachzudenken, als es tatsächlich zu tun, und dass es keine Nachteile gibt, die ich mir vorstellen kann.

Answer 2

In einem ähnlichen Projekt bei meiner Arbeit verwenden wir Versionsnummern.

Jede Übergabe an das Versionskontrollsystem (VCS) bewirkt, dass unser CI-Server ( TeamCity ), um ein neues Artefakt zu erstellen, wobei die Version auf "LATEST" gesetzt wird. Jeder erfolgreiche Build von "LATEST" wird automatisch in unserer Testumgebung bereitgestellt. Theoretisch könnten wir diese "LATEST"-Version auch für die Produktion bereitstellen, aber wir tun es nicht.

Wenn wir eine neue Version für die Produktion bereitstellen wollen, führen wir einen anderen, manuellen Build-Auftrag aus, der eine versionierte Version erstellt (z. B. 1.4.7). Der Build-Auftrag erstellt auch eine SVN "Tag" der aktuellen Codebasis. Damit unsere DLLs die richtige Version haben, verwenden wir TeamCitys AssemblyInfo-Patcher Funktion. Auf diese Weise müssen wir unsere Projekte nicht ständig manuell aktualisieren. AssemblyInfo.cs Dateien. Stattdessen werden sie immer mit Platzhalter-Versionsinformationen wie dieser versehen...

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Diese Zahlen werden während des Builds von TeamCity automatisch aktualisiert. Die versionierten Artefakte (einschließlich aller zugehörigen SQL-Skripte) werden in unserem Verzeichnis "Releases" gespeichert, in dem wir alle Versionen der Codebasis aufbewahren.

Das alles scheint übertrieben zu sein, oder? Nicht wirklich.

Das bringt uns folgende Vorteile...

• Unser Bereitstellungsprozess führt eine wget zu unserer Überwachungsseite, die die Versionsnummer auflistet und sicherstellt, dass die Versionen übereinstimmen (die Version, von der erwartet wird, dass sie bereitgestellt wurde, und die Version, die derzeit auf dem Server läuft). Dies gibt uns die Gewissheit, dass unser Bereitstellungsprozess ordnungsgemäß funktioniert hat.
• Wenn Fehler in der versionierten Version (dem Kandidaten für die Produktionsversion) gefunden werden, können wir SVN checkout das Tag, wenden Sie eine Korrektur an und erstellen Sie eine neue Version, ohne sich um andere Änderungen am Stamm zu kümmern, die die Version gefährden könnten. Es ist schwer, die ganze Zeit "releasefähig" zu bleiben, dies ermöglicht es, dies nicht zu müssen. Obwohl, verstehen Sie mich nicht falsch, es hat seine Vorteile .
• Wenn Probleme mit einer versionierten Version auftreten, die nicht schnell behoben werden können, können Sie immer noch das ältere Artefakt, von dem bekannt ist, dass es funktioniert, erneut bereitstellen. Die Möglichkeit, eine bereitgestellte Version auf eine ältere Version zurückzusetzen, hat uns bei einigen Gelegenheiten definitiv gerettet.
• Wenn in der Produktionsumgebung Fehler gefunden werden, die untersucht werden müssen, steht es uns frei, das gleiche Artefakt in einer unserer Testumgebungen einzusetzen, so dass wir versuchen können, die Probleme außerhalb unserer Produktionsumgebung zu reproduzieren.

Wahrscheinlich gibt es noch mehr Vorteile, die ich im Moment vergesse, aber die obige Liste sollte eine allgemeine Vorstellung von den Möglichkeiten vermitteln, die eine gute Versionsverwaltung mit sich bringt.

Ich würde jedoch davon abraten, die Versionsdateien von mehr als 20 Projekten ständig manuell zu aktualisieren. Das scheint eine Menge Arbeit zu sein, die vor allem Zeitverschwendung ist, weil sie anfällig für menschliche Fehler ist. Was auch immer Sie tun wollen, automatisieren Sie es und überprüfen Sie die Ergebnisse.