Jenkins 测试流水线实战——Pipeline as Code、并行阶段、测试报告集成

适读人群：DevOps 工程师、测试工程师、后端工程师 | 阅读时长：约 15 分钟 | 核心价值：用 Jenkinsfile 构建生产级测试流水线，掌握并行 Stage、测试报告集成、环境隔离最佳实践

---

我在一家国企下属的技术公司做过三年顾问，那里的 IT 环境极其典型：代码不能上外网，GitHub 进不去，GitLab 也是私有化部署，CI/CD 工具只有一个选项——Jenkins。

当时项目组的 Jenkins 用法让我大开眼界：所有 CI 配置都是通过 Jenkins Web 界面点点点设置的，没有一行配置代码写进版本控制。某次一个运维离职，新来的人完全不知道那些 Job 是怎么配置的，重新从头搭了两周。

我第一件事就是推行 Jenkinsfile——把所有流水线配置写成代码，和业务代码一起提交到 Git。这一篇，我把当时做的那套最佳实践完整地分享出来。

---

1. Declarative Pipeline vs Scripted Pipeline

Jenkins Pipeline 有两种语法，新项目推荐用 Declarative：

// Declarative Pipeline（推荐）
pipeline {
    agent any
    
    stages {
        stage('Build') {
            steps {
                sh 'go build ./...'
            }
        }
        stage('Test') {
            steps {
                sh 'go test ./...'
            }
        }
    }
    
    post {
        always {
            echo 'Pipeline finished'
        }
        success {
            echo 'All stages passed!'
        }
        failure {
            echo 'Pipeline failed!'
        }
    }
}

Scripted Pipeline 更灵活（Groovy 代码），但维护成本高。Declarative 结构清晰、IDE 支持好，95% 的场景足够用。

---

2. 完整 Go 项目 Jenkinsfile

// Jenkinsfile（放在项目根目录）
pipeline {
    agent {
        docker {
            image 'golang:1.22-alpine'
            args '-v /root/go-cache:/root/go/pkg/mod'  // 挂载模块缓存
        }
    }
    
    environment {
        GOPATH = '/root/go'
        GOPROXY = 'https://goproxy.cn,direct'  // 国内环境
        CGO_ENABLED = '0'
    }
    
    options {
        timeout(time: 30, unit: 'MINUTES')
        buildDiscarder(logRotator(numToKeepStr: '20'))
        disableConcurrentBuilds()
    }
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
                sh 'go version'
                sh 'go env'
            }
        }
        
        stage('Dependencies') {
            steps {
                sh 'go mod download'
                sh 'go mod verify'
            }
        }
        
        stage('Lint') {
            steps {
                sh '''
                    go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
                    golangci-lint run --timeout=5m ./...
                '''
            }
        }
        
        stage('Test') {
            steps {
                sh '''
                    go test \
                        -race \
                        -covermode=atomic \
                        -coverprofile=coverage.out \
                        -v \
                        ./... \
                        2>&1 | tee test-output.txt
                '''
                
                // 转换为 JUnit XML 格式（需要 go-junit-report）
                sh '''
                    go install github.com/jstemmer/go-junit-report/v2@latest
                    go-junit-report -in test-output.txt -out junit-report.xml -set-exit-code
                '''
            }
            
            post {
                always {
                    // 发布 JUnit 测试报告
                    junit 'junit-report.xml'
                    
                    // 发布覆盖率报告
                    publishHTML(target: [
                        allowMissing: false,
                        alwaysLinkToLastBuild: true,
                        keepAll: true,
                        reportDir: '.',
                        reportFiles: 'coverage.html',
                        reportName: 'Coverage Report'
                    ])
                }
            }
        }
        
        stage('Coverage Gate') {
            steps {
                script {
                    def coverage = sh(
                        script: "go tool cover -func=coverage.out | grep '^total:' | awk '{print \$3}' | sed 's/%//'",
                        returnStdout: true
                    ).trim()
                    
                    echo "Coverage: ${coverage}%"
                    
                    if (coverage.toFloat() < 80.0) {
                        error("Coverage ${coverage}% is below 80% threshold")
                    }
                }
            }
        }
        
        stage('Build') {
            steps {
                sh 'go build -o bin/myapp ./cmd/myapp'
            }
        }
    }
    
    post {
        always {
            cleanWs()
        }
        failure {
            // 发送通知（企业微信/钉钉/Email）
            script {
                def msg = "❌ 构建失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}\n${env.BUILD_URL}"
                // sh "curl -X POST ..."
            }
        }
    }
}

---

3. 并行阶段：parallel 关键字

并行是 Jenkins Pipeline 的核心优化手段，适合相互独立的任务：

pipeline {
    agent any
    
    stages {
        stage('Parallel Tests') {
            parallel {
                // 单元测试
                stage('Unit Tests') {
                    agent { docker { image 'golang:1.22-alpine' } }
                    steps {
                        sh 'go test -short -race ./...'
                    }
                }
                
                // 集成测试（需要 Docker）
                stage('Integration Tests') {
                    agent { 
                        docker {
                            image 'golang:1.22-alpine'
                            args '--network=host'
                        }
                    }
                    steps {
                        // 启动测试依赖
                        sh 'docker-compose -f docker-compose.test.yml up -d'
                        sh 'sleep 10'  // 等待服务就绪
                        sh 'go test -run Integration -timeout 120s ./...'
                    }
                    post {
                        always {
                            sh 'docker-compose -f docker-compose.test.yml down -v'
                        }
                    }
                }
                
                // 静态分析
                stage('Static Analysis') {
                    agent { docker { image 'golang:1.22-alpine' } }
                    steps {
                        sh 'go vet ./...'
                        sh 'staticcheck ./...'
                    }
                }
            }
        }
    }
}

---

4. 多项目 Mono-Repo Jenkinsfile

// 根据变更的文件决定跑哪些测试
pipeline {
    agent any
    
    stages {
        stage('Detect Changes') {
            steps {
                script {
                    def changedFiles = sh(
                        script: 'git diff --name-only HEAD~1 HEAD',
                        returnStdout: true
                    ).trim().split('\n')
                    
                    env.GO_CHANGED = changedFiles.any { it.startsWith('services/go/') }.toString()
                    env.JAVA_CHANGED = changedFiles.any { it.startsWith('services/java/') }.toString()
                    env.PYTHON_CHANGED = changedFiles.any { it.startsWith('services/python/') }.toString()
                    
                    echo "Go changed: ${env.GO_CHANGED}"
                    echo "Java changed: ${env.JAVA_CHANGED}"
                    echo "Python changed: ${env.PYTHON_CHANGED}"
                }
            }
        }
        
        stage('Tests') {
            parallel {
                stage('Go Tests') {
                    when {
                        expression { env.GO_CHANGED == 'true' }
                    }
                    steps {
                        dir('services/go') {
                            sh 'go test -race ./...'
                        }
                    }
                }
                
                stage('Java Tests') {
                    when {
                        expression { env.JAVA_CHANGED == 'true' }
                    }
                    steps {
                        dir('services/java') {
                            sh 'mvn -B test --no-transfer-progress'
                        }
                    }
                }
                
                stage('Python Tests') {
                    when {
                        expression { env.PYTHON_CHANGED == 'true' }
                    }
                    steps {
                        dir('services/python') {
                            sh 'pytest --cov=src -v'
                        }
                    }
                }
            }
        }
    }
}

---

5. 测试报告集成

5.1 JUnit 报告（自动解析测试结果）

Jenkins 内置 JUnit 插件，支持自动解析：

post {
    always {
        junit allowEmptyResults: true,
              testResults: '**/junit-report.xml',
              healthScaleFactor: 2.0  // 测试失败对 build 健康度的权重
    }
}

5.2 Coverage 徽章（Cobertura 格式）

// Go 转 Cobertura 格式
sh 'go install github.com/boumenot/gocover-cobertura@latest'
sh 'gocover-cobertura < coverage.out > coverage.xml'

post {
    always {
        // 需要安装 Cobertura Plugin
        cobertura coberturaReportFile: 'coverage.xml',
                  onlyStable: false,
                  failUnhealthy: true,
                  failUnstable: false,
                  lineCoverageTargets: '80, 75, 70'
    }
}

---

6. 踩坑实录

踩坑记录 1：Declarative Pipeline 里用 sh 多行命令，第一行失败后不停止

// 坑：每个 sh 命令的 exit code 独立，下面这样第一条失败后还会继续
steps {
    sh 'go test ./...'
    sh 'echo "still running after failure"'
}

// 正确：用 set -e 确保任意命令失败就退出
steps {
    sh '''
        set -e
        go test ./...
        go build ./...
    '''
}

踩坑记录 2：Docker agent 里的 workspace 权限问题

Jenkins 默认 workspace 目录权限是 jenkins 用户，但 docker image 里可能是 root 用户，导致文件权限冲突，测试产物（coverage.out、junit-report.xml 等）无法写入。

解决方案：在 docker args 里指定用户：

agent {
    docker {
        image 'golang:1.22-alpine'
        args '-u root:root'
    }
}

或者在 Dockerfile 里创建和 Jenkins 一致的用户。

踩坑记录 3：parallel stage 里一个失败导致其他 stage 也标记失败但继续运行

parallel 里某个 stage 失败后，其他 stage 仍会运行完，但整个 parallel stage 会标记失败。这是期望行为。但如果某个 stage 失败后你想立即停止其他 stage，可以用：

options {
    parallelsAlwaysFailFast()
}

---

7. Jenkins Shared Libraries：跨项目复用 Pipeline 逻辑

当一个团队有多个项目都用 Jenkins CI 时，复制粘贴 Jenkinsfile 是最常见的反模式。Jenkins Shared Libraries 可以把通用 Pipeline 逻辑封装成库，跨项目共享：

# 共享库项目结构（独立 Git 仓库）
jenkins-shared-libs/
├── vars/                   # 全局变量和函数（最常用）
│   ├── goTest.groovy       # go 测试流程
│   ├── javaTest.groovy     # java 测试流程
│   └── notifyWechat.groovy # 企业微信通知
├── src/                    # 辅助类（复杂逻辑）
│   └── org/company/ci/
│       └── BuildUtils.groovy
└── resources/              # 配置文件、模板
    └── defaults.yaml

// vars/goTest.groovy
def call(Map config = [:]) {
    def goVersion = config.get('goVersion', '1.22')
    def coverageThreshold = config.get('coverageThreshold', 80)
    def workDir = config.get('workDir', '.')

    pipeline {
        agent {
            docker { image "golang:${goVersion}-alpine" }
        }

        stages {
            stage('Test') {
                steps {
                    dir(workDir) {
                        sh '''
                            set -e
                            go mod download
                            go test -race -covermode=atomic -coverprofile=coverage.out ./...
                        '''
                    }
                }
            }

            stage('Coverage Gate') {
                steps {
                    script {
                        def cov = sh(
                            script: "cd ${workDir} && go tool cover -func=coverage.out | grep '^total:' | awk '{print \$3}' | tr -d '%'",
                            returnStdout: true
                        ).trim().toFloat()

                        if (cov < coverageThreshold) {
                            error("Coverage ${cov}% is below threshold ${coverageThreshold}%")
                        }
                    }
                }
            }
        }
    }
}

在业务项目的 Jenkinsfile 里使用共享库：

// @Library('jenkins-shared-libs@main') _  // 在 Jenkins 里配置好共享库路径

// Jenkinsfile
goTest(
    goVersion: '1.22',
    coverageThreshold: 85,
    workDir: 'services/order'
)

这样的封装让业务项目的 Jenkinsfile 极度简洁，CI 逻辑的维护集中在共享库里。

---

8. Jenkins 的组织级实践：蓝绿部署与回滚策略

Jenkins 不只是测试工具，对于无法使用云原生 SaaS 的企业环境，它往往也是部署控制中心。在 Pipeline 里实现安全的部署流程是非常重要的工程能力。

蓝绿切换的 Jenkinsfile 实现

蓝绿部署的核心是同时维护两套环境（蓝和绿），通过切换流量来实现零停机发布：

pipeline {
    agent any

    parameters {
        choice(name: 'TARGET_ENV', choices: ['green', 'blue'], description: '部署到哪个环境')
        booleanParam(name: 'SWITCH_TRAFFIC', defaultValue: false, description: '是否切换流量到新环境')
    }

    stages {
        stage('Deploy to Target') {
            steps {
                script {
                    def targetEnv = params.TARGET_ENV
                    sh "kubectl set image deployment/myapp-${targetEnv} app=myapp:${env.GIT_COMMIT_SHORT}"
                    sh "kubectl rollout status deployment/myapp-${targetEnv} --timeout=300s"
                }
            }
        }

        stage('Smoke Test') {
            steps {
                script {
                    def targetHost = params.TARGET_ENV == 'green' ? 'green.internal.example.com' : 'blue.internal.example.com'
                    sh "curl -f http://${targetHost}/health || (echo 'Smoke test failed!'; exit 1)"
                }
            }
        }

        stage('Switch Traffic') {
            when {
                expression { params.SWITCH_TRAFFIC }
            }
            steps {
                input message: "确认切换流量到 ${params.TARGET_ENV} 环境？"
                sh "kubectl patch service myapp -p '{"spec":{"selector":{"slot":"${params.TARGET_ENV}"}}}'"
                echo "流量已切换到 ${params.TARGET_ENV}"
            }
        }
    }

    post {
        failure {
            echo "部署失败，${params.TARGET_ENV} 环境保持当前状态，流量未切换"
        }
    }
}

把 Jenkins 融入工程文化

在纯离线或强管控的企业环境里，推行 Jenkinsfile 的过程往往不只是技术挑战，更是工程文化挑战。我在那个国企的经验是：从一个示范项目开始，把 Jenkinsfile 的好处用数据说话——在代码里的流水线配置变更记录清晰可查，谁在什么时候改了什么，出了问题可以 git revert，这比以前在 Jenkins Web 界面手动点点点不留记录要好得多。

有了一个说服力强的示范项目，推广到整个团队就自然多了。技术层面的改变往往最容易，人的习惯改变才是真正的挑战所在。把这一点放在心里，推行任何工程实践时都会少走很多弯路。

9. Jenkins 生态工具链与企业级实践

企业内部的 Jenkins 往往不是孤立的，它和代码仓库、制品库、安全扫描、部署平台都有集成需求。掌握 Jenkins 的生态集成，才能构建出真正完整的内部 CI/CD 体系。

与 Nexus/Artifactory 的制品管理集成

在无法使用公网的企业环境里，所有依赖都必须走内部制品库。在 Jenkinsfile 里配置制品库地址：

pipeline {
    agent any
    
    environment {
        MAVEN_SETTINGS = credentials('maven-settings-xml')  // 从 Jenkins Credentials 获取
        GOPROXY = "http://nexus.internal.company.com/repository/go-proxy/,direct"
        GONOSUMCHECK = "nexus.internal.company.com"
    }
    
    stages {
        stage('Build') {
            steps {
                // Maven 使用内部制品库
                sh "mvn -s ${MAVEN_SETTINGS} clean package -DskipTests"
                
                // 把构建产物发布到 Nexus
                sh "mvn -s ${MAVEN_SETTINGS} deploy -DskipTests"
            }
        }
        
        stage('Publish Image') {
            steps {
                script {
                    // 推送到内部 Harbor 镜像仓库
                    withCredentials([usernamePassword(
                        credentialsId: 'harbor-credentials',
                        usernameVariable: 'HARBOR_USER',
                        passwordVariable: 'HARBOR_PASS'
                    )]) {
                        sh "docker login harbor.internal.company.com -u ${HARBOR_USER} -p ${HARBOR_PASS}"
                        sh "docker push harbor.internal.company.com/my-team/myapp:${env.BUILD_NUMBER}"
                    }
                }
            }
        }
    }
}

与安全扫描工具的集成

企业级 CI 往往有合规要求，需要在流水线里集成代码安全扫描（SonarQube）、依赖漏洞扫描（OWASP Dependency Check）、镜像安全扫描（Trivy）：

stage('Security Scan') {
    parallel {
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('SonarQube') {
                    sh "mvn sonar:sonar -Dsonar.projectKey=myapp"
                }
                // 等待 Quality Gate 结果
                timeout(time: 1, unit: 'HOURS') {
                    waitForQualityGate abortPipeline: true
                }
            }
        }
        
        stage('Dependency Vulnerability Scan') {
            steps {
                sh '''
                    dependency-check.sh                         --project myapp                         --scan .                         --format XML                         --out dependency-check-report.xml                         --failOnCVSS 7
                '''
                dependencyCheckPublisher pattern: 'dependency-check-report.xml'
            }
        }
        
        stage('Container Image Scan') {
            steps {
                sh "trivy image --severity CRITICAL --exit-code 1 myapp:${env.BUILD_NUMBER}"
            }
        }
    }
}

把安全扫描写进 Jenkinsfile，不只是满足合规要求，更重要的是让开发团队直面安全问题——看到流水线因为高危漏洞失败，比收到一份安全报告邮件要有行动力得多。

Jenkins 的监控与可靠性

生产级 Jenkins 的稳定性直接影响团队效率。几个常见的可靠性实践：

一是 Jenkins 主节点与 Agent 分离。主节点只负责调度，测试和构建全部在 Agent 上运行。这样主节点负载低，即使某个构建任务崩溃也不影响主节点稳定性。

二是使用 Jenkins Configuration as Code（JCasC）。Jenkins 的全局配置、工具配置、安全策略用 YAML 文件描述并提交到 Git，实现"Jenkins 配置本身也是代码"。这样 Jenkins 宕机恢复或迁移时，可以快速重建完全一致的配置，不再依赖某个运维的记忆。

三是 Build History 清理策略。每个 Job 都配置 buildDiscarder(logRotator(numToKeepStr: '30'))，避免历史构建记录无限增长占用磁盘。

在那家国企推行 Jenkinsfile 三年后，有一次 Jenkins 主节点因为磁盘满了导致宕机，重启后所有 Job 配置全部从 Git 恢复，没有丢失任何流水线逻辑。这一次"事故"反而成了 Pipeline as Code 理念的最好广告——从那以后，再也没有人质疑"为什么要把 CI 配置写进代码库"这个问题了。

10. Jenkins 在 AI 时代的定位与演进

经常有人问我："现在都用 GitHub Actions 了，Jenkins 还有价值吗？"这个问题值得认真回答，因为它背后其实是"如何在技术选型里做正确决策"的问题。

Jenkins 的优势在几个特定场景里是不可替代的：

完全离网的企业环境。银行、军工、政府信息系统，不允许任何代码或构建日志离开内网。GitHub Actions、GitLab.com 这类 SaaS 服务根本进不来。Jenkins 私有化部署是这类场景的唯一选项。即使是 GitLab 私有化版本，其 CI Runner 的配置复杂度也往往高于 Jenkins。

遗留系统的 CI/CD 整合。大量传统企业有几十年的遗留系统，这些系统的构建过程极其复杂：依赖特定版本的 JDK（JDK 6、7）、特定版本的构建工具、特殊的环境配置。Jenkins 的极强可定制性，让它能和这些遗留构建过程整合，而 GitHub Actions 这类工具的标准化设计反而成了限制。

与企业内部系统的深度集成。企业内部有 JIRA、Confluence、Nexus、Sonar、钉钉/企业微信等一套完整的工具生态，Jenkins 的插件体系（超过 1800 个插件）能和这些工具逐一对接。这种集成深度是 SaaS CI 工具在短期内很难达到的。

然而，Jenkins 也有它的成本：运维负担重。Jenkins 主节点的备份、升级、插件兼容性管理，都需要专职的 DevOps 资源投入。如果一个团队没有专职的基础设施工程师，Jenkins 的运维成本很容易失控。

我的建议是：如果你的代码可以放在 GitHub 或 GitLab.com，用 GitHub Actions 或 GitLab CI；如果你必须私有化部署代码仓库，用 GitLab 私有化 + GitLab CI；只有当你的场景真的需要 Jenkins 的特有能力（遗留系统集成、特殊企业工具链、政策合规要求），再投入 Jenkins。

Jenkins 在 AI 辅助下的可能性

有趣的是，Groovy DSL 其实非常适合 AI 辅助生成。当你描述"我需要一个流水线，先并行跑单测和集成测试，只有两者都通过后才构建 Docker 镜像，然后需要手动审批才能推到生产"这个需求时，AI 能快速生成对应的 Jenkinsfile。这降低了 Jenkins 的使用门槛，让不熟悉 Groovy 的工程师也能快速上手。

工具本身是中性的，关键是理解它的适用场景和成本边界。Jenkins 没有过时，只是它最合适的场景更加明确了。这也是技术演进的正常轨迹——新工具出现后，旧工具找到它更专注的细分市场，而不是消亡。

11. 小结：Pipeline as Code 的工程哲学

Jenkinsfile 的本质，是把"如何构建、测试、部署"这个知识从人的脑袋里转移到代码文件里。这个转移看起来简单，背后是工程文化的转变：从"凭经验"到"按规范"，从"运维个人掌握"到"团队共同拥有"，从"靠记忆维护"到"靠版本控制维护"。

在那家国企推行 Jenkinsfile 的三年里，最大的收获不是 CI 速度变快了，而是流水线变成了团队知识的沉淀。每一次流水线改进，都通过 PR 记录在代码历史里。新人加入时，读 Jenkinsfile 就能理解团队的整个构建部署流程。这种知识沉淀的价值，远超 CI 工具本身的技术价值。

无论你的组织是用 Jenkins、GitHub Actions 还是 GitLab CI，Pipeline as Code 的思想都适用。工具会变，但"流水线配置应该在版本控制里"这个原则，是不会过时的工程实践。

12. Jenkins 运维的工程实践

Jenkins 长期稳定运行需要一套运维规范，这是很多团队容易忽视的部分。

定期的插件审计与升级

Jenkins 的插件生态丰富，但也是最大的稳定性风险。建议每季度进行一次插件审计：检查哪些插件有安全更新，哪些插件已经不再使用（可以卸载），哪些插件的版本已经落后太多。在测试环境先升级验证，确认没有兼容性问题后再在生产环境升级。

Jenkinsfile 语法验证

提交 Jenkinsfile 之前，可以通过 Jenkins 的 Declarative Pipeline Linter 验证语法：

# 通过 Jenkins API 验证 Jenkinsfile 语法
curl -X POST   "http://jenkins.internal.company.com/pipeline-model-converter/validate"   -H "Jenkins-Crumb: YOUR_CRUMB"   -F "jenkinsfile=<Jenkinsfile"

或者安装 VS Code 的 Jenkins Pipeline Linter Connector 插件，在编辑器里实时检查语法错误。

备份与灾难恢复演练

Jenkins 主节点的配置（含所有 Job 定义、凭证、全局工具配置）要定期备份。更重要的是要定期演练恢复流程——备份了但从未验证过的备份，在真正需要的时候往往会让人失望。建议每半年做一次从零恢复演练，验证备份的完整性和恢复操作的可行性。

13. Jenkins 的团队协作规范

除了技术实践，Jenkins 的团队协作规范同样重要。

Jenkinsfile 命名规范：项目根目录的 Jenkinsfile 是主流水线，特殊用途的流水线用 Jenkinsfile.integration、Jenkinsfile.release 等有意义的名称区分。不要用 Jenkinsfile.bak、Jenkinsfile.old，用版本控制的 git history 保留历史版本。

Credentials 管理规范：所有密钥（数据库密码、API Token、SSH Key）必须通过 Jenkins Credentials Store 管理，绝对不能硬编码在 Jenkinsfile 里。Credentials 要按项目和环境分组，明确命名（如 prod-db-password、staging-harbor-token），定期轮换并更新。

失败通知接收人规范：CI 失败通知要发给触发构建的提交者，而不是群发给整个团队。精准的通知让相关人员第一时间处理，避免大家在群里互相等待"这是谁的问题"。

变更审批流程：对生产环境的部署步骤，建议加 input 步骤要求人工确认，并通过 Jenkins Audit Trail 插件记录所有操作，满足合规要求。

Jenkins 的 Pipeline as Code 把流水线从运维配置变成了工程资产，这个转变的意义超越了工具本身——它代表了"基础设施即代码"理念在 CI/CD 领域的落地，是工程成熟度的重要标志。把 Jenkinsfile 提交进代码仓库，是每个使用 Jenkins 的团队应该做的第一步，也是最重要的一步。

Jenkins 在企业环境里的长期价值，来自于它的可私有化部署能力和极强的定制性。把这两个能力发挥好，Jenkins 是企业级 CI/CD 的可靠基石。而 Pipeline as Code，是这一切的工程基础——代码才能被版本控制，被 Code Review，被测试，被重用。

写在最后

Jenkins 的核心价值在于私有化部署和极强的可定制性——在无法使用 SaaS CI 的企业环境里，它几乎是唯一选择。Pipeline as Code 的本质是把"如何构建和测试"这个知识从运维脑袋里转移到版本控制里，这是工程化成熟度的体现。

把 Jenkinsfile 提交进代码仓库，这一步看起来简单，但它代表了一种思想的转变：基础设施即代码，流水线即代码。

下一篇我们看 GitLab CI——.gitlab-ci.yml 的构建、缓存、Docker 服务配置，适合用 GitLab 私有化部署的团队。