对我来说，解释持续集成最简单的方法就是用一个简单的例子来示范开发一个小 feature。现在假设我要完成一个软件的一部分功能，具体任务是什么并不重要，我们先假设这个 feature 很小，只用几个小时就可以完成。（我们稍后会研究更大的任务的情况。） 一开始，我将已集成的源代码复制一份到本地计算机。这可以通过从源码管理系统的 mainline 上 check out 一份源代码做到。 如果你用过任何源代码管理系统，理解上面的文字应该不成问题。但如果你没用过，可能会有读天书的感觉。所以我们先快速解释一个这些概念。源代码管理系统将项目的所有源代码都保存在一个“仓库（repository）”中。系统的当前状态通常被称为“mainline”。开发者随时都可以把mainline复制一份到他们自己的计算机，这个过程被称为“check out”。开发者计算机上的拷贝被称为“工作拷贝（working copy）”。（绝大部分情况下，你最终都会把工作拷贝的内容提交到mainline上去，所以两者实际上应该差不多。） 现在我拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。在持续集成中，软件应该包含完善的可自动运行的测试，我称之为自测试代码。这一般需要用到某一个流行的 XUnit 测试框架。 一旦完成了修改，我就会在自己的计算机上启动一个自动化 build。这会将我的工作拷贝中的源代码编译并链接成为一个可执行文件，并在之上运行自动化测试。只有当所有的 build 和测试都完成并没有任何错误时，这个 build 过程才可以认为是成功的。 当我 build 成功后，我就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过 mainline。这时我需要首先把别人的修改更新到我的工作拷贝中，再重新做 build。如果别人的代码和我的有冲突，就会在编译或测试的过程中引起错误。我有责任改正这些问题，并重复这一过程，直到我的工作拷贝能通过 build 并和 mainline 的代码同步。 一旦我本地的代码能通过 build，并和 mainline 同步，我就可以把我的修改提交到源码仓库。 然而，提交完代码不表示就完事大吉了。我们还要做一遍集成 build，这次在集成计算机上并要基于 mainline 的代码。只有这次 build 成功了，我的修改才算告一段落。因为总有可能我忘了什么东西在自己的机器上而没有更新到源码仓库。只有我提交的改动被成功的集成了，我的工作才能结束。这可以由我手工运行，也可以由 Cruise 自动运行。 如果两个开发者的修改存在冲突，这通常会被第二个人提交代码前本地做 build 时发现。即使这时侥幸过关，接下来的集成 build 也会失败掉。不管怎样，错误都会被很快检测出来。此时首要的任务就是改正错误并让 build 恢复正常。在持续集成环境里，你必须尽可能快地修复每一个集成 build。好的团队应该每天都有多个成功的 build。错误的 build 可以出现，但必须尽快得到修复。 这样做的结果是你总能得到一个稳定的软件，它可能有一些 bug，但可以正常工作。每个人都基于相同的稳定代码进行开发，而且不会离得太远，否则就会不得不花很长时间集成回去。Bug被发现得越快，花在改正上的时间就越短。