从零到一，构建你的持续交付流程（五）：使用Jenkins Pipeline，让交付流程与自动化

本篇，我们将基于Jenkins Pipeline来搭建一个持续交付流程。

在这个交付流程中，我们将做到：

• 支持手动触发启动这个交付流程
• 整体流程为：从git代码控制开始，更新代码，编译与构建二进制包，制作docker镜像，重启服务

本篇为从零到一，构建你的持续交付流程第五篇，本系列其它文章为：

1. 从零到一，构建你的持续交付流程（一）：一个持续交付流程的构思
2. 从零到一，构建你的持续交付流程（二）：好的工程实践是必要的前提
3. 从零到一，构建你的持续交付流程（三）：搭建基于Jenkins+Docker的持续交付环境
4. 从零到一，构建你的持续交付流程（四）：利用Docker，将服务容器化

一）

首先，稍微解释下什么是Jenkins与Jenkins Pipeline吧。

Jenkins

Jenkins是自动化领域非常重要的一个产品，它是基于Java语言的一个开源免费的自动化产品。

使用Jenkins，你几乎可以将一切需要手动执行的各种任务自动化。Jenkins更重要的一点是它有许多官方或社区提供的插件，这些插件使得我们做自动化更方便与简单。

在自动化领域，还有一些类似travis的开源竞争者，另外像是github与gitlab等也提供了类似的机制，github叫github actions，但这些的影响力与知名度都无法与Jenkins相比。

Jenkins Pipeline

Pipeline的意思是管道，熟悉shell脚本的就比较清楚pipeline的概念。

形象的说，用流水线来形容它比较合适。我们都知道，在工业领域，流水线的方式是最高效的方式，一个任务OK后，流到下一个任务，如此往复，最终产品出来，整个流水线的动作基本都是自动化的，人则成为了流水线上没有太多价值的工具。

这就是Jenkins Pipeline，它可以帮助你将从源码更新代码到最终构建产品包，甚至是部署以及发布都以流水线的方式，一个步骤接一个步骤执行。

Jenkins pipeline是基于DSL领域特定语言而构建，这使得它的语法极为简洁与优雅。

如上图所示，持续交付的整个过程，就像一个流水线一样，一个步骤接一个步骤来执行。

二）

Jenkins Pipeline支持两种语法，一种是新的Declarative Pipeline，另一个是旧的存在时间更久的Scripted Pipeline

不管是你已经熟悉Scripted Pipeline还是没有，我个人都建议使用Declarative Pipeline，因为相比之下，它更简洁与优雅。

一个最简单的基于Declarative Pipeline的hello world实现是:

pipeline {
    agent any 
    stages {
        stage('编译项目') {
            steps {
                echo 'Hello world!' 
            }
        }
    }
}

这个脚本定义了一个名为编译项目的stage，也就是阶段，然后这个state就是输出了一个'hello world'字符。

这就是Jenkins Pipeline，它基于自身特定的DSL，整体上给人非常简洁与优雅的感觉。

如果与过往的shell脚本实现来相比，确实令人觉得更舒适。

三）

按照上述设计，我们希望从代码更新，到服务重启，都能自动化。

在我们的test-backend项目下，创建一个Jenkinsfile文件，内容如下

(直接访问或使用https://gitee.com/mydddOrg/test-backend 也行，这是我创建的public git)

   pipeline {
       agent any
  
       stages {
           stage('build') {
               steps {
                   sh 'gradle build -x test'
               }
           }
 
          stage('docker image build'){
              steps {
                  sh 'docker build -t test-backend:1 .'
              }
          }
 
          stage('start docker'){
              steps {
                  sh 'docker run -dp 8090:8080  test-backend:1'
              }
          }
      }
  }

简要解释

• 行2：是指这个pipeline可以在jenkins的任务节点上运行（jenkins本身可以做集群，甚至包括不同的操作系统节点）
• 行5：定义一个阶段，叫build。就是指构建
• 行6: 定义build阶段的steps，也就是过程，在这我们就是调用gradle去编译构建这个项目
• 行11，行17：定义其它两个阶段及其过程

从上面这个DSL脚本来看，整体上来说是非常简洁与易懂的。

把这个Jenkinsfile提交到你的git中。

四)

从上面这个定义可以看到，我们是把Jenkinsfile文件定义在git中，而不是jenkins中，这就是Jenkins Pipeline的一大优点，它的定义是跟着你的源码走，而不是在Jenkins中。

这意味着，你可以在同一分支定义不同的Jenkinsfile，比如Jenkinsfile-dev,Jenkinsfile-test,Jenkinsfile-prod等，不同分支也可以定义自己的Jenkinsfile，这样后面运行它的灵活性就非常强。不被特定部署限定。

因为Jenkinsfile是定义在git中的，所以Jenkins中的定义这个持续交付就非常简单了。整个过程如图所示

注意：在前面的文章中，我是基于Docker安装Jenkins，在你没有完全理解Docker前，还是先本地安装Jenkins为宜，这样没有docker in docker的问题。 以下都是基于本地Jenkins服务而非Jenkins in Docker

第一步，创建item

第二步：创建一个新的流水线

在新建的item中，我们选择流水线

第三步：配置git

因为我们的Jenkinsfile是放在git中，所以我们基于git来配置，这是最方便的

第四步：手动触发构建

执行完一段时间后，如果没有出现错误，你就可以见到下面这个图。这个图直观的展现了每个过程所用的时间及是否成功。

五）

最简单的一个自动化就是上面这样了，从你需要写的代码上来看，太简单了。

当然，仔细观察上面这个持续交付过程，它没有真正意义上并没有闭环。表现在：

1. 它需要手动触发，这并不是一个好方式。至少比如在开发环境可以让触发的过程也自动化。
2. 它没有通知。不管成功或失败，都没有通知。
3. 基于docker重启服务的方式并不完善（docker run -dp 8090:8080 test-backend:1），这种方式相当于每次新建了个服务，这不是我们想要的，我们更希望它是restart方式的。
4. 这只是后端一端，一个项目至少会包含后端+前端
5. 阶段过程较少，类似单元测试，质量分析与检测及API文档或服务验证等过程都没有

也就是说，这个能跑起来的简单DEMO，还是没有闭环。至少要补充1-4这四个点，才真正算一个闭环的持续交付。

下一篇：从零到一，构建你的持续交付流程（六）：一个闭环的持续交付