6

我一次又一次地看到这个。UAT 测试经理希望新版本在周五之前准备好进行测试。在预测试会议上提出的第一个问题是，“我将针对哪个版本进行测试？” （这是一个公平的问题）。房间里安静了下来，然后有人会回来说：“所有程序集都有自己的版本，只需右键单击并查看属性...”。

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

我已经看到解决方案，其中系统的不同区域的版本存储在数据存储中，然后显示在主应用程序的关于框上。问题是，这需要维护。

您看到什么解决方案可以解决这个持续存在的问题？

编辑。分布式系统涵盖VB6、Classic ASP、VB.Net、C#、Web Services（跨部门，我们用的是哪个版本？）、SQL Server 2005。

4

5 回答 5

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，除了错误跟踪之外，它还具有出色的产品版本控制和路线图支持。

于 2009-03-03T15:03:08.127 回答
1

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

于 2009-03-03T14:29:15.897 回答
1

有许多不同的事情导致了这个问题。在我的脑海中，这是一个：

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

尽管如此，这是一个公平的问题，但需要一个重要的答案才能有意义。

于 2009-03-03T14:38:29.307 回答
0

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

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

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

于 2009-03-03T14:29:37.427 回答
0

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

于 2009-03-03T14:31:36.813 回答