DevOps的探索？（篇三）百科中对Jenkins的解释：Jenkins是一个开源软件，是基于java开发的一种持续集成

上文传送门

CI/CD实现

上文我们分析了什么是CI/CD以及它们的作用，本文我们来重点探索CI/CD如何实现，是通过什么工具来实现。市面上公司常用的持续集成工具有Jenkins，BuildMaster，Microtica，Bamboo，CircleCI，TravisCI，Buddy，GoCD等等等等，其中最常用的莫属Jenkins。接下来我们就来探索一下Jenkins这个持续集成工具的实现原理。

Jenkins

百科中对Jenkins的解释：Jenkins是一个开源软件，是基于java开发的一种持续集成工具。用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。主要功能是：1、持续的软件版本发布/测试项目。2、监控外部调用执行的工作。

Jenkins的使用

自动化构建

我们在探索底层原理前，先来明确一下它的使用方法和工作流程。当然我们这里会省略掉Jenkins的安装部署与基本的配置，我们假设你对安装与部署工具的流程已经基本熟悉。Jenkins具有非常优秀的可视化Web端页面来提供给开发团队更轻松的配置与使用。在我们配置好git插件以及账户信息后，我们开始创建一个新任务，根据表单内容依次填入代码仓库地址，团队大多使用gitlab，接下来填入要构建的代码分支。然后选择构建一个触发器，接着我们一步一步进行配置，填写jenkins构建时执行的shell脚本。在这里大家会对Jenkins构建时填写的shell脚本产生疑惑，甚至可能会有小伙伴认为，Jenkins不是自动化CI的吗，为什么还要填入脚本。实际上，Jenkins仅仅是一个类似流水线的自动化工具，关于流水线我们会在后续详细讲解。我们现在可以把Jenkins当成一辆汽车的生产工厂，而构建就是组装零件部分的流水线，而我们填入的脚本，就是让Jenkins明白，把git分支上的代码拿到后该如何操作如何构建，Jenkins并不知道gitlab上的代码是什么语言，更不懂如何构建，因此就需要我们在此填写shell脚本。下面我们拿前端当下主流的vue框架的前端代码的构建shell脚本举例，

node -v
npm install
npm run build
cp -rf ./dist/ /xxxx

实际上只是检查版本，安装相关依赖，编译构建，把产物拷贝到我们需要取包的文件路径。当然，我们可以直接把构建后的产物直接压缩，方便存取。

cd dist
tar -zcvf xxxx.tar.gz *

到此，最简单的自动化构建我们就完成了。如果配置好构建器，我们这时就可以在每次提交代码时，Jenkins就自动帮我们构建好产物之后压缩成压缩包放在我们提前设置好的路径中，是不是感觉很方便，无需每次更新代码后，开发团队在本地频繁的消耗时间编译构建，把产物手动压缩成压缩包，再放到指定目录下。从此刻开始，开发团队仅仅需要开发功能，写好代码。接下来的一切的一切都无需浪费时间处理，而这，才是Jenkins的第一步。

自动化测试

前面介绍了自动化构建，那么如果我们期望把自动化构建后的产物进行测试呢？我们通过邮件或者其他通讯软件一次次发给测试团队吗？当然不是，我们测试环节也可以通过Jenkins完成自动化测试。在这里我们重点关注Jenkins如何在自动化构建后如何完成自动化测试，我们对自动化测试脚本的开发和原理不做探讨。我们可以安装junit插件来完成自动化测试，把相应自动化测试的py执行脚本写在构建成功后操作的shell脚本，并且可以通过配置邮箱等信息，把测试成功或者失败的日志和结果实时同步发送到对应的测试团队负责人，也可以把测试报告保存在我们需要保存的文件路径中。

自动化部署

如果自动化构建成功并且自动化测试也全部通过后，我们当然也不是把测试通过没问题的项目构建产物手动发送给对应的运维团队，接下来可以自动化部署。首先我们需要在web端的Jenkins配置服务器相关信息，包括ip，端口，用户名，密码。配置完成后，在确认自动化测试没问题后，可以对应执行相关shell脚本，把构建成功后的项目文件拷贝到对应服务器环境相关目录下，并通过脚本重启tomcat，当然，此时我们在成功重启tomcat后，发送邮件或者公司内部通讯工具通知到对应的运维开发团队。此时，我们的整套Jenkins流水线就已经完成，从构建，测试，部署。我们回过头来梳理时会发现，开发团队仅需要开发新功能自验无误后提交代码到git仓库即可；测试团队仅需要把相关功能模块的自动化测试脚本写好即可；运维团队仅需要对自动部署好的环境对应检查即可。这一切听起来都非常清晰流畅，并且能紧密的持续沟通开发，测试与运维。现在有一个问题，每次都要手动在web端页面上一点点配置吗，一步步填写对应流程的shell脚本吗，这些谁来负责写，每个项目都要重新写吗。这时，我们来了解一个Jenkins中最关键的核心概念，那就是Jenkinsfile。

Jenkinsfile

在官方文档中：Jenkinsfile是一个文本文件，它包含了 Jenkins 流水线的定义并被检入源代码控制仓库。下面的流水线实现了基本的三阶段持续交付流水线。不是所有的流水线都有相同的三个阶段，但为大多数项目定义这些阶段是一个很好的开始。

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building..'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing..'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying....'
            }
        }
    }
}

我们等下在探讨内部的语法，大体上我们可以了解到，在Jenkinsfile定义了执行到对应步骤的操作。我们可以把对应的项目的构建，测试，部署的shell脚本写入其中，并将该文件存放在对应项目的git仓库的根目录。当用户将代码提交到git时，Jenkins从git拉取最新代码，读取根目录下的Jenkinsfile文件，并依次执行文件中定义的任务。我们可以在Jenkinsfile中定义任何我们想要Jenkins帮助我们做的任何事。我们可以通过when语法，if/else语法等等来定义当失败时执行什么，邮件通知日志报告和结果状态，成功时执行什么。当然这只是Jenkinsfile中的最简单基础的语法，我们在明白了Jenkinsfile的工作流程后，来详细的了解一下Jenkinsfile一些常见语法。

Jenkinsfile语法

agent - 指定在哪台机器上执行任务，为必填项
stage - 组成工作流的大的步骤，这些步骤是串行的，例如build，test，deploy等
steps - 描述stage中的小步骤，同一个stage中的steps可以并行
sh - 执行shell命令
input - 需要你手动点击确定，Pipeline才会进入后续环节，常用于部署环节，因为很多时候部署都需要人为的进行一些确认
post- 所有pipeline执行完成后，会进入post环节，该环节一般做一些清理工作，同时还可以判断pipeline的执行状态
options-在pipeline内或stage内提供附加的控制
parameters-启动 pipeline 之前可以输入的参数，可以输入各种类型参数。
environment-设置环境变量
这些也只是一些基础的语法，语法中的对应选项以及更多的语法大家可以参考官方文档。后文我们会从服务器的角度深入探讨Jenkins。

DevOps的探索？（篇三）