为什么要读这本书？

现在做任何事情心里都要先想着问个为什么，明确原因和目标。持续集成我们已经推进了好几年了，为什么现在还要读《持续集成》这本书？是因为教练对我们做的持续集成做了评估，按照持续集成成熟度模型，其实只是处于入门级（2级）。要向持续交付这个目标迈进，还有很多改进空间。同时技术教练已经帮兄弟产品线用jenkins打造了持续集成流水线，有些方面已经比推行了几年的我们做得还要好了，我们可不能落后啊。另外，按照母公司敏捷教练的说法，敏捷转型，其他的东西可以没有，但绝对不能没有持续集成。按照CI成熟度模型，第5级优化级的评估标准之一是“CI成为团队⼀切开发、测试⼯作围绕的核⼼，持续关注和保障它的有效和稳定，视保持CI通过⾼于开发新特性”。

感觉对持续集成本身的研究还不够透彻，所以把这本书拿出来读，当然也因为这本书是教练推荐阅读列表中的。

译者序

Grady Booch说，成功的项目有两个特点：一是具有良好的架构愿景，二是采用迭代增量式的开发过程。项目的早期就应该验证架构的可行性，得到系统的“可行走的骨架”。持续集成是成功项目不可或缺的实践。

现在我们的新产品研发其实还比较难做到在一开始就建立一个可行走的骨架并启动持续集成，还需要花费比较长的时间进行初始架构的构建，所以应该还是有很大的提升空间的。这个“可行走的骨架”应该是和用户故事地图也相关的吧。

成功的项目，还离不开信任：客户与开发者相互信任，管理层和开发者相互信任，开发者之间相互信任。里根说“信任，但要检查。”我们也可以反过来说，因为可以随时检查，所以我们信任。因此，采用持续集成策略之后，项目中的信任大为增强。

本周在和大家交流精益思想的时候提到尊重和信任的问题，这可以作为一个很好的注解：信任，但要检查。同时因为可以随时检查，所以才信任。

这本书向我们揭示了这样一个道理：如果一件事很难，而您又必须做，不妨经常去做，每次做一点点。其实这也是古老的“分而治之”思想的一种应用。正所谓“滴水穿石，跬步千里”。

项目正在经历的软件版本部署的痛苦，就是因为之前的持续集成没有做到位吧，集成的范围不够，同时也是因为没有频繁的做，即没有做到持续。出来混，总是要还的，前面没有投入精力好好做的事情，到后面需要投入更多的精力，花费更多的加班来把前面的坑填上。现在的9C试点项目一定要吸取这个教训。

一本好书使您改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改变您的行为。然而，所有具有重要意义的改变都不会在一夜之间发生。改变随时都在发生，但按照您的意志去领导变革却很难。如果您相信这种变革必须发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。

说得很好，温伯格之前的说法和这个意思差不多吧，及早采取措施，但措施的力度要小。前面几年都是采取这种方式，但草莓酱铺得太开，所以就只有薄薄的一层了。这次希望能够在试点项目集中精力取得突破。

软件业中没有银弹，不可能有某种东西在短时间内让您的开发效率提高10倍。但是我们也容易发现不同人和不同团队之间的开发效率相差巨大，不止10倍。那些软件高手和明星团队就像职业围棋选手，他们高得惊人的效率是多年用心改进实践的结果。

没有银弹，是布鲁克斯几十年前的论断，不过在HP LaserJet Firmware大规模敏捷转型案例的书中，正是把持续集成取得的10倍绩效提升作为典型例子来说的。从流水线每天集成的代码量和构建次数这两个指标来看，确实取得了10倍速的提升，这是持续集成推进能够取得的效果。不过书中说的案例横跨4年时间，这个时间确实也不能算是短期，所以还是需要有些耐心才行，静待花开。

Martin Fowler序

关于持续集成，一件有趣的事情就是人们常常会对它产生的影响感到吃惊。我们经常发现人们认为它的好处不大，但它却给项目带来了完全不同的感觉。项目的可见性变得好了很多，因为问题能够更快的检测出来。引入缺陷和发现缺陷之间的时间间隔变短，就更容易发现缺陷，您可以很容易地看见改变了什么，以方便找到问题的根源。当它与良好的测试程序配合时，可以大大减少缺陷的数量。结果是，开发者在调试上花的时间减少了，在增加功能上花的时间更多了，他们详细自己是在一个坚实的基础上开发软件。

想法：10年前老马的名字在业界是如雷贯耳的，老马善于总结和提炼，著述颇丰，在IT圈中是响当当的。10年后的今天，似乎知道老马的人很少了，是时代变了还是我自己老了？或者是因为随着AI崛起，算法工程师上升，程序员越来越不入流了？

这么多年来我们推行的持续集成一直只是持续编译，因为缺少自动化单元测试的支撑，所以开发人员感受到的价值有限。这次试点项目的推进，希望在自动化单元测试方面能够取得长足的进步，同时让开发人员自己体会到好处。

当然，光说您应该更频繁地集成是不够的。在这个简单的词语后面有一些原则和实践，正是这些原则和实践使得持续集成变成现实。

原则和实践，原则总是排在前面，敏捷也好，精益也好，都是如此。只有明白了为什么，后面推行实践才有意义。另外只要是符合原则的事情，实践其实是可以变通的。以前我对敏捷的理解是这些实践是最重要的，现在慢慢才理解，价值观和原则才是更加核心的事情。

Paul Julius序

我一直投入在持续集成之中，做那些似乎永远也做不完的事情。

ZCIP的口号是持续意味着一旦开始就永不结束，和这句话的意思差不多啊。其实敏捷也是一条永远不会终止的道路，也许永恒的意思就是永不停止吧。

CI的好处，如快速反馈、快速部署和可重复的自动化测试，要远大于实现CI的麻烦。但是，在创建这类环境时却很容易忽视这一点。

CI的好处似乎是不言自明的，很多人都知道，但是往往开发人员在需要分析和解决构建失败问题时，却会抱怨这个事情太麻烦了，经常打断当前的工作。这也许就是CI想要达成的目标吧。丰田模式或者说精益制造中的自働化，就是要求生产线上的工人发现问题时勇敢的拉停流水线，把问题解决掉，避免扩散到下游环节。持续集成是软件行业和自働化直接对应的实践，往往大家还是不会把CI失败作为优先级最高的事情来处理，原因是觉得出现某个小问题比如代码检查工具告警了，对整体质量并不会有太大影响，可以不用现在关注，以后再解决也来得及。同时也担心时间被打成碎片，导致效率下降。 其实在当前阶段解决是成本最低，效率最高的，因为刚提交的代码印象最深刻啊。看起来质量内建意识的建立，还有一段比较长的路要走。希望有一天团队成员能够自豪的说：这是我创建的产品，没有缺陷。

我遇到了一些极为复杂的企业级部署结构。我们的客户根据业界的宣传资料承诺的优势，经常希望得到快速的修复。就像所有的技术一样，关于它可以怎样轻易地该笔那您的企业，实际上存在着一些误导。如果说我从多年的顾问工作中学到了什么，那就是没有什么事情像看起来那么简单。

我想告诉客户如何实际地应用CI的原则。我想强调从开发的“韵律”转变到真正享受到那些好处的重要性。如果开发者每个月只签入（Check In）一次，不关注自动化的测试，或者并不急于修复失败的构建，那么要完全享受CI的好处就很成问题了。

没有什么事情像看起来那么简单，只有真正做起来才知道门道在哪里。CI其实关注的是整体优化，如果开发和测试各自为正，那么开发人员可能不会特别关注CI的结果，而只关心“开发”工作是不是能够很快做完，做完之后就是测试的事情额。敏捷是做出来的，开发和测试需要紧密的协作。

今天我意识到一个问题，之前我一篇文章写得太长，不符合简书中这个简字的要求。其实有一个想法，好好提炼一下，写一篇短文就好，不必长篇大论，唧唧歪歪，否则可能有一天会被人勒住脖子，把舌头剪掉。所以，就此打住。

我是有底线的