从零到一，构建你的持续交付流程（五）：使用Jenkins Pipeline，让交付流程与自动化
从零到一，构建你的持续交付流程（五）：使用Jenkins Pipeline，让交付流程与自动化
本篇，我们将基于Jenkins Pipeline来搭建一个持续交付流程。
在这个交付流程中，我们将做到：
- 支持手动触发启动这个交付流程
- 整体流程为：从git代码控制开始，更新代码，编译与构建二进制包，制作docker镜像，重启服务
本篇为从零到一，构建你的持续交付流程第五篇，本系列其它文章为：
- 从零到一，构建你的持续交付流程（一）：一个持续交付流程的构思
- 从零到一，构建你的持续交付流程（二）：好的工程实践是必要的前提
- 从零到一，构建你的持续交付流程（三）：搭建基于Jenkins+Docker的持续交付环境
- 从零到一，构建你的持续交付流程（四）：利用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来配置，这是最方便的
第四步：手动触发构建
执行完一段时间后，如果没有出现错误，你就可以见到下面这个图。这个图直观的展现了每个过程所用的时间及是否成功。
五）
最简单的一个自动化就是上面这样了，从你需要写的代码上来看，太简单了。
当然，仔细观察上面这个持续交付过程，它没有真正意义上并没有闭环。表现在：
- 它需要手动触发，这并不是一个好方式。至少比如在开发环境可以让触发的过程也自动化。
- 它没有通知。不管成功或失败，都没有通知。
- 基于docker重启服务的方式并不完善（docker run -dp 8090:8080 test-backend:1），这种方式相当于每次新建了个服务，这不是我们想要的，我们更希望它是restart方式的。
- 这只是后端一端，一个项目至少会包含后端+前端
- 阶段过程较少，类似单元测试，质量分析与检测及API文档或服务验证等过程都没有
也就是说，这个能跑起来的简单DEMO，还是没有闭环。至少要补充1-4这四个点，才真正算一个闭环的持续交付。
下一篇：从零到一，构建你的持续交付流程（六）：一个闭环的持续交付