一、先搞清楚:CI/CD到底在干什么?
很多团队把CI/CD理解成"自动部署"——这只说对了三分之一。
完整的CI/CD是一条从代码到生产的自动化管道,它包含四个阶段:
| 阶段 | 名称 | 干什么 | 耗时(理想状态) |
|---|---|---|---|
| 1 | 持续集成(CI) | 代码提交后自动编译、测试、打包镜像 | 5-10分钟 |
| 2 | 持续交付(CD) | 镜像推送到仓库,自动部署到测试环境 | 10-15分钟 |
| 3 | 持续部署(CD) | 自动部署到预发环境,人工审批后上生产 | 15-20分钟 |
| 4 | 持续回滚 | 任何阶段出问题,一键回退到上一版本 | 1-2分钟 |
核心价值:把"手动、重复、易错"的发布动作,变成"自动、可靠、可追溯"的流水线。
某电商团队的数据:上了CI/CD之后,发布频率从每月2次提升到每天5次,发布耗时从4小时降到15分钟,回滚时间从2小时降到30秒。
二、架构全景:一条流水线长什么样?
把所有组件串起来,你会看到一条清晰的流水线:
1开发者提交代码
2 ↓
3代码仓库触发Webhook
4 ↓
5CI工具拉取代码 → 编译 → 单元测试 → 构建Docker镜像
6 ↓
7镜像推送到云容器镜像服务(SWR)
8 ↓
9CD工具从SWR拉取镜像 → 部署到测试环境(CCE集群)
10 ↓
11自动化测试通过 → 人工审批(可选)
12 ↓
13部署到预发环境 → 验证
14 ↓
15部署到生产环境(CCE集群)
16 ↓
17监控确认 → 发布完成
18
每一步都是自动的,每一步都有检查点,每一步都可以回滚。
三、第一步:代码仓库 + Webhook——流水线的起点
一切从代码提交开始。
你把代码推到仓库的那一刻,Webhook就会触发CI工具开始工作。这是整条流水线的"发令枪"。
3.1 分支策略:不是所有代码都能上生产
| 分支 | 用途 | 触发的流水线 |
|---|---|---|
| main/master | 生产代码 | CI → 测试 → 预发 → 生产 |
| develop | 开发主干 | CI → 测试环境自动部署 |
| feature/* | 功能分支 | CI → 临时环境部署 |
| release/* | 发布分支 | CI → 预发环境部署 |
| hotfix/* | 紧急修复 | CI → 直接上生产(跳过预发) |
核心原则:只有merge到main分支的代码,才有资格上生产。其他分支,只在测试环境跑。
3.2 Webhook怎么配?
在代码仓库的设置页面,添加Webhook,指向CI工具的回调地址。选择触发事件为"Push"和"Merge Request"。
这样,每次代码推送或合并请求,流水线自动启动——你不需要手动点任何按钮。
四、第二步:CI工具——自动编译、测试、打包镜像
这是流水线最核心的环节。CI工具负责把你的源代码变成一个可以运行的Docker镜像。
4.1 CI工具选什么?
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Jenkins | 插件生态最丰富,自定义程度最高 | 复杂流程、已有Jenkins经验的团队 |
| GitLab CI | 与代码仓库深度集成,配置简单 | GitLab用户,追求简洁 |
| 云原生CI(CodeArts Pipeline) | 全托管,免运维,与云服务无缝集成 | 不想维护CI服务器的团队 |
| GitHub Actions | 事件驱动,市场有大量预制Action | GitHub用户 |
我的建议:如果你已经在用云上的代码仓库,直接用云原生CI,免运维、免搭建、开箱即用。如果你有Jenkins经验且流程复杂,Jenkins依然是最灵活的选择。
4.2 CI流水线的标准流程
| 步骤 | 做什么 | 为什么 |
|---|---|---|
| 拉取代码 | 从仓库拉取最新代码 | 确保构建基于最新代码 |
| 安装依赖 | 下载项目依赖包 | 编译前的准备工作 |
| 编译构建 | 编译源代码,生成可执行文件 | 把代码变成程序 |
| 单元测试 | 运行单元测试用例 | 确保代码逻辑正确 |
| 代码扫描 | 静态代码分析,检查漏洞和规范 | 质量门禁,不通过则阻止后续流程 |
| 构建镜像 | 用Dockerfile构建镜像 | 把程序打包成镜像 |
| 镜像扫描 | 扫描镜像中的CVE漏洞、恶意文件 | 安全门禁,不通过则阻止推送 |
| 推送镜像 | 推送到云容器镜像服务(SWR) | 镜像进入交付环节 |
注意:代码扫描和镜像扫描是两道独立的质量门禁。代码扫描在构建前,镜像扫描在推送前。任何一道不通过,流水线自动终止——垃圾代码和漏洞镜像根本进不了生产环境。
五、第三步:云容器镜像服务(SWR)——镜像的中转站
CI构建好的镜像,不是直接推到生产集群的——它先进入SWR。
为什么?因为SWR提供了三个CI工具自己做不到的能力:
| 能力 | 说明 | 价值 |
|---|---|---|
| 版本管理 | 每个镜像都有版本号,不可变 | 追溯到每次发布用的是哪个镜像 |
| 安全扫描 | 镜像上传时自动扫描漏洞 | CI的镜像扫描是构建时,SWR的扫描是上传后,双重保险 |
| 加速拉取 | CCE集群从SWR拉取镜像有加速 | 大规模节点并发拉取时,速度提升3-5倍 |
SWR就是你的镜像仓库+质量检查站+分发中心。三合一。
六、第四步:CD工具——把镜像部署到CCE集群
镜像在SWR里了,接下来要把它部署到Kubernetes集群(CCE)上。
这一步由CD工具完成。CD工具从SWR拉取指定版本的镜像,然后更新CCE集群中的Deployment配置。
6.1 部署策略:不是"一把梭",是"步步为营"
| 环境 | 部署方式 | 触发条件 |
|---|---|---|
| 测试环境 | 全自动,镜像推送后立即部署 | 每次CI完成后自动触发 |
| 预发环境 | 全自动,但需通过自动化测试 | CI完成 + 测试通过后自动触发 |
| 生产环境 | 半自动,需人工审批 | 预发验证通过后,等待审批 |
为什么生产环境要人工审批?因为自动化再可靠,也替代不了人的判断。产品经理说"这个功能周一上",你点一下"批准",流水线自动执行——这才是CI/CD的正确打开方式。
6.2 部署方式:三种策略,三种场景
| 策略 | 做法 | 适用场景 | 风险 |
|---|---|---|---|
| 滚动更新(Rolling Update) | 逐步替换旧Pod,新Pod就绪后再杀旧Pod | 大部分场景,默认选择 | 更新期间新旧版本共存 |
| 蓝绿部署(Blue-Green) | 新版本部署到另一套环境,验证通过后切流量 | 零停机要求高的场景 | 需要双倍资源 |
| 金丝雀发布(Canary) | 先让1%的流量走新版本,逐步放大 | 大流量业务,风险高的发布 | 需要流量切分能力 |
CCE原生支持这三种部署策略,在Deployment配置中一行参数就能切换——不需要改任何代码。
6.3 回滚:一键回到上一个版本
出了问题怎么办?
CD工具保留了每次发布的镜像版本和配置快照。点击"回滚",系统自动把Deployment的镜像版本改回上一次的版本——30秒内完成,用户无感知。
某金融团队的数据:上了CI/CD之后,回滚操作从平均2小时降到30秒,因发布故障导致的业务中断时间下降了95%。
七、第五步:CCE集群——应用的最终归宿
所有的镜像,最终都要跑在CCE集群上。
CCE作为全托管Kubernetes服务,跟CI/CD的配合有三个天然优势:
| 优势 | 说明 | 对CI/CD的价值 |
|---|---|---|
| 集群API开放 | 支持通过API动态更新Deployment | CD工具可以直接调用API发布,无需SSH |
| 弹性伸缩 | HPA + Cluster Autoscaler自动扩缩容 | 发布后流量暴增,集群自动扩容,不用人管 |
| 多集群管理 | 一个控制台管多个集群 | 测试/预发/生产集群统一管理,流水线一键切换目标 |
CCE不只是跑应用的地方,它是CI/CD流水线的"最后一公里"。
八、实战:一条完整流水线的配置清单
| 组件 | 配置项 | 建议值 |
|---|---|---|
| 代码仓库 | 分支策略 | main/develop/feature,保护main分支 |
| Webhook | 触发事件 | Push + Merge Request |
| CI工具 | 触发条件 | 代码推送到develop或合并到main |
| CI流程 | 步骤 | 拉代码 → 编译 → 单元测试 → 代码扫描 → 构建镜像 → 镜像扫描 → 推送SWR |
| SWR | 镜像仓库 | 按环境分仓库:test/pre/prod |
| CD工具 | 测试环境 | CI完成后自动部署 |
| CD工具 | 预发环境 | CI完成 + 测试通过后自动部署 |
| CD工具 | 生产环境 | 预发通过后,人工审批,自动部署 |
| CCE集群 | 部署策略 | 测试/预发用滚动更新,生产用金丝雀 |
| CCE集群 | 回滚策略 | 保留最近5个版本,一键回滚 |
| 监控 | 发布后检查 | 自动检查Pod状态和错误率,异常自动回滚 |
九、避坑指南:CI/CD最容易踩的五个坑
| 坑 | 后果 | 正确做法 |
|---|---|---|
| 所有分支都能上生产 | 垃圾代码直接进生产 | 保护main分支,只有审批后才能合并 |
| 没有镜像扫描 | 漏洞镜像进生产 | CI扫描 + SWR扫描,双重门禁 |
| 发布后不验证 | 上线了才发现挂了 | 发布后自动跑健康检查,失败自动回滚 |
| 手动修改生产配置 | 配置不一致,排查无据 | 所有配置变更走流水线,禁止手动操作 |
| 回滚太复杂 | 出了问题不敢回滚 | 保留版本快照,一键回滚,30秒完成 |
十、写在最后:CI/CD不是工具,是交付文化
很多团队把CI/CD当成一个"工具"来推——装了Jenkins,配了流水线,然后呢?没人用,因为流程太复杂;或者乱用,因为没有规范。
CI/CD的本质不是自动化,是纪律。
它强制你:代码必须过测试才能合并,镜像必须过扫描才能推送,发布必须过验证才能上生产,出了问题必须能回滚。
这些规矩,不是工具给你的,是你自己定的。但工具让这些规矩自动执行、不可绕过。
从代码提交到生产上线,15分钟。从生产故障到回滚完成,30秒。这不是梦想,这是CI/CD + 云容器服务能给你的日常。
你的代码值得更快地到达用户手中。别让手动发布,成为你和用户之间最慢的那一环。
现在就去配你的第一条流水线。配置只需要一个下午,但它能帮你省下未来每一个周五的加班。