1.5 候选发布版本

什么是候选发布版本（release candidate）？对于代码的任何一次修改都有被发布出去的可能性。当你问自己“我们这次修改的版本是否应该发布出去”时，得到的答案很可能只是一次臆测的结果而已。然而，恰恰是构建、部署、测试流程能够验证是否可以发布这次修改后的版本。对于“是否可以发布这次修改的版本”这个问题，这一流程会不断让我们增强信心。我们只做很小的修改（无论是新功能，还是修复缺陷，或是提高一些性能），并且验证我们是否有足够高的自信把这个带有本次修改的系统发布出去。为了进一步减少发布风险，我们希望尽可能在最短的时间内完成这个验证过程。

尽管每次修改都可以产生一个能够交给用户的最终产物，但是我们应该首先对每次修改都进行适用性评估。只有这次修改没有缺陷，而且满足由客户定制的验收条件，才能够发布它。

大多数软件发布方法都是在其流程的最后阶段才能识别出可以发布的那些版本。当说到与跟踪（tracking）相关的工作时，这是有些意义的。在写作本书时，Wikipedia上对开发阶段的描述中将“候选发布版本”作为这一流程中的一个步骤进行了说明，如图1-2所示。我们的观点则稍有不同。

图1-2 对于发布候选版本的传统观点

在传统软件开发方法中，通常以较长时间的验证过程来确保软件满足质量要求并实现了全部功能需求，之后才确定能够发布的候选版本。然而，当有全面的自动化测试，并且构建和部署也是自动化过程时，我们在项目后期就不再需要冗长且手工密集型的测试了。在这一阶段应用程序的质量通常也会比较高，手工测试只是用于证实功能完备就行了。

根据我们的经验，直到开发阶段之后才做测试的话，无疑会降低应用程序的质量。最好还是在缺陷被引入时，就发现并将其解决。发现得越晚，修复的成本越高。开发人员已经不记得他们是在实现哪个功能时把缺陷引入的，而这个功能很可能已经发生了变化。直到最后才做测试，这通常意味着没有足够的时间真正地修复缺陷，或者只能修复其中很少的一部分缺陷。因此，我们想尽早地发现并修正这些缺陷，最好是在将其提交到代码库之前。

每次提交代码都可能产生一个可发布的版本

开发人员对代码库的每次修改都应该是以某种方式为系统增加价值。每次代码到版本控制系统的提交都应该是对当前所开发软件的提高或增强。我们如何知道它的正确性呢？唯一的方法就是运行这个软件，看它的行为是否符合我们的期望。大多数项目都将这部分工作推迟到了开发的后期。这就意味着，即使它不能工作，也只有当有人测试或使用这个软件时才能被发现，而此时的修复成本通常会比较高。这个阶段通常称作集成阶段，常常是整个开发过程中最不可预测、最不易管理的阶段。由于集成这件事太痛苦了，所以团队总是推迟集成工作。然而，集成频率越低，集成时我们就会越痛苦。

如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁地去做，而不是回避。因此，我们应该频繁做集成，事实上应该在每次提交修改后都做集成。持续集成这个实践将频繁集成发挥到了极至，而“持续集成”转变了软件开发过程。持续集成会及时检测到任何一次破坏已有系统或者不满足客户验收测试的提交。一旦发生这种情况，团队就立刻去修复问题（这是持续集成的首要规则）。如果能够坚持这个实践，那么软件会一直处于可用状态。假如测试足够全面，且运行测试的环境与生产环境足够相近（甚至相同）的话，那么可以说，你的软件一直处于可发布状态。

我们可以把每次修改都作为一个有可能被发布的候选版本。每次将修改后的代码提交到版本控制系统时，我们都希望它能够通过所有的测试，产生可工作的软件，并能够发布到生产环境中，而这只是我们的一个假设。持续集成系统的职责就是推翻这一假设，证明某个版本并不适合部署到生产环境中。