CI/CD:从 Jenkinsfile 到蓝绿部署,Go 项目的自动化交付¶

这一章讲现代软件交付的默认形态:代码一合入,机器自动构建、测试、部署。 主线例子是一份 Jenkinsfile——它长得像配置文件,但读完你会把它读成一条有时间顺序的流水线。后半场的两个问题更值钱: 怎么测试才能让流水线有意义(覆盖率、mock、并行), 以及怎么上线才能不砸锅(五种部署策略,重点走蓝绿)。

1. 三个词先分清:CI、CD、持续部署¶

这三个缩写天天被混用,书里把它们掰开了¹:

缩写	全称	意思
CI	Continuous Integration 持续集成	频繁把代码合进共享仓库,每次合入自动跑测试,尽早抓集成问题
CD	Continuous Delivery 持续交付	代码过了所有自动化测试后,自动部署到预发/生产环境(部署动作自动,但「上不上线」由人拍板)
CDep	Continuous Deployment 持续部署	测试一过,自动上线生产,无人介入——CI/CD 流水线里多一个 D,少一道人闸

工具方面,书里点了 Jenkins、Spinnaker、GoCD、Concourse、GitLab 一票²—— 本章选 Jenkins 当主角,只因它最老牌、插件最多;机制懂了,换 GitHub Actions 只是换语法(补充,不在书里)。

2. Go 项目的标准目录结构¶

流水线要跑的对象先摆好。书里给的「典型 Go 项目结构」,记住这几个目录的分工³:

路径	装什么
`cmd/`	每个子目录 = 一个可执行程序的入口
`pkg/`	可复用的库(设计给别人 import 的)
`api/`	HTTP API 的 handler、中间件
`autodeployment/`	Dockerfile、Kubernetes 清单等部署物
`config/` `scripts/` `tests/` `docs/`	配置、脚本、测试、文档,各司其名
`go.mod` / `go.sum`	模块依赖清单 + 校验和(第 6 章的模块,这里落到工程位)

这个结构的价值书里点了一句:关注点分离,让 CI/CD 能对「测试」「部署」分别精准打击。

3. 主线例子:一份 Jenkinsfile 的全程¶

Jenkins 环境的搭建书里给了七步(装 Jenkins → 开 localhost:8080 → 装 Go/Git 插件 → 配全局 Go 工具 → 配凭据 → 建 Job → Build Now)⁴——步骤随版本变, 记住「Job = 一条流水线任务」即可。真正承重的,是项目根目录(项目文件夹的最顶层)下的 Jenkinsfile。

主线例子照原书,五个阶段走一遍⁵:

阶段一:Checkout(拉代码)。

stage('Checkout') {
    steps {
        git 'your_repository_url'      // 从版本控制取源码
    }
}

阶段二:Unit Tests(跑测试)。

stage('Unit Tests') {
    steps {
        sh 'go test ./...'    // ./... = 当前模块下所有包
    }
}

./... 这个记号值得记:一次跑全项目的测试,是 go test 的常用形态。

阶段三:Code coverage(出覆盖率报告)。

stage('Code coverage') {
    steps {
        sh 'go tool cover -html=coverage.out -o coverage.html'
        publishHTML(target: [reportFiles: 'coverage.html'])
    }
}

go tool cover 把 go test -coverprofile=coverage.out 生成的数据画成人类能看的 HTML——哪些行测到了、哪些行裸奔,一张网页全亮出来。

阶段四:Deploy(部署)。 书里给的是 scp 把二进制拷到 staging 服务器的示意——生产环境会换成 Ansible/Docker/云 API,但「流水线里有一站叫部署」的形状不变。

阶段五:post { always { ... } }(无论成败,收尾)。

post {
    always {
        emailext(subject: "Jenkins Build Notification: ${currentBuild.result}", ...)
        cleanWs()      // 清工作区
    }
}

always 是 Jenkinsfile 的灵魂之一:成功发一封邮件,失败也发一封邮件, 工作区永远清干净。——注意这就是第 16 章 defer 的同构思想: 「无论如何都要执行的收尾」在流水线和在函数里是一个形状。

4. 测试工程:让流水线抓得到 bug¶

流水线只能跑你写过的测试。书里给的测试工程五件套⁶:

写测试: 文件以 _test.go 结尾,函数名 TestXxx,用 t.Errorf 报失败:

func TestAdd(t *testing.T) {
    result := Add(1, 2)
    if result != 3 {
        t.Errorf("Add(1, 2) = %d; want 3", result)
    }
}

TestMain 套件: 一个包里定义 TestMain(m *testing.M), m.Run() 前后就是你的「搭环境/拆环境」钩子。

并行测试: Go 的测试默认跨核并行;-p 控制并行度。

覆盖率与静态检查:

go test -cover ./...        // 覆盖率数字
go vet ./...                // 可疑写法检查
gofmt -l .                  // 格式没对齐的文件列表

Mock 依赖(本章和第 12 章接口知识的会师点): 把依赖声明成接口,测试时塞一个假的实现⁷:

type DataFetcher interface {          // 依赖 = 接口
    FetchData() (string, error)
}
type MyService struct {
    DataFetcher DataFetcher           // 字段是接口类型
}
// 测试时:
type MockDataFetcher struct{}          // 手写假实现
func (m *MockDataFetcher) FetchData() (string, error) {
    return "Mocked Data", nil
}
// 测试里把假的塞进真身:
myService := MyService{DataFetcher: &MockDataFetcher{}}

图说:接口是 Go 依赖注入的原生机制——不用框架,语言本身就够了。 (mockgen 之类的代码生成器能省掉手写的部分,但原理就是这个。)

5. 五种部署策略:怎么上线不砸锅¶

策略一「直接 CD」不算策略,真正的五种⁸:

策略	一句话	风险控制
蓝绿部署	两套一模一样的环境,蓝的在服务,绿的空闲	新版部署到绿的,测完把流量整个切过去;翻车切回蓝的
金丝雀发布	先放一小撮用户/服务器尝新	观察没事再全量;「煤矿里的金丝雀」名字的由来
滚动部署	一台一台地换旧实例	过程中新旧共存,负载均衡分流
A/B 测试	两个版本同时跑,比 KPI	用数据选赢家,不只是控风险
特性开关	代码上线了,功能没开	开关在配置里,不发版就能切

蓝绿部署全流程值得按原书走一遍,因为它是理解其余策略的基准⁹:

  ① 开发合入代码,CI 跑测试
  ② 合并/打 tag 触发流水线,准备新版本
  ③ 新版本部署到「绿」环境(空闲的那套)
  ④ 在绿环境上跑自动化验证
  ⑤ 流量从「蓝」切到「绿」——可一次性切,也可渐进切
  ⑥ 绿的出问题?流量立刻切回蓝,用户几乎无感
  ⑦ 确认稳定后,把蓝环境也更新成新版本,为下一轮待命

图说:蓝绿买的保险是「随时能退回」,代价是双倍的基础设施。 金丝雀和滚动是用更小的流量窗口换更低的成本;特性开关是把「部署」和「发布」彻底解耦——代码先上,功能后开。

6. 监控与日志:流水线之外的眼睛¶

部署完不等于完事——系统跑着的时候,你得看得见它。

监控五个层次,书里给的地图¹⁰:基础设施(Zabbix/Nagios)→ 应用指标(Prometheus/Grafana/Datadog,盯响应时间、错误率、CPU 内存)→ 自定义看板 → 告警分级(邮件/Slack/短信,分信息/警告/严重)→ 事故管理(PagerDuty/OpsGenie,告警自动开工单)。安全监控另起一摊:DAST(对运行中的应用做攻击面扫描)、依赖漏洞扫描(OWASP dependency-check、snyk)、容器镜像扫描(Clair、Anchore)、密钥管理(Vault/AWS Secrets Manager)。

日志三件套¹¹:

结构化日志:日志输出成 JSON 等机器可读的键值对,带时间戳(这条记录是几点几分写的)和级别, 才能被搜索过滤(工具:ELK、Splunk、Graylog);
集中化日志:把各个服务的日志汇到一个仓库里统一查;
留存与归档:按合规要求定保留期,老日志压缩进廉价存储。

判断(我们的,不是书里的): 本章的工具密度很高,但有一条主线可以串起来: **「测试抓得住的 bug 留在流水线内,抓不住的才需要部署策略和监控兜底」—— 五种部署策略和三级监控,本质都是「承认总会有漏网之鱼」后的保险设计。预算有限时,保险钱的顺序是:先有回滚(蓝绿/金丝雀),再有可观测(日志+指标), 最后才是花样(A/B、特性开关)。 如果错,会错在: 特性开关派会认为它才是根本解药—— 但特性开关治的是「发布节奏」,治不了「已经写进去的 bug」; 没有快速回滚,它只会把事故从「功能坏」变成「两个功能都坏」。

7. 边界与局限¶

Jenkins 的七步安装是截图级教程,会随版本过期;概念(插件、全局工具、凭据、Job)不过期;
没有讲 GitHub Actions——对今天的多数新项目,它才是默认选项 (补充,不在书里,来自通用知识);本章的流水线阶段划分对它完全适用;
覆盖率一节没给「覆盖率该多高」的答案——业界对「追求 100%」有长期争论, 务实的线是「关键路径必有测试,覆盖率只作趋势指标」;
监控一节纯名录,没有 Go 代码接入 Prometheus 的示例(补充:需在代码里暴露 /metrics 端点)。

8. 可带走的¶

CI = 合入即测;CD(交付)= 过了测试自动部署、人拍板上线; CDep(部署)= 过了测试自动上线,无人介入;
Go 项目目录:cmd/(入口)、pkg/(可复用库)、api/(HTTP)、 autodeployment/(部署物)、go.mod/go.sum(依赖);
Jenkinsfile 五个阶段:Checkout → Unit Tests(go test ./...)→ 覆盖率(cover -html)→ Deploy → post{always} 收尾;
always 块 = 流水线的 defer:成败都执行收尾;
测试文件 _test.go、函数 TestXxx、t.Errorf 报错;
**TestMain(m *testing.M) 是套件的搭/拆环境钩子**;
go test -cover、go vet、gofmt 是 CI 里的三件套;
Mock 的秘密 = 依赖声明成接口 + 测试塞假实现——Go 接口的原生胜利;
五种部署策略:蓝绿(双环境整切)、金丝雀(小流量尝鲜)、滚动(逐台换)、 A/B(数据选版本)、特性开关(部署与发布解耦);
保险钱的顺序:回滚 > 可观测 > 花样。

9. 原文地图¶

主题	原书章	原文位置
CI/CD/CDep 三词定义	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:55`(搜「frequently integrating」) · `text/30-fm-learning-go-programming.txt:58`(搜「staging or production」) · `text/30-fm-learning-go-programming.txt:61`(搜「without human intervention」)
工具名单	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:64`(搜「Jenkins, Spinnaker, GoCD」)
项目目录结构	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:80`(搜「main entry points」) · `text/30-fm-learning-go-programming.txt:95`(搜「reusable libraries」) · `text/30-fm-learning-go-programming.txt:113`(搜「Go 1.11 introduced go.mod」)
Jenkins 环境七步	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:125`(搜「select appropriate CI/CD tool」)
流水线的九个阶段	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:161`(搜「Checkout」) · `text/30-fm-learning-go-programming.txt:170`(搜「go test」) · `text/30-fm-learning-go-programming.txt:236`(搜「coverage.html」)
Jenkinsfile 完整示例	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:191`(搜「pipeline {」) · `text/30-fm-learning-go-programming.txt:281`(搜「always」)
测试五件套	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:317`(搜「_test.go」) · `text/30-fm-learning-go-programming.txt:401`(搜「TestMain」) · `text/30-fm-learning-go-programming.txt:431`(搜「-cover flag」)
mock 接口示例	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:449`(搜「DataFetcher interface」) · `text/30-fm-learning-go-programming.txt:511`(搜「Mocked Data」)
蓝绿部署全流程	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:582`(搜「green」) · `text/30-fm-learning-go-programming.txt:597`(搜「redirects user traffic」) · `text/30-fm-learning-go-programming.txt:600`(搜「redirected back」)
其余四种策略	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:606`(搜「canary group」) · `text/30-fm-learning-go-programming.txt:609`(搜「Rolling deployment」) · `text/30-fm-learning-go-programming.txt:612`(搜「A/B testing」) · `text/30-fm-learning-go-programming.txt:615`(搜「Feature flags」)
监控五层与日志三件套	Build CI/CD pipeline with Golang	`text/30-fm-learning-go-programming.txt:630`(搜「Prometheus, Grafana, or Datadog」) · `text/30-fm-learning-go-programming.txt:657`(搜「HashiCorp Vault」) · `text/30-fm-learning-go-programming.txt:666`(搜「key-value pairs」)

出处:「Build CI/CD pipeline with Golang」第 55–61 段(text/30-fm-learning-go-programming.txt:55,搜「frequently integrating」;:61,搜「without human intervention」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 64 段(text/30-fm-learning-go-programming.txt:64,搜「Jenkins, Spinnaker, GoCD」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 67–119 段(各目录定义)。 ↩
出处:「Build CI/CD pipeline with Golang」第 122–152 段(text/30-fm-learning-go-programming.txt:125,搜「select appropriate CI/CD tool」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 155–308 段(text/30-fm-learning-go-programming.txt:191,搜「pipeline {」;:221,搜「go test ./...」;:236,搜「coverage.html」;:281,搜「always」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 311–567 段(text/30-fm-learning-go-programming.txt:317,搜「_test.go」;:401,搜「TestMain」;:425,搜「multiple CPU cores」;:431,搜「-cover flag」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 434–558 段(text/30-fm-learning-go-programming.txt:449,搜「DataFetcher interface」;:511,搜「Mocked Data」;:544,搜「DataFetcher: mockDataFetcher」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 570–615 段(五种策略的定义)。 ↩
出处:「Build CI/CD pipeline with Golang」第 582–603 段(text/30-fm-learning-go-programming.txt:597,搜「redirects user traffic」;:600,搜「redirected back」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 618–657 段(text/30-fm-learning-go-programming.txt:630,搜「Prometheus, Grafana, or Datadog」;:657,搜「HashiCorp Vault」)。 ↩
出处:「Build CI/CD pipeline with Golang」第 660–675 段(text/30-fm-learning-go-programming.txt:666,搜「key-value pairs」;:669,搜「single repository」)。 ↩