意外发布的代码生存。如何防止再次发生？

Question

我们最近发生了一起事件，其中一些代码已经发布，但未计划发布。

显然已经检查了行李箱。我觉得这很好，因为你想'提早入住，经常登记'。

然而，在这种情况下，它不应该在下一个版本中发布。

可以采用何种检查/策略/流程来避免代码被过早释放。

在我看来，即使使用持续集成和单元测试，这也是一个人为程序问题？

- 李

Answer 1

修改您的整合程序。

如果“上线”意味着执行某些批处理脚本的人 - 如果再次发生这种情况，请不要感到惊讶。

另外，考虑分支。一个常见的例子可能是使用trunk进行开发，一个单独的分支用于测试（例如，每周合并一次），以及一个最终分支（来自上述测试分支）用于RTC。

这个分支在部署到生产之前，应该进行彻底的测试。

Answer 2

如果源控制软件允许这样的事情你应该有不同的分支。

在这种情况下，您将有一个人负责将已经符合质量条的代码从主分支合并到生产分支。

---

<强>更新 虽然产品特定，但TFS 2008 Branching Guide 2.0提供的指南有很多指南可以应用于能够创建分支的其他源控制软件。

Answer 3

不要从主干构建到生产 - 手动将测试的主干代码合并到生产分支中并从中继续生效。或者正如其他答案所说，在测试过程中使用适合您需求的任何数量的分支和步骤。

此外，通常需要在单独的功能分支中进行大约一天左右的代码更改，直到完成为止。

Answer 4

问题显然不在于检查存储库的代码。你有两个问题：

1）任何应该上线的代码都必须有一个特殊的版本标签或分支或其他任何代码，具体取决于您使用的源代码控制。所以代码上线永远不会与开发中的代码混淆。

2）无论如何，谁是未经测试的代码的蠢货？如果投入使用的人认为您的开发中代码已准备就绪，那么就会严重缺乏沟通。

Answer 5

要继续讨论分支，这是保持版本处理结构化的方法。

我们使用trunk作为主分支，当我们在开发周期中达到某个点时我们不允许提交任何功能（只有错误修正），我们为该版本分支一个新分支（而不是去通过容易出错的合并），并且在我们从它构建版本之前对该分支进行了很好的测试。当然，为了实现这一点，每个程序员都需要在功能冻结日期临近时保持提交的清洁。

Answer 6

  

在我看来，即使是连拍   集成和单元测试这是一个   人类程序问题？

事实上！但是，您应该能够从基础架构获得一些支持，以支持流程的人性化。当您要进行发布时，您应该能够轻松地看到所有提交的内容以及所有相关问题。这是持续整合的报告方面。 （我会说有four elements（pdf）：构建，部署，测试和报告。）

Answer 7

  

什么样的检查/策略/   过程可以到位以避免   代码正在发布   过早。

我会说任何没有检入主干作为习惯性开发仪式的过程，这意味着除了牛仔编码之外的任何开发模型。

让开发人员尽早办理登机手续并经常进入他们的功能分支，并在时机成熟时将其合并到主干中。

Answer 8

我们构建了一个与subversion一起使用的发布管理器。 www.ReleaseManager.com 因此，我们可以控制问题编号（或错误编号）发布的内容，并且我们可以控制，以便在需要时将内容从发布中删除。现在正在寻找测试网站：）