在分布式架构中，为什么管理版本很困难？

Question

我一次又一次地看到。 UAT测试经理希望新版本能够在星期五之前进行测试。在预测试会议中提出的第一个问题之一是，<！>“我将测试哪个版本，反对？<！>”; （这是一个公平的问题）。房间变得沉默，然后有人会回来，<！>所有组件都有自己的版本，只需右键单击并查看属性...... <！> quot;。

从测试经理的角度来看，这没用。他们想要一个版本/标签/标签跨越一切，告诉他们他们正在做什么。他们希望这些信息很容易获得。

我见过一些解决方案，系统的不同区域的版本存储在数据存储区中，然后显示在主应用程序的框中。问题是，这需要保持。

你看到哪些解决方案可以解决这个问题？

EDIT。分布式系统包括VB6，Classic ASP，VB.Net，C＃，Web Services（跨部门，我们使用的是哪个版本？），SQL Server 2005。

Answer 1

我认为问题在于您和您的测试经理谈到了两件不同的事情。汇编版本非常适合程序集，但是如果您愿意，您的测试经理会使用更高级别的版本，即系统版本<！>。至少那是我对你的帖子的解读。

在这种情况下，您需要做的是将所有不同的组件装配映射到系统版本中。你说的是<！>的一些内容;系统的1.5版本由Foo.Bar.dll v1.4.6和Baz.Qux.dll v2.6.7以及（等等）<！>引用。地狱，在分布式系统中，您可能希望每个服务都有不同的版本，这些版本本身可能由不同版本的.dll组成。您可能会说，例如：<！> quot;系统版本1.5由Foo服务v1.3组成，它由Foo.dll v1.9.3和Bar.dll v1.6.9以及Bar服务v1组成.9，由Baz.dll v1.8.2和Qux.dll v1.5.2以及（等）<！>组成。

这样做的事情通常是组织中软件架构师和/或构建经理的工作。

您可以使用许多工具来处理与您选择的语言无关的此问题。我个人最喜欢的是 Jira ，除了错误跟踪之外，还有很棒的产品版本和路线图支持。

Answer 2

可能想看一下这个页面，它解释了一些方法将一致的版本控制集成到您的构建过程中。

Answer 3

有许多不同的因素导致了这个问题。脱离我的头顶，这是一个：

分布式体系结构的一个好处是，我们通过创建服务和以某种形式发布其接口来获得重用的巨大潜力。那意味着客户端应用程序的发布不一定与底层服务的发布紧密同步。因此，可能会发布一个新版本的业务应用程序，该应用程序使用与其一年使用的相同的旧可靠服务。在这种情况下，我们如何应用单个发布标签？

然而，这是一个公平的问题，但需要一个非平凡的答案才有意义。

Answer 4

除了内部引用之外，不使用基于构建的版本编号。当UAT经理提出问题时，你说<！>“;星期五的* <！>”。

唯一的技巧是确保标签在源代码管理中可靠地发生。

*在此处插入适当的日期戳/标签

Answer 5

我们使用.NET和Subversion。我们所有的应用程序集都共享一个版本号，该版本号源自手动更新的主要和次要版本号以及Subversion版本号（<major>.<minor>.<revision>）。我们有一个预建任务，可以在共享的AssemblyVersionInfo.vb文件中更新此版本号。然后，当测试人员询问版本号时，我们可以给他们完整的3部分编号或只是颠覆版本。我们消耗的库没有变化，或者变化与测试人员无关。