DevOps 加速利器——用 Cloud Build + Cloud Deploy 打造全托管 CI/CD 流水线

发布时间：2026-05-21 15:31:22

DevOps 加速利器——用 Cloud Build + Cloud Deploy 打造全托管 CI/CD 流水线

（解决开发团队“手工发布易出错、Jenkins 维护痛苦、无法快速迭代”的痛点）

上个月去一家做 SaaS 的客户那里做技术回访，他们的 CTO 给我看了一张图：过去一年的线上故障中，有 42% 是由于“发布流程手工操作出问题”导致的。比如有人忘了在部署前跑数据库迁移脚本，比如测试环境和生产环境的配置文件没对齐，比如凌晨两点手工上线后没人盯监控。

他们不是没有 CI/CD 工具，而是用着一套自己搭建的 Jenkins，跑在几台 E2 虚拟机上。“维护 Jenkins 插件和主节点比维护业务代码还累，”那位 CTO 感叹，“而且一到团队扩编，权限管理就乱成一团。”

我问他：“为什么不考虑把它托管出去？” 他愣了一下。很多人确实没意识到，谷歌云为 DevOps 准备了一整套全托管、按用量付费的 CI/CD 工具链。

一、Cloud Build：没有 Master 节点的 CI 引擎

Jenkins 架构里，最让人头疼的就是那个 Master 节点——你得给它选机器、加磁盘、做备份、升版本，还得时刻担心构建队列堆积。而 Cloud Build 是完全 Serverless 的：你提交代码，谷歌云的算力池就会自动拉起构建容器去执行，构建完毕销毁，完全按构建分钟数计费，前 120 分钟/天免费。

Cloud Build 的配置文件就是放置在代码仓库根目录的一个 cloudbuild.yaml，写法极其直观。你想做什么？定义步骤（steps）：安装依赖、跑单元测试、构建 Docker 镜像、推送到 Artifact Registry、触发部署。这些步骤可以串行，也可以并行。而且因为 Cloud Build 可以直接访问你的 VPC 私有资源（比如 Cloud SQL），它甚至能做集成测试——这在传统 SaaS CI 里往往需要复杂的网络打通。

二、Artifact Registry：不只是“存镜像的地方”

很多人对 Artifact Registry 的理解就是“谷歌版的 Docker Hub”，但其实它远不止于此。它可以同时管理容器镜像、Maven 包、npm 包、Python 包，甚至 Helm Chart。这意味着你的团队不再需要同时维护好几个制品仓库。结合 Cloud Build 的自动构建触发器，代码推上去，几分钟后一个新版本的镜像就静静地躺在 Artifact Registry 里，等着被部署。

最让我觉得实用的一点是：Artifact Registry 可以配置“清理策略”，自动删除旧的镜像版本。过去多少团队因为“留着又没坏处”这句话，把镜像仓库堆了几 TB，每月白白交存储费。设一条“保留最近 5 个版本，其余自动清理”的策略，既省钱又清爽。

三、Cloud Deploy：让发布变回它本该有的“确定感”

从制品的诞生（Cloud Build + Artifact Registry）到上线的“最后一公里”，是用 Cloud Deploy 来连接的。

Cloud Deploy 的核心概念叫 “交付流水线”（Delivery Pipeline） ，它的设计逻辑不是“一个按钮部署到生产”，而是 “强制经过一道道门”。比如你可以定义 3 个目标（Target）：测试环境（自动部署）、预发布环境（需要审批）、生产环境（需要二次审批并带自动回滚）。每次部署都会生成一个“发布记录”，记录下了哪个版本、在什么时间、由谁批准、部署到了哪个环境。

关键特性	传统自建 Jenkins 方案	谷歌云原生 CI/CD（Build + Deploy + Artifact）
维护成本	需要维护 Master 和 Agent 节点	完全 Serverless，零维护
弹性	高峰排队，需预留机器	自动扩缩，谷歌海量算力池
制品管理	额外搭建 Harbor/Nexus	Artifact Registry 原生集成
发布管控	自定义脚本，缺乏原厂视图	Cloud Deploy 天然支持审批、回滚、多目标
安全集成	需要手动集成凭证管理	原生集成 IAM、密钥管理、二进制授权
审计与合规	靠插件和日志拼凑	Cloud Audit Logs 自动记录所有操作

四、一条真实流水线的诞生：从 push 到上线，三十分钟全自动

让我用一条典型的流水线来串联这些工具。

触发：开发者把代码 push 到 Cloud Source Repositories 或 GitHub 仓库的 main 分支。

构建：Cloud Build 被自动触发，读取根目录的 cloudbuild.yaml。第一步安装依赖，第二步运行测试，第三步用 docker build 构建镜像，第四步把镜像推送到 Artifact Registry。

自动部署测试环境：Artifact Registry 的新镜像版本被 Cloud Deploy 检测到，自动触发测试环境的部署到 GKE Autopilot。

质量卡点：Cloud Deploy 的预发布阶段“暂停”，等待指定的审批人（如 Tech Lead）在 Cloud Console 中点击“批准”。同时，这期间自动运行的集成测试结果可以作为批准依据。

生产部署：审批通过后，Cloud Deploy 将新版本推送到生产环境 GKE 集群，并以金丝雀发布或蓝绿部署的方式切换流量。如果 Cloud Monitoring 检测到错误率突增，可以通过 Cloud Deploy 一键回滚到上一个稳定版本。

从头到尾，没有一个步骤需要开发人员登录服务器、手敲命令、或者半夜等着发版。整个流水线的操作记录，全部自动进入 Cloud Audit Logs，任何合规审查都可以溯源。

五、为什么“托管 CI/CD”也是省钱的一部分

那位 CTO 最后算了一笔账：他那几台跑 Jenkins 的虚拟机，不管有没有构建任务，月底都要付包月费；而 Cloud Build 只在构建时计费，前 120 分钟/天还免费。加上不再需要专人维护 Jenkins 插件、解决构建节点漂移的问题，每年光是 DevOps 工具链的成本就省下了近六成。

但比省钱更珍贵的，是发布从“紧张事件”变成了“平常操作”。当发布足够频繁且安全，每一次改动都很小，定位问题也变得极其容易。好的 CI/CD 流水线，是让你的团队从害怕发布，变成相信自己可以在任何时间、安全地发布任何一个版本。

这件事上云之后，才真正开始。

如果需要更深入咨询了解可以联系全球代理上TG:@jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。