标签：个推
软件开发过程中，开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小，对外部的依赖较小，那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确，系统架构复杂，任务分配混乱等一系列问题，从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。
个推持续集成系统的组成
使用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 上找到了解决方案。 虽然仍然有许多挑战，但随着技术的升级和完善，我们终会越做越好。
标签：个推
原文地址：http://blog.51cto.com/13031991/2108082
