我们正在开发一个应用程序,其中包含多个物理层的组件,共享许多程序集以及每个层都有一些独占。

我想知道发布热修复程序的典型版本控制策略,或者只知道应用程序的一些组件。

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

解决方案可能是以1.4.6重建和释放整个应用程序,但这需要重新部署多台计算机上的多个组件,并导致不会实际更改的组件的不必要停机时间。

人们为此问题制定了哪些策略?只是接受一些文件会有不同的版本号吗?在过去,我发现这会导致与客户(1级)支持团队的混淆。

有帮助吗?

解决方案

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

您需要制定一个政策决策来决定您的部署和版本控制策略,并考虑各种因素(您已经注意到的一些因素,例如客户混淆)的权衡。

您可以做的一件事是分离各个层的发布和版本控制,这样您就可以在一个层中实现一致的版本控制,从而降低修补程序部署开销。您还需要将公共程序集分解为单独的程序包和版本,而且也是独立的。

这可能有点矫枉过正,因此另一种方法是让您的版本控制更容易掌握。例如,您可以保留部分版本号以指示修补程序。例如,如果1.4.5.0是正式版本,则修补程序将为1.4.5.1,这很容易理解为1.4.5正式版本的一部分。

您还可以使用其他程序集版本(例如 AssemblyInformationalVersion )来存储用户的版本信息。 (有关<的详细信息,请查看我的博客文章。代码> AssemblyInformationalVersion 和.NET中的程序集版本。)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top