CI/CD

什么是CI/CD?

CI/CD是持续集成和持续交付/持续部署的组合实践,目标是让代码变更经过构建、测试、制品管理和部署流程后,更稳定、更可追溯地交付到目标环境。这个标签聚合流水线、自动化部署、制品仓库、发布规范和交付治理内容。

显示更多

这个页面适合围绕 CI/CD 流程、工具选型和发布治理查找文章;如果希望按阶段系统学习 DevOps、CI/CD、GitOps 和平台工程,可以进入 DevOps 学习路径页。

按学习路径系统学习DevOps内容

  • 流程建设重点关注代码提交、构建、测试、制品、部署和回滚链路
  • 工具选型重点比较 Jenkins、GitLab CI、GitHub Actions、制品仓库和发布平台
  • 治理升级重点关注标准流水线、审批、灰度、审计和多团队复用
建设建议

CI/CD建设可以先从稳定构建和制品管理开始,再逐步推进自动部署、审批、灰度和回滚。企业场景不要只追求自动化速度,更要关注流水线模板复用、权限审计、质量门禁、制品可追溯和失败后的恢复能力。

学习路径

了解更多关于CI/CD的信息

CI/CD应该先建设CI还是CD?

通常先把 CI 做稳,再逐步推进 CD。 如果代码检查、构建、测试和制品管理都不稳定,直接自动部署只会把不确定性更快带到测试或生产环境。

比较稳妥的顺序是:先统一代码扫描、依赖安装、构建缓存和测试门禁,再把镜像、二进制包或 Helm Chart 等制品纳入制品库管理;当制品可追溯、构建可重复之后,再推进自动部署、审批、灰度和回滚。这样 CD 才不是简单的脚本触发,而是建立在可靠 CI 基础上的交付能力。

CI/CD和DevOps是什么关系?

CI/CD 是 DevOps 落地中非常关键的工程链路,但 DevOps 不等于 CI/CD。CI/CD 更关注代码变更如何经过构建、测试、制品和部署流程进入目标环境;DevOps 还包括组织协作、平台能力、发布治理、度量反馈和持续改进。

如果只有流水线,没有质量门禁、权限控制、制品追溯、失败恢复和团队协作机制,交付效率未必真正提升。 因此 CI/CD 可以看作 DevOps 的技术抓手之一,而 DevOps 的目标是让研发、测试、运维、安全和平台团队围绕同一套交付链路协作。

企业选择CI平台时看哪些能力?

企业选 CI 平台不能只看能不能跑脚本,还要看它能否支撑团队规模、权限边界和交付治理。Jenkins、GitLab CI、GitHub Actions 等工具没有绝对优劣,关键是匹配组织现状和平台策略。

  1. 是否能对接现有代码仓库、合并请求、分支策略和权限体系。
  2. Runner 是否支持隔离、弹性扩缩容、缓存和 Kubernetes 动态构建环境。
  3. 流水线模板是否便于复用,能否沉淀标准构建、测试和安全检查。
  4. 密钥、制品、日志、审计和失败重试机制是否完整。
  5. 能否与镜像仓库、发布平台、GitOps 或 Kubernetes 集成。

CI/CD流水线标准化会不会降低团队灵活性?

好的标准化不会消灭灵活性,而是把高风险、重复性的部分统一起来。 例如代码扫描、制品命名、镜像推送、部署审计和质量门禁适合标准化;构建命令、测试矩阵、业务参数和发布节奏可以保留差异。

平台侧可以提供模板、默认阶段和安全基线,业务团队通过参数和扩展步骤适配自身应用。这样既能降低重复维护成本,又不会把所有应用强行塞进同一条固定流水线。真正需要避免的是“表面统一”,即模板看似一致,但每个团队都在私下绕过规则。

CI/CD流水线是否应该完全自动上线?

不一定。是否完全自动上线取决于业务风险、合规要求、测试质量、监控能力和回滚能力。对低风险服务,可以逐步推进自动发布;对核心系统,生产发布可能仍需要审批、灰度、发布窗口和人工确认。

判断是否适合自动上线,可以看几个条件:测试是否覆盖关键路径,发布后是否有健康检查和告警,失败后是否能快速回滚,变更记录是否可审计,团队是否清楚故障响应责任。自动化上线不是目标本身,稳定、可控、可恢复的交付才是目标。

CI/CD指标应该看哪些?

CI/CD 指标应该帮助团队发现交付瓶颈,而不是单纯考核部署次数。常见指标包括部署频率、变更前置时间、变更失败率、平均恢复时间、流水线成功率和流水线耗时。

这些指标需要结合业务上下文解读。部署频率提升但失败率也提升,说明交付质量可能在下降;流水线耗时变长,可能是测试、依赖、缓存或构建环境出现瓶颈;平均恢复时间过长,则说明回滚、监控和应急流程需要改进。