如何基于Docker和Jenkins打造面向初创公司的持续集

谈到持续集成，大家可能首先想到的是「自动化测试」。但事实上，我个人认为从DevOps的角度来说持续集成会有包含到整个研发生命周期中可以被自动化的方方面面。

如图所示，除了可以根据用例来跑自动化测试并输出对应的测试报告以外。 包括诸如：基于源代码来进行镜像构建、使用静态代码分析器针对代码风格以及潜在的 隐患点（比如： N+1查询、SQL注入风险点）进行白盒检查都是持续集成所能够带来的价值。

在方案的具体选型上，之前我们也尝试过一些必源的商业方案——比如teamcity， 但是发现因为生态系统完备性的问题 其实会有蛮多比较大的坑，需要自己造一大堆轮子。所以，我们最后综合考虑选用了生态圈最为完备的开源CI系统——Jenkins。

为什么我们觉得每个初创公司都会需要一套基于Docker和Jenkins实现的持续集成系统？

首先，从持续集成的角度来看自动化是最大的优势所在。根据我之前的经验，在技术团队内部进行布道推广测试驱动开发code review统一的代码风格约定等最佳实践的时候，所遇到的最大障碍是人。因为人会有天生的惰性。比如「哥们，我这个 hotfix现在急着merge到生产环境，变量命名不符合规范的问题 回头再改。你先帮我把 code review 通过来吧」或者「就改了2行代码，没必要在跑单元测试，直接提pr得了」 诸如此类等等。 然后，我个人觉得解决这一系列问题的最好方案是通过机器而非人， 达成对于遵守规范的强约束。

然后，之所以考虑将jenkins本身以及jenkins具体的构建节点，都基于docker来进行运行。首先，毫无疑问是考虑到了部署上的简易性。一行命令，如丝般顺滑。另一方面，对于处在快速成长期的初创公司来说无论是团队成员或者业务线成倍的快速扩充 都是一件非常习以为常的事情。基于docker实现的整个ci架构，有助于按需快速简便的伸缩节点数量。

整个持续交付体系在逐鹿X团队内部的实践情况

逐鹿X的整个研发团队目前有11个人，完整的生产环境由5个docker容器组成。代码托管在github的私有仓库上，使用标准的git flow来做分支管理。 同时采用了诸如 结对编程、Code Review、TDD(测试驱动开发)、静态代码检查 等等一系列最佳实践。

完整的workflow如上图所示。

首先，RD 同学会在自己的 feature 分支中完成业务开发，然后提 PR 申请 merge 到开发分支。此时，Jenkins 会开始跑相关的自动化测试用例，同时使用静态代码分析器进行代码风格检查以及白盒安全测试。

随后我们会指定一名同学进行 Code Review，并且通过 Jenkins 会自动在开发环境的联调机上执行部署。 不过考虑到从 feature 分支 merge 到 develop 分支 是一件非常高频的事情，所以出于速度上的考量——我们基于shell脚本而非docker镜像进行部署。

而当此一迭代中的所有功能全部完成开发，并且通过 RD 自测后。我们会将开发分支的代码 merge 到 release 分支。此时 Jenkins 则会开始构建对应的 Docker 镜像，并且部署于 Staging 环境。

几个流程中至关重要的一些细节

首先，将整个工作流和团队的IM工具打通是确保整个方案顺利实施的关键节点。 只有当团队中的所有成员，能够在第一时间获悉CI当前的构建状态。才能确保整个流程顺畅无阻的执行下去。 对于使用slack作为团队im工具的同学，jenkins中有slack相关的插件可以满足你们的需求。然后，如果有同学是使用钉钉作为团队im工具的话，那么也告诉大家一个好消息。我们已经开发了1个jenkins的钉钉通知插件，将在内部基本使用稳定后开源放出，大概是 在半个月以后。

再然后，有1个可能非常容易被忽略的点是——当通过ci自动化部署测试环境的时候。最好，同时用shell脚本将生产环境的数据脱敏后导入到测试环境。这样可以使得，很多因为脏数据导致的问题在测试环境中提前得到暴露。

还有就是，一定一定要记得尽量把整个持续集成环境部署在海外。我们目前采用 的是青云香港机房的服务器，不然无论是拉docker镜像还是跑npm或者github拉代码 都会慢到你想哭。 穿越长城，才能走向世界。