个推持续集成最佳实践

软件开发过程当中，开发成员常常须要把本身工做集成到项目中,一般每一个成员天天至少集成一次。若是项目较小，对外部的依赖较小，那么软件集成可能不会是什么问题。可是目前不少软件项目特别是互联网项目面临着需求不明确，系统架构复杂，任务分配混乱等一系列问题，从而给持续集成带来许多麻烦。也给整个项目带来没必要要的风险。所以一个有效的持续集成系统愈来愈重要。

个推平台是一个极其复杂的分布式系统，整个系统包含了 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 上找到了解决方案。 虽然仍然有许多挑战，但随着技术的升级和完善，咱们终会越作越好。