一直很想谈谈Continuous Integration（CI），持续集成。

就在不久前一次朋友聚会上，一个刚刚跳槽到一家创业公司的朋友跟我抱怨说他们没有CI，没有code review，要做点事太累了。而其实让这个刚刚开始上手的新手项目经理无语到吐的原因是，他们的一名主要开发人员责任心不够，很难沟通，bug率很高，还不愿加班改bug。

“现在招人很难的啊，所以也不能把他fire掉，哎。。。”

“有了CI又能怎样呢？”

“至少不用等到QA发现问题，下班前就能抓住他了！不过现在我们QA连自动化测试都没有。。。”

“你们的技术主管怎么不搞？”

“他太凶了。。。哈哈哈，其实现在都忙着接单子啦。”

“看来你们生意还兴隆呀？”
“貌似还不错的。”

在走出甜品店的时候他并没有什么心塞的样子，反而我的内心开始踌躇一个问题，“你需要CI吗？”

还是先形式主义一下，谈谈CI的作用吧。

当你花了一下午完成一个模块的代码，拿起还微热的拿铁呷了一口，伸了伸懒腰，惬意地环视一圈咖啡馆里的各色达人。然而，尽管你的代码已经通过本地Unit Test的重重测试，可你还是只能对坐在不远处那桌的妹子投入99%的贼心，因为总有1%的担心徘徊于这样一个问题：“这代码能直接上产线吗？” 你不是胆小，你只是不确定。没错，CI最通俗的作用便是尽早发现质量问题，使你无比自豪地堆完几块代码之后便能全心全意地冲着妹子荡漾春心，当然我知道你也就荡漾一下而已：）

然而，故事的走向或许是这样的。在一个烦躁的离下班还剩5分钟的下午，早已跟妹子约好晚上吃饭电影KTV的你在提交代码10次之后，CI还是红彤彤地一片。你看完最新的log有了一点点头绪，老板正兴致勃勃地期待着晚上的上线。选吧，少年！楼下已经等得没剩多少耐心的可能是你的终身大事和身后要求今天必须出包并完成beta测试已经虎视眈眈的你的金主。没错，CI的另一个作用，就是磨炼你的意志以战胜人性的弱点，在放弃和不放弃之间左右为难，万一你还是个处女座。。。

CI就像是小时候作业本背后的那几页参考答案，它能立刻给你结果，但一旦那结果始终与你的答案相左，便容易陷入抓狂。哈哈，其实也没有那么恐怖，此时便是DevOps的大神们出场的时候。

如同上一篇博文中曾提到的，我喜欢把CI描述为DevOps工作的起点。每个人对CI的看法和解释都会不同，对于吃过猪肉或只见过猪跑的人来说，CI一般可能长这样的（请别介意Jenkins和GitHub）：

这张草图描述的是单一模块的CI，我们很多时候都会把多个模块的CI集成在一起形成适用于一个完整产品的CI系统，也有起名字叫作Pipeline。当你坐在市中心的Starbucks一边下午茶一边瞄妹子一边写代码的时候，大概还有几位兄弟在不开空调的办公室一边加班骂老板一边加班改bug呢。你们同时提交一段代码时，有效率的CI系统会把你们的提交按照流水线（Pipeline）的方式妥善安排执行，以避免你们互相踩踏影响各自的春心或苦心：）

这张草图中还有值得注意的三点。其一，部署测试环境（Deploy to Test ENV）和集成测试（Integration Test）都需要依赖某个版本的其他模块，一般会用最新版本或当前产线版本。而这也是Pipeline需要设计的一个部分。其二，有个隐藏关系便是，你的代码最好是基于代码库中最新的版本修改。CI系统应该实现在提交后的代码合并，并在一切都Happy之后自动合并入库。其三，最后那朵小云彩里的内容其实不比整张草图来的简单，那是DevOps大神们需要付出汗水的其他作品，以后再细谈。

尽管业界也有几个成形的CI产品，然而实际上想要找到一个适用于自身项目的CI系统并不容易。尚且先不说购买某CI系统服务需要多少钱，即使买来之后想要用得顺心，还得付出大量人力成本（DevOps）去设计用法和管理维护。因此，相比业界的收费工具，可按需定制搭建的开源产品往往更受到青睐，其中Jenkins应该是大家最熟悉的了，不过我并不打算介绍或评价某个工具的用法或好坏。我的观点是，无论用什么工具来搭建CI，对于DevOps的开发人员来说，都是在制作一件属于自己的产品。

适合的才是最好的，大家好才是真的好：）这便是对CI系统这件产品的要求。具体地，我会用几个方面的指标来衡量一个CI系统的质量高低。

1. 一键触发。高度自动化是对CI系统的基本要求，然而是否高度自动化的衡量更多的是在于对容错机制的实现。一旦提交的代码出现破坏环境的问题，系统是否能够自动回滚以恢复部署环境的健康并不影响代码库的版本控制。对人工干预的需求越少，越体现“一键”的功力。

2. 周期短。由于考虑到Pipeline的实现，协调各模块纷繁复杂的CI需求是件需要智慧的事情。效率是金钱，如果从代码提交到知道结果需要花去你一下午的时间，那对你或对那个妹子来说都是件残忍的事。统筹多方的考虑，我认为一次周期所需的能容忍的时间应该不能长于20分钟，这足以让你伸懒腰，泡咖啡，骂老板，上洗手间，聊人生关键节点了。

3. 配置快。一个可重用的CI系统框架是很多DevOps的追求。可事实却是，世界上基本找不到两个完全可重用的CI框架。原因很简单，对于不同产品，CI的内容也是不同的。其中，部署（Deploy）和集成测试（Integration Test）就是决定性因素。于是优秀的DevOps大神会在部署脚本和测试脚本上花去大部分脑力，而通过快速配置CI系统来实现一个新模块CI的需求。而这其中能重用的便是依此抽象出来的一套配置方式与适用于产品各模块的参数化的脚本。

4. 高可用。其实对于高可用的原则不用赘述。产品必须高可用，这是这一代互联网人的信条。CI是产品，也是保证产线质量的基础设施，自然也适用。

零零落落地写了这么多，我的咖啡也凉了。在这个没有太阳只有小雨的下午，对面坐的是依然美丽动人的老婆，咖啡馆里人也不多。再来杯最爱的美式，陪老婆看完电影就回家~

对了，因为CI而抓狂是正常的，不过也别太抓狂。Remember, CI drives you crazy only because you are a responsile person:)