为什么我们应该尽早并尽可能的频繁发布？
在第二次世界大战期间，苏联军队为了阻止德国入侵，想到了一个放在现在会被动物保护协会全球通缉的办法——训练了一批反坦克犬，当犬只身披zhaya钻进德军坦克身下，引爆zhaya破坏坦克。
不幸的是，这个“天才”的想法在落地时出现了严重的问题。
苏联人在训练军犬时用的是静止的坦克，到了实际战场上，坦克的移动和四周的枪声让军犬们慌不择路，要么被德国人枪杀，要么回到了战壕，反而炸死了苏联士兵。
而且……要知道狗是嗅觉非常灵敏的动物，他们接受苏联训练时坦克中装的是柴油，而德国坦克使用汽油，所以就导致了有些军犬并没有按照苏联人设计的那样在德国坦克下奔跑，而是来到了苏联坦克身下，结果不难想象。
其实苏联人最初的想法是训练犬只进入一个固定的目标，用牙齿拔掉zhayao拉环，然后安全回到战壕，但是没有奏效。可以说，在把反坦克犬部署到战场之前这个项目就失败了，败就败在从未在真正的战场环境下进行测试……
说完二战的故事，再来看持续集成。
持续集成（Continuous Integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试)来验证，从而尽快地发现集成错误。（Martin Fowler）
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量，这里并不是说持续集成能够消除BUG，而是说可以让我们更容易发现BUG并加以改正。
联系上面的故事，假设反坦克犬计划的设计者一开始用一只犬在实际战场上进行测试，或许苏联人就可以在早期发现问题、控制伤亡损失、采取相应的改进……毕竟控制一只狗比控制30只狗，显然是要容易很多。
这就是持续集成最基本的好处。
当然在反坦克犬这个故事中，早期的部署或许会向地方透露战术，但软件开发实践并不是战争。所以，在大多数情况下，我们开发软件应该尽早进行集成，这样做能带来的好处远远超过其潜在的成本。
牛顿曾经说过：“如果说我看得比别人更远些，那是因为我站在巨人的肩膀上”。
没有什么比实际的失败更有参考意义，若想避免在开发中成为“计划反坦克犬的苏联人”，采用持续集成会是一种明智的选择。