浅尝CI 之 揭开CI的神秘面纱

今天是西方的圣诞节，祝东方的我们“Happy Holidays”！????????????

圣诞节也不休息#￥%&*%*#@%￥%￥&%????????????????????????

说来惭愧，第一次听说CI，已是两年多以前的事了。那时候，由亮哥和晋阳兄带领的一班人马搭建的CI平台，获得了华为无线的优秀实践奖。友情参与的我，不明觉厉，只负责了PPT的美工部分，一直为不能真正地了解CI而耿耿于怀。之后日子，CI之于我依然只是个概念，始终是我知识地图中的一块短板，也成了一块心病。

幸得近日，同Team的SJ童鞋分享，让我茅塞顿开，所以决心连载几篇关于CI的内容，希望能帮助到更多的和我一样困惑的童鞋。顺便做个小广告，悄悄附上SJ的个人博客（http://blog.sjyuan.cc/dojo/ci/basics），拥有更多精彩内容哦。再悄悄告诉你，SJ同学是一位聪明但又内敛的技术达人，还是为90后小帅哥呢~

好了，废话太多了，转入正题......

对于新鲜事物，我们通常采用5W2H法则来加以分析。因此今天，我将从What、Why、How三个维度来解说，让大家对CI有个初步的认识。

1. What — CI是什么？

程序员写什么？—— 代码。软件由什么构成？ —— 代码。

因此，CI (Continuous integration)，持续集成，就是指频繁地（一天多次）将代码集成到主干。集成，是指将不同程序员提交的代码集成到主干；持续集成，便可以理解为一天多次地将不同程序员提交的代码集成到主干，从而快速迭代高质量的代码。

那么怎么做到高质量快速迭代呢？就是在代码集成到主干之前，必须先通过自动化构建（编译，自动化测试，部署）来验证其正确性。只要有一个测试用例失败，就不能集成。

2.How — CI的是如何工作的？

人类之所以能够成为高级动物并引领世界，是因为人类能够使用并创造工具。那么集成，自然也少不了借助一些工具，将这些工具通过合理的方式组合在一起形成一种工作流，就是CI的工作原理。来看这张图：

（本图来自SJ的博客）

可以看到，一个Team可能同时存在多名开发人员，向同一个版本控制库提交代码。因此在部署之前，由CI master去检测是否有更新请求，一旦收到更新请求，便会在Build Server中触发构建。一次构建通常包含一下几个步骤：

Step 1: 提交  

开发者向代码库提交代码。所有后面的步骤都始于本地代码的一次提交.

Step 2: 测试（第一轮）

CI Master检测到代码提交请求，便会在build Server触发测试（Unit Test，Integration Test，End to End Test ）。第一轮测试至少覆盖单元测试。

Step 3：Build

通过第一轮测试，代码就可以合并到主干了。这时，先要进行Build，也就是将源码转换为可执行的实际代码，比如安装依赖，配置各种资源等等。

Step 4：测试（第二轮）

Build完成，需要进项第二轮测试。如果第一轮测试已经覆盖所有内容，那么本轮测试可以忽略。

Step 5: 部署

第二轮测试完成，当前代码就是一个可以直接部署的版本了。这时，Build Server会输出构建结果，CI Master会根据失败与否设置状态（失败：红；成功：绿），并将结果反馈给相关人员（开发人员、QA、以及Team Leader）。

3.Why— 为什么要搭建CI？

如今的软件开发，已不再是一个人的狂欢。绝大多数情况下，是由团队共同作战，去完成一个软件，一个产品。这样一来，冲突、重复以及错误就再所难免。那么CI就是从基础上去帮助开完人员解决和避免这些错误。产品越复杂，开发人员越多，CI的优势就体现的越明显。

那么，CI究竟给我们带来什么样的好处呢？

(1). 减少了重复过程所花费的时间

CI将一些需要重复执行的操作（代码审查、编译、测试、构建、部署）通过自动化管理起来，释放了人力，并且节省了大量的时间。

(2). 降低风险和成本

开发过程中，每天进行多次集成，每次集成都能通过Unit Test，Integration Test，End to End Test多种测试类型，检查代码缺陷，从测试金字塔的最底层降

低了风险和成本。

(3). 可视化

CI提供了大量真实且最新的数据，能够让我们实时关注当前集成的状态（例如构建时间、构建失败比例、测试覆盖率等），有利于有效决策。

(4). 增强团队信心

每次构建结果都是公开透明的，所有人清楚地知道自己的每次提交改动对软件所造成的影响。

(5). 随时随地生成可部署的软件

说的天花乱坠都没用，客户就是上帝，关心客户之关心才是硬道理。那么，客户关心的是什么呢？即高质量的产品，之于开发过程，就是可以部署的软件。CI让我们就可以在任何时间发布可以部署的软件。

或许我们将提升软件质量和减少项目风险说的滔滔不绝。但对于客户来说，可以部署的软件产品才是最实际的资产。

总而言之，没有CI的软件项目，犹如在裸奔。有了CI，有了持续集成，我们可以在第一时间发现代码缺陷，并通知相关人员在第一时间进行修复。反之，没有CI，很多问题都要等到最终交付测试时才能被发现，轻则增加成本，重则可能导致产品发布延迟，紧急修复更可能引入新问题，最终导致项目失败。

说了这么多，是不是迫不及待想要一试身手，来搭建一个属于自己的CI呢？

不急不急，先消化理念，接下来才能做更有效的尝试，不是吗？

预知更多CI知识，尽请期待下期 —— “浅尝CI 之 环境搭建”。