可重现构建

持续集成 的拥护者普遍认为，构建应该是可重现的。这意味着，在任何时候，您都应该能够获取正在处理的系统的某个旧版本，并以与当时完全相同的方式从源代码构建它。

在我经常参考的构建过程资料中，这并没有作为一个关键实践被提及。我认为这是因为它是一个基本假设——一个被认为是显而易见的事实，不需要解释。

拥有可重现构建的一个主要原因是确保我们能够处理仍在使用的过去版本中的问题。如果我们在一年前向客户发布了软件，而他们现在报告了该软件的一个严重错误，那么能够重新创建该软件以便我们能够提供修复就非常重要。

但是，让我们假设一种情况，您每周都会向托管环境发布软件。让我们还假设您有一个可靠的 持续交付 流程，因此您有信心通过等待下一个版本或（如果真的非常关键）进行早期发布来传播错误修复。那么您还需要可重现的构建吗？

在以下情况下，您不需要：收到错误报告，在最新版本上重现错误，在最新版本上修复错误，然后等待或立即发布。但是在某些情况下，拥有可重现的构建仍然非常方便。

当您收到一个错误报告但无法重现时会发生什么？您是否只是宣布它已修复并继续前进？我对这样的回应不会感到满意。首先，我想确保我真正理解了这个错误——所以我想查看已发布的软件版本，构建它，并确保我可以重现它。为了有信心重现错误，我需要重现构建。此外，即使我相信这个错误在最近的开发过程中被“顺便”修复了，我仍然认为至少缺少一个测试。我想编写该测试，并验证它现在可以通过，而针对已发布的版本则失败。

另一种情况是回归。客户联系您，说现在出现了一个以前没有的错误。这样的错误可能会潜伏很长时间，然后才会突然出现并困扰您。也许它只发生在每月的第一天是星期一的时候。无论哪种方式，您现在都拥有您认为两个月前还可以正常工作但现在有错误的软件。

在这里，拥有可重现的构建使您能够使用 差异调试。您的客户非常确定您在两个月前没有遇到过这个问题，那是构建版本 20000，您现在使用的是构建版本 28000。因此，您检出构建版本 20000，看看该错误是否存在。它不存在，因此您尝试构建版本 24000，也不存在，因此接下来是 26000。不久之后，您就会知道该错误首次出现在修订版 26543 中（现代版本控制系统 具有 功能 可以帮助您做到这一点）。现在，您查看修订版 26543 及其父版本之间的差异——这种方法通常可以更容易地找到错误。