如何理解 CI/CD，它怎样用于项目交付？

核心回答

CI/CD 是把代码变更持续地验证、打包并交付到运行环境的一套工程流程。

**CI（持续集成）**强调频繁集成代码，通过自动构建、静态检查和测试尽早发现问题。**持续交付（Continuous Delivery）**进一步把经过验证的版本保持在可发布状态，生产发布时机可以由团队决定。**持续部署（Continuous Deployment）**则把满足发布条件的变更自动部署到生产环境，因此 CD 的具体含义需要结合上下文说明。

以 Jenkins + Harbor 交付一个后端服务为例：代码变更触发 Jenkins，检出确定的提交并安装依赖，运行检查和测试，构建镜像并推送 Harbor，再部署同一镜像到测试或生产环境，最后做健康与业务验证。Jenkins 编排步骤，Harbor 保存和分发镜像，主机或容器平台负责运行服务。

流水线的价值是让交付可重复、失败可定位、版本可追溯，并在发布异常时有恢复办法。它不只是定时跑一轮回归测试，也不等于执行一次远程部署脚本。

一次交付包含哪些环节

1. 触发与检出： 根据提交、合并请求、标签或人工触发规则启动，记录代码提交、分支和构建编号，避免执行过程中取到另一份代码。
2. 准备与验证： 使用明确的运行环境和依赖版本，执行格式、类型、单元及必要集成检查。检查范围按项目和变更风险配置，报告与失败日志保留到对应构建。
3. 构建与归档： 生成可部署的软件包或镜像，关联代码版本、构建编号和镜像摘要。验证后的制品继续向后交付，而不是在每个环境重新构建一份无法对应的程序。
4. 环境部署： 注入目标环境的配置，执行必要迁移并启动新版本。测试环境验证后，按项目发布策略进入后续环境；部署权限和凭据由平台管理。
5. 发布验证与观察： 检查实例就绪、关键接口和核心业务流程，并关注错误率、延迟等变化；异常时停止继续放量或执行恢复。

独立的检查可以并行，存在前后依赖的步骤顺序执行。例如测试和静态检查可以并行，但部署必须拿到构建产物，并满足相应检查要求。测试任务未执行、全部被跳过或报告未生成，也需要与真正通过区分。

Jenkins、Harbor 和 Docker 各做什么

Jenkins 是自动化执行与编排工具。可以把流水线写成 Jenkinsfile，与应用代码一起版本管理，让阶段、触发条件和失败处理能够复查。Stage 用来划分构建、测试、部署等阶段，Step 是阶段中的具体动作；执行这些动作的机器仍需要相应工具和权限。

Dockerfile 描述镜像怎样构建，镜像包含应用及必要运行依赖，容器是镜像运行后的实例。Harbor 接收并保存构建出的镜像，部署端再拉取运行。把镜像推到 Harbor，只说明制品已可获取，服务还没有因此自动更新。

镜像标签默认可以被重新指向另一份内容。发布记录可以保存可读的版本标签，同时用 digest 明确锁定制品；Harbor 的标签不可变规则也能限制覆盖。这样才容易确认测试验证的镜像与生产运行的镜像是否相同。

应用配置和数据生命周期另外管理。生产凭据无需写进镜像，数据库和上传文件也不应随着替换应用容器而丢失。

怎样判断发布成功，失败后怎样恢复

部署命令退出成功，只覆盖了命令执行这一层。还需要检查进程是否健康、依赖是否可达、目标版本是否生效，以及关键业务是否正常。例如 API 服务启动了，但数据库迁移未完成，仍可能无法处理请求。

发布记录应关联代码提交、制品摘要、配置版本、目标环境和检查结果。回退时重新部署已知可用的历史制品及匹配配置，部署来源应明确到版本；使用一个不断变化的 latest 无法可靠表达要回到哪一版。

代码回退不一定能撤销数据库结构变更、已发送消息或外部业务操作。因此迁移需要考虑新旧版本兼容，必要时采用分步变更、补偿或单独的数据恢复方案。回滚后同样检查业务恢复情况。

追问：持续交付是否意味着每次提交都上线

不是。CI 可以在每次提交或合并请求上运行，交付流程还会决定哪些版本具备发布条件、进入哪个环境以及何时发布。持续交付的重点是让发布成为可重复执行的流程；持续部署才进一步自动完成生产发布。

项目较小时，也可以从“自动检查、构建制品、部署测试环境、验证结果”这条短链路起步，再根据发布频率和风险增加所需能力，无需一开始就堆满平台和阶段。

对应教程

参考资料