我一次又一次地看到。 UAT测试经理希望新版本能够在星期五之前进行测试。在预测试会议上提出的第一个问题之一是“我将测试什么版本，反对？” （这是一个公平的问题）。房间变得沉默，然后有人会回来，“所有的装配都有自己的版本，只需右键单击并查看属性......”。
从测试经理的角度来看，这没用。他们想要一个版本/标签/标签跨越一切，告诉他们他们正在做什么。他们希望这些信息很容易获得。
我见过一些解决方案，系统的不同区域的版本存储在数据存储区中，然后显示在主应用程序的框中。问题是，这需要保持。
你看到哪些解决方案可以解决这个问题？
EDIT。分布式系统包括VB6，Classic ASP，VB.Net，C＃，Web Services（跨部门，我们使用的是哪个版本？），SQL Server 2005。
答案 0 :(得分：3)
我认为问题在于您和您的测试经理谈到了两件不同的事情。汇编版本非常适合程序集，但是如果您愿意，您的测试经理会谈到更高级别的版本，即“系统版本”。至少那是我对你的帖子的解读。
在这种情况下，您需要做的是将所有不同的组件装配映射到系统版本中。你说的是“系统版本1.5由Foo.Bar.dll v1.4.6和Baz.Qux.dll v2.6.7和（等）组成”。地狱，在分布式系统中，您可能希望每个服务都有不同的版本，这些版本本身可能由不同版本的.dll组成。您可能会说，例如：“系统的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，除了错误跟踪之外，还有很棒的产品版本控制和路线图支持。
答案 1 :(得分：1)
可能希望了解this page，它解释了将一致版本集成到构建过程中的一些方法。
答案 2 :(得分：1)
有许多不同的因素导致了这个问题。脱离我的头顶，这是一个：
分布式体系结构的一个好处是，我们通过创建服务和以某种形式发布其接口来获得重用的巨大潜力。那意味着客户端应用程序的发布不一定与底层服务的发布紧密同步。因此，可能会发布一个新版本的业务应用程序，该应用程序使用与其一年使用的相同的旧可靠服务。在这种情况下，我们如何应用单个发布标签？
然而，这是一个公平的问题，但需要一个非平凡的答案才有意义。
答案 3 :(得分：0)
除了内部引用之外，不使用基于构建的版本编号。当UAT经理问你问“星期五*”时。
唯一的技巧是确保标签在源代码管理中可靠地发生。
*在此处插入适当的日期戳/标签
答案 4 :(得分：0)
我们使用.NET和Subversion。我们所有的应用程序集都共享一个版本号，该版本号源自手动更新的主要和次要版本号以及Subversion版本号（<major>.<minor>.<revision>）。我们有一个预建任务，可以在共享的AssemblyVersionInfo.vb文件中更新此版本号。然后，当测试人员询问版本号时，我们可以给他们完整的3部分编号或只是颠覆版本。我们消耗的库没有变化，或者变化与测试人员无关。