火力全开 | 持续集成、持续交付 | 5分钟了解一个容器典型应用场景系列

５分钟了解一个容器典型应用场景系列篇

关于容器解决方案的概念、架构、成功案例，笔者已经分享了很多了。为了使读者能够花更短的时间，迅速感性地解容器的典型应用场景。笔者从今天开始，推出“５分钟了解一个容器典型应用场景”系列片。每次分享一个场景，采用文字描述+视频展示的方式。本系列分享内容将分别是：灰度发布、CI/CD、开发自动化、微服务、业务弹性扩展。

声明：本实验基于红帽淡成等专家提供的实验步骤和实验环境/脚本整理而成。在此表示感谢。

本系列第一篇：火力全开 | 灰度发布 | 5分钟了解一个容器典型应用场景系列

概念介绍

持续集成与持续交付（CI/CD）

谈到敏捷开发与自动化，可能大家第一时间想到的是devops（开发运维一席话）。而实际上，从传统的开发模式，提升到devops，至少需要如下几个阶段：

持续集成（CI）==>持续交付（CD）==>持续部署==>Devops。

在四个阶段中，前一个阶段是后一个阶段的基础，随着阶段的提升，每个概念覆盖的流程越来越多，而DevOps则是终极目标。

客户在自身的IT环境中，使用持续交付还是持续部署，抑或推广devops，这更多是从企业内部的规章制度或自身业务特点方面来考虑；从技术方面，openshift能够实现devops全流程的打通。

持续集成的目的，在保证高质量的基础上，就是让产品可以快速迭代。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。所以说，持续交付，持续交付是将持续集成产生的软件，进行自动化测试。

持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。持续部署与持续交付的区别，是当代码在dev阶段测试通过后，自动部署到生产。具体可以参考下图。

而DevOps则是覆盖从开发到运维的全流程，并且是自动化完成的。

操作步骤

本篇实验所分享的是CI/CD。

在实验中，第一步首先创建一个项目用于测试。

第二步，创建jenkins的服务。需要注意的是，在openshift3.4版本中，jenkins已经与openshift做到深度集成，统一认证。部署完成后的jenkins，可以通过openshift账号直接登录。而这里，我们用到的jenkins的容器镜像，也是红帽认证过的镜像。

第三步，通过已经写好的json文件部署pipeline。需要注意的是，这个json(pipeline.json)文件中不仅定义了pipeline的各个阶段，还定义了其管理的应用。

查看json配置文件的阶段定义（为了方便读者看清，笔者将代码贴出来）：

"jenkinsfile": "node(){\n \nstage '编译构建容器镜像'\n sleep 1 \necho '编译构建容器镜'\n \nstage '开发环境部署'\nsleep 1 \necho '开

发环境部署'\n \nstage '测试环境部署'\nsleep 1 \necho '测试环境部'\n \nstage '确认测试通过'\nsleep 1 \ninput '测试是否成功？'\n \nstage '生产环境部署'\necho '生产环境部署'\n}"

而json配置文件中这段代码的定义，当pipeline创建好以后，将会以如下方式展现，五个阶段是完全对应的。

在json中，其对所管理代码的定义如下，是php：

第四步,触发pipeline。应用将经历“编译构建容器镜像”、“开发环境部署”、“测试环境部署”、“确认测试通过”

此时，下发操作指令（点击Input Required），批准还是拒绝。这步是通过链接到jenkins来实现的。而正是这一步，说明了持续交付与持续部署的区别。（前者需要人为批准测试成功的代码是否部署到生产上，后者自动部署到生产环境上）。

如果点击Proceed，那么测试成功的代码将会部署到生产环境。如果点击Abort，那么操作将终止，测试成功的代码不会部署到生产上。如果成功部署到生产上，那么pipeline将如下显示。

操作视频

总结

本文简单地展示了Openshift持续集成、持续交付的功能。在实验展示中，我们也能够清晰地认识到了持续交付与持续部署之间的差别（前者需要人为批准测试成功的代码是否部署到生产上，后者则直接自动部署到生产环境）。而客户在自己的IT环境中，使用持续交付还是持续部署，抑或推广devops，这更多是从企业内部的规章制度或自身业务特点方面来考虑；从技术方面，openshift能够实现devops全流程的打通。