基于 jenkins 的 CI/CD 实践

毕宏飞

作者简介

Rock

一、实践背景

CD，主要指持续部署。

在公司，我主要负责的持续集成和发布部署这块，目前现在有n00万用户，开发最多的时候有200人，每日上线部署次数应该是50～60次。

部分团队最近开始使用 spring cloud 。

二、CD 中 jenkins 详解

2.1 CD业务建模

在做工具实施之前，肯定会构想一下所有部署的业务是什么样的模式，让它变得很灵活，可以支持开发、测试等环境的构建和部署。

先按产品切分，每个产品下面有很多工程，每个工程的部署流水线一般会分二方包，单独拿出来发布到私服。另外是应用程序包，会把代码生成部署包，这中间我们会加单测和 findbugs 检查。
再按环境切分：环境有开发测试、测试环境、集成测试环境、模拟和生产。
从代码到开发测试环境和测试环境、基准测试环境、集成测试环境、模拟环境和线上环境，每个环境可以支持多套，环境部署成功后会自动调用集成测试。 

每个产品有不同的发布流程。还有的是配置没做到抽取，所以会有发布到每个环境时，都需要从源代码构建。 原则上： 代码和配置要做分离的。

2.2 CD系统支撑

系统调用，代码管理使用 GitLab ，中间是 Jenkins，通过 Jenkins 打包，部署工具使用 Rundeck ，当部署完成时自动调测试。

2.3 CD.jenkins 实战

Jenkins 实际使用我们分为以下五点：

• JOB-DSL
• Nested View
• Pipeline
• Slaves
• Groovy

• JOB-DSL ，单项目构建好模型后，从代码到某个环境或者从环境到某个环境，会用 JOB-DSL 批量做生成；

• Nested View ，切成两级或者三级，现在有1000+的job，可以按照1级或者2级产品线去做归类；

• Pipeline 目前主要用在是批量构建，一个产品有可能拆成50个微服务，在开发阶段经常需要批量执行所有服务的构建部署。

• Slaves 目前运行在 Docker容器中 ，理想状态是Master 上不做构建（目前我们在master上还有少量工程）。这样master上做升级和迁移会容易很多。另外一个原因是：用docker做构建环境的管理：有的团队用 Python ，有的团队用 JAVA 等等，使用docker可以把环境描述成文件。

使用 Groovy Scripts 来配置JOB的权限 。

2.3.1 JOB-DSL

JOB-DSL ，会把所有的产品解析出来之后就是一个简单的模板，做完之后就是我想要的状态。

有一个输入参数，在下面判断一下git什么样，下面的图都是在上面的DSL上面定义完成后自动生成的。

Build 脚本里，把工程名称记下来，他的产品名称、组件名，从哪到哪，比如从代码到测试环境还是从测试环境到集测，最后会加载一下。比如你要到集测，加载集测环境的那些配置，假如用其他工具可能是其他的配置。

下面的图则是我们构建的输出日志。

2.3.2 Nested View

上图是一个CD例子，产品A的工程 Login-Server 的发布流程，代码构建到发布测试环境到集成测试环境到生产环境。
下图是 Nested View 我做的一个 Demo。

比如可能在这边派一些脚本，几个脚本就可以实现产品A和产品B，产品A下面有 CI、DEV、INTE、NEXUS 等。

2.3.3 Pipeline

后面说一下 Pipeline ，在 Pipeline 里面，它的 list 集成里有两个项目，一个cd，一个ci，最后生成的样子如下图的。

上面说的所有的单工程或者 Pipeline 的工程都是可以通过 JOB-DSL 全部把它生成出来的。

2.3.4 Slave

Slave这块，使用 slave Docker 镜像，构建环境隔离，添加 slave 到 Jenkins 。

根据环境需要，做一个镜像，可以不影响其他人的场景下把这个做起来。

这也是前几天做的一个 Demo ，我们会把M2和WS这两个目录画出来，这两个目录经常会读写。正常来说，做得好的话是无状态的，把WS和M2丢掉，重新再构建一次，跟这个结果应该是一样的。 BUILD_DATA 是构建中临时产生的文件，都放到 var/data 下面。容器启动完之后，把密码改掉，给这些目录加一个权限，如下图挂进来就可以正常运行了。

2.3.5 Groovy demo

如果用好 Jenkins ，你可能需要了解 Groovy ，前面在 JOB-DSL 里没有加权限，这样可能需要一个 Groovy 脚本把相应的权限加上。

如上图把这三个人加一个执行权限，到产品AA的Dev阶段的JOB配置权限。 Groovy 那个例子不太好，在 JOB-DSL 里也有一些配置可以做到类似的功能，脚本的量会更少一些。

三、CI 中 jenkins 详解

3.1 CI系统支撑

CI， Trigger ， Jenkins ，取代码，一般做编译，自动化单测，还有 Sonar 自带的一些东西，有的可能会做集成测试。页边会做度量系统，比如按部门/产品汇总，可以给每个产品或者每个部门提供相应的代码重复率、注释率、类复杂度、阻断性问题单测覆盖率、集测覆盖率的数据。

3.2 CI.jenkins 实战

在CI我们是如何使用 jenkins 的，主要是插件的使用，我们主要使用的为下面4种：

• Gitlab
• Dashboard
• Ext mail
• Sonar
  

所有的 Jenkins 装插件的时候，装多了容易引起各种各样的问题，像 Maven 那种我们是不装的，虽然是官方维护的，也觉得它不是一个特别好的插件。在这边我们选了 GitLab ； Dashboard 则能在上面生成一些图表，静态分析的报告；邮件的选了 ext mail ，做自定义的邮件的推送。所有工程的脚本，后面都会统一成一个入口，这个工作现在还在做。最后会把静态分析报告加 Findbugs 和 PMD 发送出来。构建失败，或者有新增的 findbugs 警告的时候就会发邮件给大家。现在在部署那个环节，编译的时候也会去检查，如果有 findbugs ，只要有一个就会给他报过去。

3.2.1 Gitlab

这是 Jenkins-GitLab ，可以更好的做一些集成，也在 commit 的时候，根据注释里的关键字做一些相应的东西，这是很好的一个功能。

3.2.2 Dashboard

现在说 Dashboard ，比如pmd的警告可能会放在上面，下面会显示一些总共有多少个，高级别的什么样的，中级别的什么样的，低级别的什么样的。前年去做 findbugs 清理的时候，发现 findbugs 是非常管用的东西。 Dashboard 可以做一些图表和界面的显示，尤其你在做pmd的时候，数据展示会非常方便。这个显示结果 findbugs 有0个， PMD 警告有5个。

3.2.3 Mail

ext-mail是发邮件，如果失败的时候发给谁，如下图：

另外还有 Script，写一些脚本去定义它，如果有新增，把邮件发给谁。下图是 Script 的脚本：

下面这个截图是之前那个界面里，CI_JOB_DSL扩展 mail， DSL 默认的命令不多的，包括现在我们在用的，后面会有一个脚本，重置所有的扩展邮件，把所有的 Jenkins job 改一遍。

3.2.4 Sonar

Sonar，这是我们现在的一个界面，它会给你提供很多的信息。

下图是之前有一些列表的东西，有一些饼图、柱图。

我们会在度量系统里把这些数据收集起来，比如哪个部门哪个产品的，上个月和这个月的数据。

四、chat-bearychat

最后是chat cd，现在说聊天机器人是比较好用的东西，我们这边也在做这种。

最后选的 bearychat ，再加 Jenkins 。 hubot 版本是2.19.0，bearychat是0.7.2，效果是不用打开网页点点点。在聊天室，所有触发的动作其他人可以看到，输入命令行是一样的。还有一个比较方便的点，手机端装一个 bearychat 客户端，比如你正在坐班车或者正在下班路上，手机可以触发一些事，也可以查某个机器的状态。 hubot 和其他工具也可以做集成，如 Jira 、 GitLab ，提供更加快捷的方式。

这是 bearychat 自己的插件，比如说 JAM/ci-demo ，我昨天晚上派完之后，这边会有一个，你派完了，触发一个工程，加一些 bearychat 的，编译完之后发布这个结果，然后它自己就会带过来，这个 bearychat 是用自身的东西去做的通知。

hubot Jenkins ，跟它说把所有的job列表打出来，它就说这些是列表。

如果想看编译结果，就说show output for demo-a。