当构建服务器被视为金矿时，我们应该怎么做？

Question

一年前，我开始在我们的构建机器（TFS2008）上创建一些自动构建。与完全规模的TDD（我们仍然有很多旧的遗留代码）相结合并不是那么多，而是能够在早期检测到构建是否被破坏。另一个目标是尽量减少包装/部署工作。

到目前为止，这种方法运作良好，但最近一些同事开始将构建服务器视为快速发布的金矿，并且测试过程似乎不那么经常被优先考虑。在2-3天内重构我们的一些代码证明了我们的构建服务器上的构建可能会覆盖我们的客户。 ：）

我想我们的构建服务器随着时间的推移已经从开发人员的“一致性工具”转变为服务器生产的软件包，预计将全天候发布。

这显然是一个沟通问题，应该有一套规则。唯一的问题是我不知道从哪里开始。有人有类似的经历吗？

Answer 1

你是对的，这是一个沟通问题。如果您的开发人员和管理人员一直期待发布质量的构建，他们就不会理解构建/测试/发布的过程。

您唯一能做的就是澄清构建服务器的用途：构建的单一集中位置。您需要澄清 build 和 release 之间的区别。构建应始终成功（没有人应该破坏构建）但是创建构建的能力对构建质量或给定构建的适用性没有任何影响。

构建质量通过单元，功能和用户验收测试来衡量。在准备发布版本时，这些测试没有替代品。 不进行这些测试的长期成本远远超过了获得发布的短期利益。

Answer 2

我们的unittestserver进行测试，并标记CVS。然后我们继续构建一个具有ea脚本的构建服务器来创建一个已经为客户安装的版本。然后将此版本安装在测试服务器上，就像它是客户的服务器一样，然后进行测试。

判断您的故事，您希望找到一些脚本或设置，以防止构建服务器被用作“快速发布”服务器。唯一真正的做法是流程。

我们公司的规则：

1. 开发人员检查CVS，如果失败则从unittest服务器收到邮件，并且必须在代码中修复它。无法访问开发人员的构建/测试服务器。
2. 有一位特定的开发人员可以创建一个可以发送给测试部门的版本。
3. 测试部门在其测试服务器上安装该版本并对其进行测试。
4. 测试人员，只有测试人员，可以发布“Go”。
5. 该释放由指定人员完成，该人员也是客户联系人。

正如您所看到的，开发人员与测试人员和客户分开（正式来说）。在实践中，并不是那么严格，但人们需要明白，如果这个过程不到位，客户将获得质量低劣的软件。

客户必须接受教育，“快速”意味着“低质量”。我们可以做到快速，好，或便宜。选择两个。 http://www.sixside.com/fast_good_cheap.asp

Answer 3

我建议所有由内部构建服务器创建的构建在启动画面“内部构建 - 不是为客户”中创建，并且发布构建服务器在官方启动画面。