CI/CD流水线指南

如果你的团队上线时还是"指着一台服务器、敲几条命令、然后祈祷"，那你的交付流程就是个隐患。一年发两版、配一段巨长的测试期，和一天放心地发好几次之间，差距不是天赋，而是流水线。持续集成与持续交付（CI/CD），是把混乱的手工上线，变成可重复、可自动化的那台机器；你只要见过一条好流水线跑起来，就再也不想回到从前。

"CI/CD"这个词被说得太多，意思已经模糊了。让我们说清楚。持续集成指的是频繁地合并代码改动，并自动构建、测试每一次合并，让集成 bug 尽早暴露。持续交付指的是每个通过测试的改动都已经准备好部署到生产，最终部署可能是人工的。持续部署连最后一步也自动化了。大多数团队停在持续交付，把最后那个按钮留给人按。这篇指南带你从第一次合并一路建到生产，搭出一条真正能用的流水线。

先从版本控制纪律开始，而不是工具

一条流水线有多好，取决于喂养它的版本控制工作流有多好。在挑 CI 服务之前，先理顺你的分支模型。最常见的入门配置是 trunk-based 流程加短期特性分支。开发者拉分支、提交小改动、推送、开 PR、合并进主分支。小而频繁的合并是 CI 的心脏，因为它让集成问题保持微小、可发现。

再给 PR 模板加上提醒——把"一个完整的改动长什么样、合并前必须过什么"写清楚。用受保护分支强制没人能直接推主分支。要求状态检查必须通过，至少一次评审。这些规则设起来很便宜，却为自动化奠定了一个有纪律的地基。如果你的团队还在学 Git 本身，一份 Git 教程 能快速补上这段差距。

把流水线设计成一道道闸门

把你的流水线想成一条带校验闸门的装配线。每个阶段接过上一阶段的工件、做一项检查，只有检查通过才放行。一个典型的入门流水线长这样：安装依赖 → 跑单元测试 → 跑 lint 和格式检查 → 构建工件 → 跑集成或端到端测试 → 部署到预发环境 → 最终提升到生产。

让每个阶段聚焦且快。一个常见错误是把所有测试塞进一个要跑四十分钟的巨型步骤里，最后失败了还不知道为什么。拆分职责才能让失败可行动化：单元测试告诉你逻辑坏了，lint 告诉你风格跑了，集成测试告诉你服务之间不对付。快速反馈很重要——从 push 到结果的周期越短，开发者越可能在第一时间处理。

让流水线快速失败，但失败得清清楚楚。按成本最低、最可能失败的检查先跑的次序排阶段。这样语法错误几秒就被逮住，而不是跑完整个套件。你的失败信息要可行动："构建失败"没用，"lint 发现 12 行有一个未用 import"才行。清晰是特性，不是加分项。

线上传的是工件，而不是源码

你能给流水线做的最大升级，是只构建一次可部署的工件，然后把同一个工件推进每个环境。否则预发和生产会漂移，因为每个环境都从略有差异的状态重新构建，"在我机器上能跑"就变成"在预发能跑"，然后是"为什么生产又不一样了？"

测试通过后，把应用 编译/打包成一个带版本号的工件——镜像、jar、bundle，看你技术栈——并打上唯一标识。然后把那个精确的工件部署到预发，跑你的集成测试，再把同一个工件提升到生产。如果它在预发过了，你有高信心它会在生产过，因为字节完全相同。这个工件提升模式，消除了整类环境漂移。

环境配置应该在部署时注入，而不是烘焙进工件。把密钥和环境相关值放在工件之外、部署时再传进去，这样同一个构建在开发、预发、生产表现一致。这正是流水线可靠性和安全问题交汇的地方，因为把密钥塞进工件，就是一场在等着的泄密事故。

自动化测试：覆盖对的那几层，而不是能覆盖的一切

自动化测试是让流水线可信的东西，但目标不是测试数量最大化，而是一套稳到"一条绿的流水线就给你真信心"的套件。实务上这意味着：一层快而可靠的单元测试逮住大部分回归，一小组聚焦的集成测试验证关键跨服务路径，再有一层很薄的端到端测试覆盖最重要的用户路径。

端到端测试最慢也最脆弱，所以保持小而要有价值。两条随机失败的 e2e 测试比没有更糟，因为团队会学会无视红构建。先把测试套件稳定下来，再扩覆盖。流水线本身的可信度至高无上；如果开发者不信任一个绿的构建，整套 CI/CD 投资就崩了。

想更完整地看流水线、部署和基础设施怎么共处，DevOps 流水线 系列把 CI/CD 连进更广的部署工具链，而 DevOps 基础 则讲底层的运维心智。CI/CD 是一门更大学科的自动化那一层。

救命的部署策略与回滚

怎么部署和你是否自动化它同样重要。最安全的自动化，是去掉"拨一个巨大开关"那种进退两难的抉择。蓝绿部署维护两个相同的环境，生产流量路由到一个，新环境过了健康检查就切过去；回滚就是一次路由翻转。金丝雀部署把一小部分用户引到新版本，监控错误后逐渐放量；失败只波及一小撮人。

无论选哪个策略，你都需要一条快速、测过的回滚路径。团队不敢频繁部署的原因，通常是怕上生产崩了没退路。把上一个工件留着、把把流量拨回去的机制做成一条命令，回滚就自动化了。当回滚琐碎且测过，恐惧就蒸发，频繁部署会变成低压力惯例，而不是恐惧的仪式。

还要自动化判断部署是否成功的健康检查。一个脚本检查新环境是否有响应并报告健康，能自动提升或自动回滚——这正是"半夜一个人干盯仪表盘"和"系统自己处理"的区别。健康检查把部署从一件事件，变成一次受监控、可逆转的动作。

给你的团队选一个 CI/CD 平台

平台选择由你的源码在哪、以及你想跑多少基础设施决定。已经在 GitHub 上的团队用 Actions 起步最快；想完全掌控、又已经在跑 Jenkins 的企业通常留在那。GitOps 导向的 Kubernetes 团队倾向 Argo CD。你甚至可以先用免费的 GitHub Actions 或 GitLab CI 起步，之后再迁移。流水线定义本身——阶段、闸门、工件提升——是跨平台通用的，所以别因为工具能换，就不下功夫把工作流做对。

衡量并迭代你的流水线

当你开始衡量一条流水线，它就变成战略资产。追踪部署频率、从提交到上线的交付用时、变更失败率、以及平均恢复时间。这四个通常叫 DORA 的指标，会告诉你交付流程健不健康。高部署频率配合低变更失败率，说明流水线在起作用；反之就是你正在自动化混乱。

衡量周期时间，锁定最慢的那个阶段。如果集成测试要 20 分钟而其他一切都是 2 分钟，你的杠杆就在那。激进地砍掉脆弱测试并把它们归零。追踪开发者多常碰到流水线、构建是否保持绿，并把"主分支坏了最高优先级"设为目标。对 Kubernetes 原生部署，Kubernetes 安全基础 会在你的平台长大时补上需要的护栏。

最后，把流水线当活的软件。定期审查、删掉死阶段、改善开发者"上线"的体验。想做更深的构建自动化模式，SkillGoHub 上的 Jenkins 流水线指南 是一个扎实的技术深潜。最好的 CI/CD 配置，是你团队每天真在用、无条件信任、并持续改进的那套，因为交付速度已经变成一种你输不起的竞争优势。

常见问题

已经在 GitHub 或 GitLab 上，还需要单独的 CI/CD 工具吗？

不用。GitHub Actions 和 GitLab CI 都功能完整，且集成进多数团队已在用的平台。从内建选项开始，省去单独工具的成本和复杂度，还让流水线紧贴你的代码和 PR。只有当你有特定需求——比如自托管代理机组、或原生方案处理不好的老仓库格式——才需要单独的工具。

我应该先搭的最小可行流水线是什么？

先从三个阶段开始：跑单元测试、跑 lint/格式检查、构建可部署工件，全部在每次 push 和每次 PR 时触发。再加一条要求这些必须通过的分支保护规则。这足以逮住大部分回归和集成疏漏。等核心稳定地绿了之后，再加集成测试、预发部署和健康检查——因为铺得太快，会造出一条你信不过的流水线。

怎么把生产密钥隔离在流水线日志和工件之外？

把密钥存在你 CI/CD 平台的密钥管理器或 vault 里，按名字引用，而不是把值写进流水线文件。绝不把密钥提交进源码。在构建日志里做脱敏，并按计划轮换。可注入的密钥意味着工件保持干净，每个环境部署时接到自己的值——既更安全也更可移植。

持续部署是不是总比持续交付好？

不一定。持续部署让每个通过的改动自动上线，速度最大化，非常适合有强自动化测试和 feature flag 的服务。持续交付——代码总是可部署，但最后那个按钮由人点——适合那些你想对发布时点有刻意控制的产品，比如受监管行业或重大功能发布。按你的风险承受度和测试成熟度来选，而不是追时髦。

我们一个月发一版。CI/CD 还值得搭吗？

值得，但按匹配的规模投入。即便按月度节奏，一条自动构建测试每次合并的 CI 流水线，也能移除"为什么只在发布分支里坏"这类痛苦问题，而一份写清楚的发布 runbook 能消除脆弱的手工步骤。工件提升纪律——构建一次、部署同一个工件——哪怕发布很稀照样回本，因为它杀掉环境漂移。先从 CI 加一个简单的部署任务开始，节奏起来了再延伸。