传统我们的项目开发模式是产品调研提出需求，开发团队研究决定开发方案选型。然后开始一个周期的开发，模块开发完成之后开始模块间的联调。联调结束之后打包交付给测试团队。测试团队，系统测试或自动化测试，然后提交bug，开发团队修复bug，周而复始。传统的模式中，存在着较多的不确定因素。例如，开发环境、编译环境、测试环境、生产环境，等不确定因素。人为介入打包中的不确定因素，缺乏单元测试和自动化测试的整合。从而导致的结果是，开发-测试-修复的周期较长，而且很多小的问题完全可以由单元测试进行覆盖。

持续交付并不是某个特定的软件，而是一个结果。这个结果要求团队可以随时的发布一个新的准确版本，而且要求在编译发布的过程中进行自动化测试，通过自动化测试可以及时地发现并定位存在的bug，修复bug之后再进行快速的发布到测试环境，测试团队直接进行测试。与传统模式的区别在于持续交付可以提前发现bug的存在和快速修复而不必等到测试人员的介入之后才发现。持续交付分解出来就是“持续”和“交付”。

持续：持续要求任何时，候任何情况都能进行准确的发布，做到准确的发布需要注意以下几个关键点。

1. 持续应该是一个周期性的，可以是每天的某个时间点，也可以是某次代码的提交，或者某次人为触发。所以人工进行构建是不可能的，需要自动化的构建，自动化要求构建的任何一个流程都必须以脚本的形式运行，代码检出、代码构建、各模块代码单元测试、集成测试、UI自动化测试等。

2. 发布的程序版本不允许是各个模块在开发环境编译出一个版本作为交付，而要求在一个纯净的编译环境中进行构建。

3. 构建的过程应该要求最大可能的固化，例如操作系统的版本，构建环境的版本，相关的依赖等。

4. 避免从网络获取相关的文件，这点以nodejs为开发或编译的项目尤其重要，安装node的依赖包总是一个漫长的过程，就算有国内的源，一般的项目也需要一两分钟的node依赖包，这不符合快速构建。

交付 : 在持续编译的过程，使用自动化已经可以避免大多数的错误了。但是还是需要人为介入的系统测试，毕竟自动化的测试一般只能覆盖到70%左右。

根据我们团队内部推广这种工作方式的效果来看，持续集成确实让我们工作便利了许多， 每次代码的构建和自动化测试让我们及时发现存在的bug。好的工作模式也需要团队成员的遵守，团队成员应该积极的拥抱这种工作方式，团队成员需要做好以下几点。

1. 使用版本工具例如git。git有强大的版本回溯，成员每次完成一个小的功能点进行代码提交。合并到master分支，持续交付工具应该配置为代码更新触发。团队内部应该等到持续交付流程结束之后，确认编译、自动化测试通过之后方可进行下一个版本的提交，这样容易定位bug。而不会导致这次bug影响团队内其他成员的工作。

2. 主分支的代码bug不应该存留时间过长，避免团队内其他成员合并代码的时候引入其他问题。

3. 测试驱动开发，任何一个新的功能开发都应该先写好单元测试脚本，并积极更新自动化测试脚本。并且积极地拥抱测试，虽然你明白这个测试不通过的问题并不会引起很大的系统性问题 ，但是还是应该进行修复而不是想方设法的跳过这个自动化测试。

4. 临近下班的时候不要提交代码，这主要是因为遵守第2点。

使用Docker

Docker已经越来越火，CICD和Devops也是Docker一个重要的场景。在持续交付中使用Docker有一下优点。

1. Docker强大的环境隔离性可以将环境和程序打包在一起，测试、运维，人员无需知道我们的程序是如何配置的，只需要一条docker 的命令就可以将我们的程序运行起来，这也更加容易实现持续部署。

2. 减少编译环境的污染，因为Docker天然的隔离性，也避免了传统编译环境难以配置多套编译环境的问题。在基于Docker的持续发布中，我们可以在同一台宿主机上同时编译不同版本的Java项目，不同版本的Python项目，而无需任何配置，镜像也只是从docker hub中获取。

持续集成

在持续集成方面，我们选择Jenkins。Jenkins是一款开源软件，拥有众多优秀的插件，依靠这些插件，我们可以完成一些周期、繁琐、复杂的任务。例如我们今天分享的持续发布，虽然Jenkins解决了我们繁琐复杂周期性的操作，但是没有解决我们在多种环境下编译构建的需求。而这个场景正是Docker的强项。通过Jenkins的pipeline我们可以实现代码检出、单元测试、编译、构建、发布、测试等流程的自动化，而最终通过Jenkins的Docker插件将产出物构建成镜像，方便部署到Docker环境。

持续部署

持续集成让我们新的代码源源不断的构建成了镜像，这些镜像经历了单元测试，自动化测试，但还没有接受过测试团队的严格测试。Jenkins是一个强大的持续集成工具，然而持续部署并不是Jenkins的强项，但是Jenkins拥有很多强大的插件。而且我们持续集成产出的是镜像，所以持续的部署，我们只需要将镜像运行起来，或者利用第三方的容器管理平台提供的API进行部署。

1. 本地部署应用到Docker。

   本地部署到Docker容器可以使用Jenkins的docker插件，下面会介绍。

2. 部署到远程主机的Docker、Appsoar。

   Docker和Appsoar都支持开启API调用。通过现有的API我们可以运行我们生成镜像版本。从而达到持续的部署最新版本。

3. 部署到kubernetes。

   kubernetes除了可以通过API调用还可以在jenkins中配置kubectl的方式创建或更新deployments。

Docker部署Jenkins的方式简单方便，下面我们介绍用Docker的方式运行Jenkins。

1. 这里将docker.sock和docker的可执行文件挂载到Jenkins容器中，这样我们就可以在容器中使用docker了。

2. Jenkins容器，默认的用户是Jenkins。因为我们需要使用Docker，所以我们需要使用root用户。

3. /var/jenkins_home的挂在卷是可选的，Jenkins_home存放了所有任务、日志、认证、插件等jenkins运行后的文件。可做数据恢复使用。

配置Jenkins

• 解锁jenkins

解锁的密码在容器的log中可以查看，或者直接查看jenkins_home指定文件

• 选择插件

下面我们创建一个的Jenkins的Pipeline完成简单的cicd流程。

1. 新建pipeline，在左侧新建选择pipeline。

2. 在左侧的Credentials中新建git和镜像仓库的credentials

3. 配置pipeline，例如定时触发，代码更新触发，webhook触发等。

4. 在pipeline script中填入下面的demo.

以下是伪代码，仅提供思路

Jenkins pipeline的脚本语法是groovy的语法，其中docker 、Git是插件提供的能力。代码的执行流程如下：

1. 通过Git插件获取最新代码到jenkins的工作区，例如`/var/jenkins_home/workspace/pipelineDemo。

2. docker.image().inside是如何编译我们的代码呢，通过查看Jenkins的console 可以看到如下log.

3. [Pipeline] withDockerContainer

   

4. 熟悉Docker命令的朋友应该很容易理解了，原来是docker.image().inside启动的时候会将当前的目录挂在到容器中，然后在容器中执行./script/build.sh，这样我们就完成了利用容器中存在的环境做单元测试或构建编译了。

5. 通过docker插件提供的能力构建镜像，Dockerfile存放在代码目录中。构建镜像后push到镜像仓库，私有仓库需要自行配置镜像仓库。

6. 镜像构建完成之后就可以删掉旧版本，并重新运行一个新的版本。

通过简单的例子，可见Jenkins和Docker的结合给CICD带来了足够的便利和强大。我们需要准备的只是一个编译的脚本，在编译脚本中可以使用任何的环境和任何的版本。

Jenkins的任务两个主要版本。

 free style只是一个自动化的脚本，脚本类型为shell。所有的脚本在一台机器上运行，需要的环境需要提前准备。配置不集中，混乱。但是一般情况下还是够用的。

pipeline 是jenkins2的版本使用了一个基于groovy脚本的任务类型，通过一系列的stage将构建的不同部分组合成一个pipline。而且配合step可以完成异步操作。因为基于groovy可编程性更加强大，而且脚本可以存放在源码中，脚本的更改不需要直接到jenkins中修改。

pipeline的一些使用经验和技巧

1. Jenkins的资料较少，官网可以查看的内容也不多，一般的需求Jenkins内置的pipeline-syntax里面就有常用的命令生成器。可以满足大多数需求。

2. 在pipeline脚本调试完成之后应该将脚本以文件的形式放在源码目录中，这样子方便修改。和多分支需要编译的情况下进行互相隔离。

3. 应该多查找下相应的插件，而不是使用sh用执行脚本的方式来解决问题。

4. 应该将jenkins_home目录挂在出来，如果遇上了Jenkins崩溃了可以及时的恢复数据。

5. 应该新建一个定时的pipeline用来清理生成的镜像，减少硬盘资源的占用。

6. 页面新建的pipeline,在页面删除之后，jenkins_home/workspace中对应的项目文件并不会被删除。

持续发布很多团队想有这样的工具达到这个效果，有些团队觉得不需要。任何工具、流程都需要符合自身团队的实际。从我开始参与团队内的这个和持续发布有关的项目，查看了许多资料，结合团队项目内的实践。给出的一些经验的和见解和大家一起分享，如有错误或者建议，欢迎大家及时沟通。

Q1：请问Kubernetes怎么结合Jenkins做持续集成呢？

A1：部署到Kubernetes。Kubernetes除了可以通过API调用还可以在Jenkins中配置kubectl的方式创建或更新deployments。

Q2：必须通过pipeline才能实现Jenkins把代码构建成Docker镜像么？

A2：不一定，使用Docker主要是方便进行编译环境的隔离，也可以配置好NFS，构建完成之后复制到固定的服务器上，这个我们一般叫制品库。

Q3：Pipeline如何通过Docker容器部署应用到不同的节点上去？发布遇到问题如何回滚版本的？

A3：Jenkins的能力更多的是做持续集成（CI）的功能，部署和回滚都需要容器管理平台并不是Jenkins的强项，特别是回滚单依靠Jenkins很难做到完美的方案。但是部署到不同的Docker的节点上，可以使用第三方的管理平台，例如Appsoar和k8s提供的API能力，可以进行部署。Jenkins直接调用curl命令执行容器管理平台提供的API。

Q4：pipeline的每个环节的报告如何快速获取？比如代码静态检查，工程构建，测试报告等等。

A4： http://jenkins:8080/job/clearImages/86/wfapi/，通过Jenkins这个API，可以获取一些状态和时间信息，至于详细的代码静态检查，每种语言都有不同的语法检查。需要自行配置。当然详细的需要查看输出日志。

Q5：关于测试驱动开发，在开发之前写好的用例一定要是自动化的吗？为什么？

A5：一个系统由若干的方法组成，单元测试就是测试你写的方法是否符合你的业务要求。所以先写合理的单元测试，只要你的方法通过了这个单元测试就表示你写的这个方法是正确的，单元测试代码是需要开发人员编写的，每种语言有不同的单元测试框架例如Nodejs的mocha，Golang 的go test。自动化测试由测试人员编写.单元测试应该需要脱离外部因素，不依赖数据库、不依赖外部API。

Q6：怎么触发工作流的？

A6：Jenkins pipeline 提供了三种方式（如果安装了SCM的插件可能有其他的方式触发），进入到pipeline的设置页面中的分别有。wbhook（触发远程构建 (例如,使用脚本)）、定时触发（Build periodically）、代码更新触发（Poll SCM）。

Q8：Jenkins的编译环境是怎么处理的，实际用户的编译需求和环境都不一样？

A8：用户需要清楚你使用的编译环境的基本情况，例如golang的编译环境，容器中的GOPATH是在什么位置。你需要将你的代码ln到什么目录才能进行编译,等这些细节都是需要用户提前知晓。

Q9：Jenkins里的有用户权限管理吗，贵公司的CI/CD是怎么实现用户隔离的，每个用户只能看到自己的项目。

A9：Jenkins当中并没有用户权限。公司在研发的产品中，有一个虚拟的概念叫用户组，对应的是k8s中的一个或多个namespaces。管理员将成员用户添加到这个用户组中，组内成员创建的资源（pipeline、集群、服务，等）在组内是可见，用户组来进行逻辑概念上的隔离

Q10：贵公司Jenkins和Kubernetes是怎么结合使用的？是什么的部署形式？如何回滚？

A10：我看到很多朋友都提问了，Jenkins如何跨主机部署或者如何部署到Kubernetes集群，如何回滚。Jenkins对这方面的能力比较弱，仅仅能够支持kube-api-server的调用而已，如果完全依靠Jenkins是很难完成需求，所以我们的产品当中有一个专门对接kubernetes的deploy的模块，一个应用商店的模块，一个封装了Jenkins的uflow模块，uflow模块向应用商店获取模板并根据当前编译构建出来的镜像tag号替换模板，并交付给deploy模块创建。回滚和升级都由deploy模块负责。这样各自分开，各司其职。

Q11：多个PHP项目，在Docker 应用中，需要逐个拆分吗？一个项目对应一个镜像管理？还是使用文件夹映射的方式构建镜像？

A11：多个项目服务是放在一个容器中还是分开容器中，这个并没有强制的限定。但是建议还是分为多个容器进行部署。Docker的理念就是一个容器完成一个单独的事情。

Q12：Jenkins PIpeline input指令可以复杂的参数化么？

A12：input是一个比较强大的指令，可以在pipeline的运行过程中确认操作，字符输入，文件上传等功能。详细的可以看下jenkins的pipeline-syntax有使用说明和脚本的生成。

Q13：Jenkins自动触发job到build docker image，自动触发是怎么实现的，wedhook 定时触发有没遇到过问题？不能正常触发的？

A13：自动触发的原理的原理是，我们在pipeline中配置一个定时器，这个定时器是用cron表达式表示。例如你设置了 “* * * * * ”就表示每分钟检查一次，那么检查什么呢，检查每次提交的ID，例如git的commit ID 。只要检测到了这个ID和上一次的不一致就会触发pipeline的构建。从目前使用并没有出现过不能触发的情况。如果出现了请检查是否是配置的错误。

Q14：CD过程中，重造的轮子和开源组件是一个什么样的比例？个人推崇哪个？

A14：自己重复造轮子和开源组件应该如何选择，这个是很有意思的一个问题。因为开发者都说不要重复造轮子，这是因为很多轮子经过了很多项目考验和众多开发者提交代码和fix的bug。这些项目肯定是比自己从头开始造一个轮子更加有效率而且使用风险低，毕竟所有人都想完成工作上的任务早点下班。但从个人发展来说，有些轮子还是值得自己去制造一次的，这样子你才会了解到这个组件的工作原理、底层的东西。所以我个人的推崇的是，假如你找到了合适接近完美的轮子那就直接用，如果找到了一个可用但总觉得用起来不太爽的组件，那你就把轮子造起来吧。