使用热修复对分布式应用程序的程序集进行版本控制

Question

我们正在开发一个具有多个物理层上的组件的应用程序，共享许多程序集，并且每个层都有一些独占的组件。

我想知道典型的版本控制策略是什么，用于发布热修复，或者只是应用程序的几个组件。

我们的问题跟踪软件包含整个产品的版本号。如果当前版本是1.4.5，并且需要热修复程序，则该热修复程序的问题将针对1.4.6发布。受1.4.6修复影响的所有程序集都是1.4.6版本。如果我们只分发这些文件，我们最终会得到一些1.4.5版本的文件和一些1.4.6版本的文件。

一个解决方案可能是重新构建整个应用程序并将其发布为1.4.6，但这将需要重新部署多台机器上的多个组件，并导致没有实际更改的组件出现不必要的停机时间。

人们在这个问题上采取了什么策略？接受一些文件会有不同的版本号是一个问题吗？在过去，我发现这会引起客户(1级)支持团队的困惑。

Answer 1

你提出了一个有趣的问题。

这实际上是一个策略决策，您需要决定您的部署和版本控制策略将是什么，并考虑各种因素的权衡(您已经注意到其中一些因素，例如客户困惑)。

您可以做的一件事是将您的各个层的发布和版本控制解耦，这将允许您在一个层内拥有一致的版本控制，并减少修补程序部署开销。您还需要将公共程序集分解为独立的包和版本。

这可能有些夸张，所以另一种选择是让你的版本更容易掌握。例如，您可以保留版本号的一部分来指示热修复。例如，如果1.4.5.0是官方版本，那么修补程序将是1.4.5.1，这很容易理解为1.4.5官方版本的一部分。

还可以使用其他程序集版本，如AssemblyInformationalVersion为用户存储版本信息。(有关AssemblyInformationalVersion和.NET中的程序集版本控制的更多详细信息，请查看my blog post。)