Docker 技术的兴起推动了很多技术的革新与发展。如我们熟知的微服务架构、DevOps， 再一个就是持续集成与持续交付的流程衍变。

对于持续集成，其定义有很多种，这里把它总结为：指开发人员将代码定期合入到中央仓库后触发的一系列构建、静态代码检查、 单元测试、 部署、接口测试等一系列构建或集成的行为。 其主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

传统持续集成的流程

由上图我们来回顾一下传统持续集成的流程：

首先，我们在事先搭建好的持续集成环境中配置好一系列的测试 Jobs 即 Pipeline；并且配置好测试的触发条件。

具体的测试任务内容会由产品的形态和发展阶段进行定制，举一个当前在使用的 Pipeline 的内容：静态代码检查->单元测试->测试环境部署->结果反馈和展示。

当开发小明提交了一次代码的时候，JenkinsMaster 检测到代码的变更触发了测试。

当测试执行完毕之后将测试结果反馈给测试/开发/运维人员，最终人为地去部署预发布或者线上环境。

当前持续集成测试存在的问题

1. 部署环境的成本较高 (包含持续集成本身) 以持续集成环境搭建为例：

以上面流程图中的持续集成环境搭建为例子, 我们可以看到搭建一套持续集成环境的必经步骤。

2. 测试环境的不一致

相信我们都遇到过同一个问题，在测试同学发现并反馈一个问题到开发同学这里时，发现很难复现，甚至需要开发和测试一起去定位排查问题，最终花费了很多时间，结果发现是由环境问题导致的。

3. 相对开发周期较长

最终的直接影响就是导致开发周期变长。

持续集成的容器化实践

容器和微服务的发展让我们经常被问到微服务的测试要怎么做，怎么样结合 docker 去做测试甚至是持续集成？下面就跟大家分享下其中的一个实践：

可以看到这个图相较于上面的图有哪些大的变化？

1. 首先是持续集成的环境我们改为容器化部署 (根据产品的情况我们可以将测试环境也实现容器化，这里就不举例了)。

2. 另外我们创建了一个支持持续集成功能的仓库。

3. 最后持续集成执行的测试结果不仅是一个 result，还有一个镜像形式的交付，这个镜像实际上是源码和环境的捆绑内容。

再来看一下这个流程：

还是这个小明提交了一次代码到 git 仓库，JenkinsMaster 检测到代码的变更触发了测试。

同时，这次代码的变更，触发了一次镜像的构建，并将这个镜像保存到私有的镜像仓库中待部署。

当测试执行完毕之后，通过 JenkinsFile (可以理解为 Pipeline as code 进行的持续集成的一系列编排) 根据测试结果判断是否将通过测试的镜像部署到预发布环境或者进行下一轮的测试。

具体实现

这里以网易云基础服务提供的容器云为例直观的去理解。

step 1. 创建两个容器部署持续集成环境， 官方提供的镜像中已经预安装好了所需要的依赖和工具，只需要通过设置环境变量的方式使得 Jenkins slave 注册到 master 上面。

部署持续集成的环境已简化为：

step 2. 创建支持持续集成功能的镜像仓库，配置绑定 git 上的源码；

step 3. 在 Jenkins 上面创建 Pipeline 选用 Pipeline script from SCM 方式，指定源代码路径下面上传好的 Jenkinsfile。

那么，怎样通过 Jenkinsfile 来实现持续集成测试的编排呢？

step 1. 首先我们创建一个 Pipeline

step 2. 填入开发源码 git 路径

step 3. 选择触发方式，这里用的是 Poll SCM 每隔 20 分钟检查下代码仓库是否有新的提交

step 4. 并填入 JenkinsFile 的路径 (源码 git 目录下)

step 5. JenkinsFile 的持续集成编排内容

Jenkinsfile 是一种基于 Groovy 的 DSL，简单的来说我们通过 Jenkinsfile 中的不同阶段来定义我们的持续集成的 Pipeline 的实现，大家可以通过 Jenkins 的官网文档进一步研究一下。

容器化实践后的思考

优点

容器化的实践不仅在资源上节省了开销，并且由于容器本身的优势为部署也带来了便捷.。同时，结合了网易云基础服务平台的持续集成镜像仓库及 API 等服务，让容器化的交付成为了可能。一方面解决了部分由环境不一致带来的问题，同时也为持续集成的编排增加了更多的灵活性。总结一下主要有以下几点：

§  节省资源

§  版本的镜像化管理

§  容器化交付

§  更好的保证环境的一致性

§  通过 API 脚本方式来编排 CI/CD

问题分析

持续集成在本次实践的过程中，我们借助了网易云的平台，并且同时引进了Jenkinsfile 的 Pipeline 编排方法，这对于传统的用户来说，迁移过程中需要有一定的时间去消化并解决实践过程中的种种问题，甚至在微服务化的过程中同时考虑微服务测试的难易程度做适当的调整；另外持续集成和持续交付在容器化的进程中还未达成一个明确的交付标准，这些都需要更多的开发者和测试同学去实践，从而积累更多的经验去总结得出：

§  CI 容器化实践的成本

§  持续集成/持续交付的流程标准化（张雨原创）

Docker 技术的兴起推动了很多技术的革新与发展。如我们熟知的微服务架构、DevOps， 再一个就是持续集成与持续交付的流程衍变。

对于持续集成，其定义有很多种，这里把它总结为：指开发人员将代码定期合入到中央仓库后触发的一系列构建、静态代码检查、 单元测试、 部署、接口测试等一系列构建或集成的行为。 其主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

传统持续集成的流程

由上图我们来回顾一下传统持续集成的流程：

首先，我们在事先搭建好的持续集成环境中配置好一系列的测试 Jobs 即 Pipeline；并且配置好测试的触发条件。

具体的测试任务内容会由产品的形态和发展阶段进行定制，举一个当前在使用的 Pipeline 的内容：静态代码检查->单元测试->测试环境部署->结果反馈和展示。

当开发小明提交了一次代码的时候，JenkinsMaster 检测到代码的变更触发了测试。

当测试执行完毕之后将测试结果反馈给测试/开发/运维人员，最终人为地去部署预发布或者线上环境。

当前持续集成测试存在的问题

1. 部署环境的成本较高 (包含持续集成本身) 以持续集成环境搭建为例：

以上面流程图中的持续集成环境搭建为例子, 我们可以看到搭建一套持续集成环境的必经步骤。

2. 测试环境的不一致

相信我们都遇到过同一个问题，在测试同学发现并反馈一个问题到开发同学这里时，发现很难复现，甚至需要开发和测试一起去定位排查问题，最终花费了很多时间，结果发现是由环境问题导致的。

3. 相对开发周期较长

最终的直接影响就是导致开发周期变长。

持续集成的容器化实践

容器和微服务的发展让我们经常被问到微服务的测试要怎么做，怎么样结合 docker 去做测试甚至是持续集成？下面就跟大家分享下其中的一个实践：

可以看到这个图相较于上面的图有哪些大的变化？

1. 首先是持续集成的环境我们改为容器化部署 (根据产品的情况我们可以将测试环境也实现容器化，这里就不举例了)。

2. 另外我们创建了一个支持持续集成功能的仓库。

3. 最后持续集成执行的测试结果不仅是一个 result，还有一个镜像形式的交付，这个镜像实际上是源码和环境的捆绑内容。

再来看一下这个流程：

还是这个小明提交了一次代码到 git 仓库，JenkinsMaster 检测到代码的变更触发了测试。

同时，这次代码的变更，触发了一次镜像的构建，并将这个镜像保存到私有的镜像仓库中待部署。

当测试执行完毕之后，通过 JenkinsFile (可以理解为 Pipeline as code 进行的持续集成的一系列编排) 根据测试结果判断是否将通过测试的镜像部署到预发布环境或者进行下一轮的测试。

具体实现

这里以网易云基础服务提供的容器云为例直观的去理解。

step 1. 创建两个容器部署持续集成环境， 官方提供的镜像中已经预安装好了所需要的依赖和工具，只需要通过设置环境变量的方式使得 Jenkins slave 注册到 master 上面。

部署持续集成的环境已简化为：

step 2. 创建支持持续集成功能的镜像仓库，配置绑定 git 上的源码；

step 3. 在 Jenkins 上面创建 Pipeline 选用 Pipeline script from SCM 方式，指定源代码路径下面上传好的 Jenkinsfile。

那么，怎样通过 Jenkinsfile 来实现持续集成测试的编排呢？

step 1. 首先我们创建一个 Pipeline

step 2. 填入开发源码 git 路径

step 3. 选择触发方式，这里用的是 Poll SCM 每隔 20 分钟检查下代码仓库是否有新的提交

step 4. 并填入 JenkinsFile 的路径 (源码 git 目录下)

step 5. JenkinsFile 的持续集成编排内容

Jenkinsfile 是一种基于 Groovy 的 DSL，简单的来说我们通过 Jenkinsfile 中的不同阶段来定义我们的持续集成的 Pipeline 的实现，大家可以通过 Jenkins 的官网文档进一步研究一下。

容器化实践后的思考

优点

容器化的实践不仅在资源上节省了开销，并且由于容器本身的优势为部署也带来了便捷.。同时，结合了网易云基础服务平台的持续集成镜像仓库及 API 等服务，让容器化的交付成为了可能。一方面解决了部分由环境不一致带来的问题，同时也为持续集成的编排增加了更多的灵活性。总结一下主要有以下几点：

§  节省资源

§  版本的镜像化管理

§  容器化交付

§  更好的保证环境的一致性

§  通过 API 脚本方式来编排 CI/CD

问题分析

持续集成在本次实践的过程中，我们借助了网易云的平台，并且同时引进了Jenkinsfile 的 Pipeline 编排方法，这对于传统的用户来说，迁移过程中需要有一定的时间去消化并解决实践过程中的种种问题，甚至在微服务化的过程中同时考虑微服务测试的难易程度做适当的调整；另外持续集成和持续交付在容器化的进程中还未达成一个明确的交付标准，这些都需要更多的开发者和测试同学去实践，从而积累更多的经验去总结得出：

§  CI 容器化实践的成本

§  持续集成/持续交付的流程标准化（张雨原创）