基于 jenkins 和 docker 的持续集成平台

软件开发过程中，开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小，对外部的依赖较小，那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确，系统架构复杂，任务分配混乱等一系列问题，从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。

个推平台是一个极其复杂的分布式系统，整个系统包含了 RPC 调用，高速缓存，集群同步等各种复杂的场景。整个团队只有二十来个人却维护了近百个模块的开发和测试工作，如果没有一套有效的机制，很难想象如何完成这些任务。持续集成在其中扮演了非常重要的角色，借助于 Git、Docker、Jenkins 以及 Nexus 等工具，我们搭建了自己的持续集成环境，并一步一步的摸索出了自己的最佳实践，这篇文章将会和大家一起分享我们是如何利用这些技术提高团队的生产力的。

个推持续集成系统的组成

使用git作为版本控制库
相比于同类项目版本系统，git有一项非常显著的优势，就是版本分支(branch)的合并(merge)十分方便。
使用docker搭建测试环境
作为一种新型的虚拟化方式，相对于传统的虚拟化方式有着众多的优势。例如，docker虚拟容器的启动可以在秒级实现，并且对系统资源的利用率很高。另外，docker的管理，迁移和扩展也更轻松有效。
使用jenkins作为持续集成服务器
Jenkins为开发人员提供了非常有效的持续集管理。其强大的插件系统和明确的构建逻辑，使得构建流程的创建非常简便。

Docker在持续集成系统中的作用

测试作为软件项目重要的一环，一般都需要开发团队搭建一套独立的测试系统。但作为持续集成的一个环节，此测试系统又异于一般的测试系统。主要原因为，持续集成测试系统主要用来做回归测试，而且需要支持快速大量的代码升级。基于docker的特性，以及持续集成的需求，个推采用docker为持续集成搭建了一整套测试系统。

镜像准备：docker 的运行基于镜像文件，而每个项目所需的镜像文件又不同。因此需要独立分析每个项目的需求以及未来扩展需要，创建出不同版本的镜像文件。目前，个推主要有4大类镜像，分别支持前端，后端，工具类等项目。以前端为例，个推采用了前后端分离的开发模式，因此此镜像主要用来支持web 前端的服务运行。

服务包准备：为了能在docker里运行所需要的服务，需要docker实例中安装相应的服务包(service package)。 一般有两种方法，一种是将相应的服务包在镜像文件中安装，另一种以docker 卷的形式动态映射到docker实例。 两种方式有其优劣，第一种方式使得每次docker 容器的启动非常迅捷，而第二种方式则更为灵活。这个需要根据不同的需求选择合适的方式。
下图为docker 在整个持续集成系统中的作用。Jenkins 作为主服务器将代码和docker 统一的管理起来。



个推持续集成流程

下面以user模块为例，对持续集成的流程进行阐述，如下图所示：



从图中可以看出，我们系统的git分支包括dev，master两个分支：

dev:开发分支，开发人员维护，开发人员将最新代码提交到这个分支，Jekins监视这个分支，任何代码改变都会触发自动化测试
master:发布分支，这个分支上的版本是自动化测试通过后的版本，且自动化打包监控这个分支

图中的每个长方形代表一个Jenkins Job。下面将对每个Job进行说明：
• user: 监控user代码库的dev分支，当每次有新的代码提交时，就会自动触发构建任务。编译代码，同时生成code style,测试覆盖率等关于代码质量的报表。成功后将触发user-docker任务。
• user-docker: 打包user工程，重启user的docker实例以便于使用全新的user包。成功后将触发testcase任务
• testcase: 验收测试，检测改变是否满足业务需求所定义的验收条件。成功后将触发marge任务
• merge：将user的dev分支merge到master分支
• user-pkg: 监控user代码库的master分支，当有代码改变时，执行mvn package打包操作
经过上面的几个步骤，从代码提交到打包的整个过程就自动化起来了。

总结

目前越来越多的公司开始重视持续集成系统，但是缺乏定制化的系统真的能满足复杂的需求吗？当模块之间的联系越来越复杂，集成的频率越来越大，运行环境的不断升级 等等，缺乏定制的持续集成系统是否能达到预期，个推在docker 上找到了解决方案。 虽然仍然有许多挑战，但随着技术的升级和完善，我们终会越做越好。