这是一个创建于 3138 天前的主题，其中的信息可能已经有所发展或是发生改变。
软件开发过程中，开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小，对外部的依赖较小，那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确，系统架构复杂，任务分配混乱等一系列问题，从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。
个推平台是一个极其复杂的分布式系统，整个系统包含了 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 上找到了问题的答案。 虽然仍然有许多挑战，但随着技术的升级和完善，终会越做越好。
个推平台是一个极其复杂的分布式系统，整个系统包含了 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 上找到了问题的答案。 虽然仍然有许多挑战，但随着技术的升级和完善，终会越做越好。
 |
1
JohnSmith 2015-09-15 16:05:39 +08:00
图片挂了
|
 |
2
Androilly OP 哈哈，感谢支持，现在抢救好了~
|
 |
3
ibudao 2015-09-15 16:08:38 +08:00
需要在 Mac 环境下 build 的貌似没法用 docker ，楼主有解决方案么
|
|
4
Androilly OP 我们是在 centos 做的，不过可以通过后面这篇文章在 mac 上安装 docker 哦
|
|
5
Androilly OP 需要在 Mac 环境下 build 且用 docker 的朋友可以看看这个链接 https://docs.docker.com/installation/mac/
|
 |
6
suckMyballs 2015-09-15 16:50:49 +08:00
@Androilly 请问 web 项目有必要做持续集成么，目前已经做了 git hook ， push dev 分支会自动推送到测试服务器，让测试人员自己去测试服务器看网站就好了，这样合适么？
|
 |
7
mgcnrx11 2015-09-15 17:03:41 +08:00
请问 jenkins 是运行在 docker 里面的么？一直碰到的问题是 Jenkins 运行在 docker 里面的话，怎样去打包 docker 和 run 容器呢？ docker in docker ？
|
 |
8
hging 2015-09-15 17:04:54 +08:00
还有个问题. 就是出现问题后怎么回滚.
|
 |
9
c742435 2015-09-15 20:31:20 +08:00
@hging 只要部署之前版本的镜像就可以了。
@mgcnrx11 在 Jenkins 中安装 sudo 。 参考： http://dockone.io/article/431 镜像参考： https://registry.hub.docker.com/_/jenkins/ 如果需要更多帮助，密我 @suckMyballs 看项目大小了。。。我的超小型项目就是手动触发构建的。俩 flash 前端一个 java 后端 |
 |
10
ganxiyun 2015-09-15 20:36:58 +08:00
@hging 我们公司是 dev 分支不能 push ，只能提交 MR ，而每个 MR 都会触发 jenkins 的 build ，只有过了测试才能 Merge 到 dev 分支。
|
 |
11
qw7692336 2015-09-15 23:31:11 +08:00
还是没懂 docker 的用途
|
 |
12
msg7086 2015-09-16 03:13:41 +08:00
|
|
14
Androilly OP @suckMyballs 如果 web 项目是前后端分离的话，可以自动化测试后端的接口；如果没有分离的话，就不好自动化测试了。
|
|
15
Androilly OP @mgcnrx11 我们 jenkins 是运行在物理机上的。 jenkins 运行在 docker 的话，也已 docker in docker ，也可以调用一个自己写的服务在物理机上启动 doker
|
 |
17
xylophone21 2015-09-16 09:35:39 +08:00
docker 确实在这里不重要，和用物理机器的区别不大（如果有的话）
|
 |
19
repus911 2015-09-16 10:05:18 +08:00
公司在做持续交付系统，我在做持续集成那部分
其他的服务发现 镜像自动部署系统都差不多写好了 还剩下一个部署操作界面... 基本思路和楼主差不多 不过集成的时候我们是按照 dockerfile 打包 没用其他工具 |
 |
20
erric 2015-09-16 10:29:31 +08:00
@xylophone21 docker 可以移植啊，可以很快的在不同机器移动。如果用物理机的话，需要的依赖都要重装。。。
|
 |
21
cloudy9101 2015-09-16 10:58:06 +08:00
请问 每次提交代码到 dev 分支后，是否要重新打包项目的 docker 镜像？ 每次测试时使用刚刚打包的镜像文件？
|
|
22
ibudao 2015-09-16 13:20:34 +08:00
@Androilly 我不是说在 Mac 下跑 docker ，而是可以提供 mac build 环境的 docker 镜像，有这样的么？
|
|
23
erric 2015-09-16 14:20:43 +08:00
@cloudy9101 可以 build 镜像，还有一种方式是通过-v 参数，将打好的包映射到 docker instance 中
|
|
24
erric 2015-09-16 14:25:23 +08:00
@ibudao docker image 是不分平台的吧，在 ubuntu 中 build 的 image 也可以在 mac 上运行啊
|
Select Language