CI/CD
CI/CD是持续集成和持续交付/持续部署的组合实践,目标是让代码变更经过构建、测试、制品管理和部署流程后,更稳定、更可追溯地交付到目标环境。这个标签聚合流水线、自动化部署、制品仓库、发布规范和交付治理内容。
显示更多
这个页面适合围绕 CI/CD 流程、工具选型和发布治理查找文章;如果希望按阶段系统学习 DevOps、CI/CD、GitOps 和平台工程,可以进入 DevOps 学习路径页。
- 流程建设重点关注代码提交、构建、测试、制品、部署和回滚链路
- 工具选型重点比较 Jenkins、GitLab CI、GitHub Actions、制品仓库和发布平台
- 治理升级重点关注标准流水线、审批、灰度、审计和多团队复用
CI/CD建设可以先从稳定构建和制品管理开始,再逐步推进自动部署、审批、灰度和回滚。企业场景不要只追求自动化速度,更要关注流水线模板复用、权限审计、质量门禁、制品可追溯和失败后的恢复能力。
学习路径
推荐阅读
-
GitOps回滚策略-发布窗口设计清单
GitOps 让发布状态回到 Git,但事故现场常常先要判断回滚哪一层。围绕 GitOps回滚策略,本篇从发布窗口、同步策略、镜像版本和责任边界入手,梳理可执行回滚方案。
-
开发运维一体化实践:流水线到反馈闭环
工具齐全并不等于开发运维一体化落地成功。环境割裂、发布反馈慢和责任边界模糊时,可以从流水线证据、GitOps发布、观测关联和复盘更新四处找断点,形成可执行闭环清单。
-
Harbor镜像复制失败排查-5个检查点
跨机房、跨集群或主备仓库同步时,Harbor镜像复制失败会拖慢发布节奏。本文按策略触发、目标凭据、TLS 证书、jobservice 队列和 digest 校验拆解排查顺序,帮助团队少走盲目重试的弯路。
-
GitOps漂移检测怎么做?同步与回滚边界
生产环境出现 OutOfSync 时,真正难点不是把状态重新同步,而是判断差异来自紧急修复、控制器补字段还是错误提交。读完本文可获得一套 GitOps漂移检测与回滚边界清单。
-
GitOps控制环原理:同步与漂移修复
GitOps 不只是把 YAML 放进仓库,真正起作用的是控制环持续比较、同步和校验状态。本篇从期望状态、实际状态、健康检查和漂移修复拆解 GitOps控制环原理。
-
Argo CD权限治理-项目隔离与同步权限设计
Argo CD 真正进入多团队使用后,风险往往不在能不能同步应用,而在谁能同步到哪个集群、能改哪些项目、漂移后谁负责处理。本文给出权限治理设计路径。
-
软件供应链安全是什么?SBOM、签名校验与制品可信机制
从代码提交到镜像上线,风险可能出现在依赖引入、构建环境、制品仓库和部署准入的任一环节。本文用流程、清单和治理路线拆解软件供应链安全,帮助团队把“相信制品”转成“验证制品”。
-
GitOps回滚与变更审计怎么做?多环境发布治理实践
GitOps 的价值不只是自动同步配置,更在于当生产变更出问题时,团队能快速判断谁改了什么、环境是否漂移、应该回滚到哪个可信状态。
-
平台工程效果怎么衡量?交付效率、开发体验与成本指标
平台工程不是上线一个门户就结束。要判断平台是否有效,需要同时观察交付速度、开发体验、稳定性、成本和团队采用情况,而不是只统计功能数量。
-
容器化开发怎么做:Dockerfile、本地调试、日志与CI/CD镜像版本
适合需要把应用交付到容器平台的研发工程师阅读,文章从Dockerfile、本地调试、日志规范、健康检查、资源边界到CI/CD镜像版本管理,帮助开发流程更贴近生产运行。
-
Jenkins迁移怎么做:迁移到GitLab CI或企业DevOps平台的风险与回滚
适合准备替换或收敛Jenkins流水线的研发效能团队阅读,文章从存量盘点、迁移分层、双跑验证、权限凭证和回滚预案展开,帮助团队把Jenkins迁移做成可控工程。
-
DevOps平台建设怎么规划:流水线、制品、环境与发布治理
适合正在从分散CI/CD工具走向统一交付平台的研发效能、平台工程和架构团队阅读,文章围绕流水线、制品、环境、发布和审计治理,形成可推进的DevOps平台建设蓝图。
-
CI/CD流水线如何设计多环境发布流程:制品、审批与回滚
这篇文章从制品一致性、环境晋级、审批节点和回滚策略出发,解释 CI/CD 流水线如何支撑多环境发布,帮助团队避免每个环境重新构建、手工改配置和发布失败后无法快速恢复。
-
内部开发平台如何做自服务交付:模板、环境与权限流程
这篇文章从应用模板、环境申请、权限流程和交付标准化角度,解释内部开发平台为什么要做自服务,以及如何避免自服务变成“把复杂流程换成另一个复杂页面”。
-
IT运维大模型怎么落地?LLM提升智能运维的方法
当平台进入多团队、多环境或规模化运行阶段,IT运维大模型怎么落地?LLM提升智能运维的方法需要从能力、风险和运营闭环一起评估。
-
多云迁移工具怎么选?跨云数据同步与应用迁移
面向正在建设跨云资源接入、统一身份、网络隔离、应用部署、监控告警和运维协同的团队,本文拆解多云迁移工具怎么选?跨云数据同步与应用迁移的适用边界、落地步骤和治理重点。
-
混合云运维监控告警怎么统一?阈值与通知渠道设计
当平台进入多团队、多环境或规模化运行阶段,混合云运维监控告警怎么统一?阈值与通知渠道设计需要从能力、风险和运营闭环一起评估。
-
云原生推理套件怎么用?大模型部署与运维实践
面向正在建设异构资源纳管、模型服务部署、任务调度、成本核算、SLA保障和多团队自助使用的团队,本文拆解云原生推理套件怎么用?大模型部署与运维实践的适用边界、落地步骤和治理重点。
-
一云多芯迁移怎么做?系统、数据库与应用迁移方法
围绕Kubernetes平台治理的真实落地场景,本文把资源对象、控制面、节点运行、交付入口串起来说明,帮助团队降低试错和排障成本。
-
跨集群应用迁移怎么做?联邦集群与灾备实践
这篇文章不把跨集群应用迁移怎么做?联邦集群与灾备实践当作孤立工具,而是放在平台标准化、运维协作和业务连续性之间分析。
了解更多关于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 等工具没有绝对优劣,关键是匹配组织现状和平台策略。
- 是否能对接现有代码仓库、合并请求、分支策略和权限体系。
- Runner 是否支持隔离、弹性扩缩容、缓存和 Kubernetes 动态构建环境。
- 流水线模板是否便于复用,能否沉淀标准构建、测试和安全检查。
- 密钥、制品、日志、审计和失败重试机制是否完整。
- 能否与镜像仓库、发布平台、GitOps 或 Kubernetes 集成。
CI/CD流水线标准化会不会降低团队灵活性?
好的标准化不会消灭灵活性,而是把高风险、重复性的部分统一起来。 例如代码扫描、制品命名、镜像推送、部署审计和质量门禁适合标准化;构建命令、测试矩阵、业务参数和发布节奏可以保留差异。
平台侧可以提供模板、默认阶段和安全基线,业务团队通过参数和扩展步骤适配自身应用。这样既能降低重复维护成本,又不会把所有应用强行塞进同一条固定流水线。真正需要避免的是“表面统一”,即模板看似一致,但每个团队都在私下绕过规则。
CI/CD流水线是否应该完全自动上线?
不一定。是否完全自动上线取决于业务风险、合规要求、测试质量、监控能力和回滚能力。对低风险服务,可以逐步推进自动发布;对核心系统,生产发布可能仍需要审批、灰度、发布窗口和人工确认。
判断是否适合自动上线,可以看几个条件:测试是否覆盖关键路径,发布后是否有健康检查和告警,失败后是否能快速回滚,变更记录是否可审计,团队是否清楚故障响应责任。自动化上线不是目标本身,稳定、可控、可恢复的交付才是目标。
CI/CD指标应该看哪些?
CI/CD 指标应该帮助团队发现交付瓶颈,而不是单纯考核部署次数。常见指标包括部署频率、变更前置时间、变更失败率、平均恢复时间、流水线成功率和流水线耗时。
这些指标需要结合业务上下文解读。部署频率提升但失败率也提升,说明交付质量可能在下降;流水线耗时变长,可能是测试、依赖、缓存或构建环境出现瓶颈;平均恢复时间过长,则说明回滚、监控和应急流程需要改进。