pipeline 结构设计

目录

• 一.pipeline步骤
• 二.案例
  • pipeline详解
  • 只生成一次制品
  • 不同环境部署
  • 系统集成测试
  • 指定版本部署

一.pipeline步骤

当团队开始设计第一个pipeline时，该如何下手呢?以下是笔者的设计步骤，仅供参考。

第1步:了解网站的整体架构。这个过程就是了解系统是如何服务用户的。其间，还可以识别出哪些是关键系统。

第2步:找到服务之间、服务与组件之间、组件之间的依赖关系。第3步:找到对外依赖最少的组件，将其构建、打包、制品管理自动化。

第4步:重复第3步，直到所有（不是绝对)的组件都使用制品库管理起来。

第5步:了解当前架构中所有的服务是如何从源码到最终部署上线的。

第6步:找出第一个相对不那么重要的服务，将在第5步中了解到的手动操作自动化。但是，通常不会直接照搬手动操作进行自动化，而是会进行一些改动，让pipeline更符合《持续交付》第5章中所介绍的“部署流水线相关实践”内容。

另外，之所以先从一个不那么重要的服务下手，是因为即使自动化脚本出现错误，也不至于让大家对自动化失去信心。这个过程也是让团队适应自动化的过程。

第7步:重复第6步，直到所有服务的所有阶段都自动化。这一步不是绝对的，也可以先自动化一部分服务，然后开始第8步。

第8步:加入自动化集成测试的阶段。

在现实项目中，远没有这么简单。而且，整个过程并不一定是顺序进行的，而是需要几个来回。

如果当前服务没有日志收集和监控，那么在第3步时就要开始准备了，免得后期返工。在第8步以后就要看团队的具体需求了。

二.案例

假设存在一个X网站，我们需要使用上一节介绍的步骤来设计其pipeline。

通过与X网站的团队进行沟通(通常不止一次沟通)，总结出它的(不是严格意义的）架构

A和B都是后端服务，它们共同依赖于common组件。F是一个Node.js服务。LB1和LB2分别负责前端的负载和后端的负载。

现在我们已经完成第1、2步。

第3步，很容易就能找出依赖最少的组件:common。它的pipeline非常简单，只需要编译打包并上传到制品库即可。读者参考第2、3章就可以独立完成。

第4步，省略。

第5步，A服务承载的业务相对不那么重要，我们就从它开始。那么，之前A服务是怎么从源代码到最终部署上线的，笔者了解到×网站的成员都是自己打包自己所负责的服务的，然后把制品以邮件的方式发给运维人员，运维人员再把制品复制到目标服务器，然后逐台机器更新服务。

第6步，开始设计A服务的pipeline。这个过程不是一次就能做到相对完善的，而是需要多次迭代调整才能实现。我们跳过这个演进过程，为A服务设置了以下几个阶段

A服务的Jenkinsfile内容如下:

//引入zpipelinelib共享库
@Library('zpipelinelib@master') _
pipeline {
    agent any
    tools{ amven 'maven-3.5.2' }
    parameters {
        string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '')
    }
    environment{
        _service_name = 'a-service'
        、、zGetVersion方法用于生成版本号
        _version = zGetVersion("${BUILD_NUMBER}", "${env.GIT_COMMIT}")
        //配置的版本
        _dev_config_version = 'latest'
        _staging_config_version = 'abcd'
        _prod_config_version = 'cdefg'
    }
    triggers{
        gitlab(triggerOnPush:true, triggerOnMergeRequest:true, branchFilterType:'all', secretToken:"abcef")
    }
    stages {
        //因为编译完成后，通常制品就在编译的那个Jenkins agent上
        //编译打包和上传制品，放在一个阶段就可以了
        stage("构建"){
            steps {
                zMvn("${_version}")
                zCodeAnalysis("${_version}")
                zUploadArtifactory("${_version}","${_service_name}")
            }
            post {
                //这时失败了，只发送消息给导致失败的相关人员
                // currentBuild变量代表当前的构建，是pipeline中的内置变量
                failure { zNotify( "${_service_name}", "${_version}", ['culprits'], currentBuild)}
            }
        }
        stage("发布到开发环境"){
            steps{
                zDeployService("${__service_name}", "${__version}", "${__dev_config_version}", 'dev')
                input message: "开发环境部署完成，是否发布到预发布环境？"
            }
            post {
                failure { zNotify( "${__service_name}", "${__version}", ['culprits'], currentBuild)}
            }
        }
        stage("发布到预发布环境"){
            when { branch 'release-*'}
            steps{
                zDeployService("${__service_name}", "${__version}", "${__staging_config_version}", 'staging')
            }
            post {
                //发布消息给团队中所有的人
                always { zNotify( "${__service_name}", "${__version}", ['team'], currentBuild)}
            }
        }

        stage("自动化集成测试"){
            when { branch 'release-*' }
            steps{ zSitTest('staging') }
            post {
                always { zNotify( "${__service_name}", "${__version}", ['team'], currentBuild)}
            }
        }
        stage("手动测试"){
            when { branch 'release-*' }
            steps{ input message:"手动测试是否通过？ " }
            post {
                failure { zNotify( "${__service_name}", "${__version}", ['team'], currentBuild)}
            }
        }
        stage("发布到生产环境")
            when { branch 'release-*' }
            steps{
                script{
                    def approvalMap = zInputDeployProdPassword()
                    withCredentials(
                        [string(currentBuild:'secretText', variable:'varName')]) {
                        if("${approvalMap['deployPassword']}" == "$${varName}"){
                            zDeployService("${__service_name}",
                                "${__version}",
                                "${_prod_config_version}", 'prod')
                        } //end if
                    } //end withCredentials
                }
            }
            post {
                always { zNotify( "${__service_name}", "${__version}", ['team'], currentBuild)}
            }
        stage("生产环境自检"){
            when { branch 'release-*' }
            steps{ zVerify('prod') }
            post {
                always { zNotfiy( "${__service_name}". "${__version}". ['team'], currentBuild) }
            }
        }
    } //stages
    post {
        always { cleanWs() }
    }
} //pipeline

pipeline详解

在×网站pipeline 中，凡是以“z”字母开头的步骤都是zpipelinelib共享库提供的步骤，如zMvn、zCodeAnalysis。换句话说，我们将pipeline的具体操作隐藏在zpipelinelib共享库中。这就像在编程语言中接口与具体实现类的关系。pipeline只负责调用接口，表达意图;共享库则负责实现接口。为什么这样做呢?有以下几个理由。

• pipeline的设计者可以更关注设计。
• pipeline的各阶段意图更清晰。
• 可维护性更好。只需要修改zpipelinelib共享库，所有引用了该共享库的pipeline都会被修改。

只生成一次制品

只生成一次制品，这是《持续交付》中提到的一个非常重要的实践。

在environment指令中，我们使用zGetVersion步骤获得版本号并赋值给变量_version。在构建阶段，我们使用_version的值生成制品，并上传到制品库。之后所有的阶段，都使用此版本号从制品库中获取制品。

不同环境部署

对不同环境采用同一种部署方式，这也是《持续交付》中提到的另一个非常重要的实践。

X网站有三个环境:开发环境( dev)、预发布环境( staging )和生产环境( prod )。对于这三个环境，我们都使用同一个步骤完成——zDeployService。zDeployService步骤的关键参数是版本号及目标部署环境。

实现这一步并不简单，因为要实现将同一制品部署到不同的环境，就必须做到制品与配置的分离。本例中A服务是基于Springboot框架实现的，配置使用了Springboot的Profiles特性，代码结构如下∶

那怎么分离呢?其实，制品与配置分离不是最终目的，最终目的是将配置项与配置值分离。部署脚本只存放配置项，配置值应该由类似于配置中心的地方提供。比如在部署脚本中，配置文件application.yml只存储配置项。

thread.pool.num={{a.service.threadPoolNum}}

在配置中心中，配置值以缓解维度进行区分，比如在开发环境下：

a.serverice.threadPoolNum:64

而在预发布环境下，该配置值又变成了：

a.serverice.threadPoolNum:128

实现配置项与配置值分离后，不同环境使用同一种部署方式就完成80%了。

配置也是需要版本化的。environment指令中的三个__**config version变量用于指定不同环境的配置的版本

系统集成测试

虽然A服务的单元测试覆盖率达到了100%，但是这也不能代表A服务与其他系统集成后，整个环境是可以正常工作的。因此，还要进行集成测试。

也就是说，在部署A服务完成后执行集成测试。在A服务的pipeline，zSitTest步骤的左右，它会触发集成测试pipeline。

集成测试pipeline通常是一个独立的代码仓库。

指定版本部署

可以看出，目前A服务是无法指定版本部署的，pipeline执行的代码始终是代码仓库中最新版本的代码。

我们可以在A服务的pipeline中加入入参参数，用于指定部署版本。然后再pipeline中加入判断，当有指定版本参数传入时，就跳过构建阶段，而在其他阶段使用指定版本的制品。

pipeline的设计还与代码的分支管理策略有关。由于X网站上线频繁，所以采用主干开发、发布分支的策略。在发布到开发环境后的所有阶段都只对release-*分支有效。