📚 课程目录第2章核心概念

核心概念：持续集成、持续交付、持续部署与 MLOps 基础

在进入 AI DevOps 自动化流水线的具体实践之前，必须先厘清一组经常被混用、但在工程语义上截然不同的核心概念：持续集成（CI）、持续交付（CD）、持续部署（CD），以及面向机器学习工作负载的 MLOps。这四者构成了自动化流水线的价值阶梯——从“代码合并后自动验证”到“模型上线后自动反馈”，每一层解决不同的问题，也对应不同的自动化深度。

2.1 持续集成（CI）：让每一次提交都不“带病”合并

持续集成的核心动作是频繁地将开发者的代码变更合并到主干分支，并自动触发构建与测试。它的目标不是“自动化跑测试”这么简单，而是通过高频合并来消除“集成地狱”——即多人各自开发数周后一次性合并导致的冲突爆炸与回归灾难。

一个标准的 CI 流水线通常包含以下阶段：

代码提交触发：开发者推送代码到 Git 仓库的特定分支（如 main 或 develop）。
静态检查：运行 linter（如 ESLint、Pylint）与格式检查，确保代码风格统一。
单元测试：执行针对函数/模块的自动化测试，通常要求覆盖率阈值（如 ≥80%）。
构建：编译代码、构建镜像或打包产物，验证“代码能成功变成可运行制品”。
结果反馈：将测试报告、覆盖率、构建日志回传到代码平台（如 GitLab/GitHub），并通知相关责任人。

在 AI 项目中，CI 的“测试”对象不仅是代码，还包括数据验证与模型冒烟测试。例如，当训练脚本被修改后，CI 会运行一个小规模数据子集的训练，确保特征管道没有断裂。

关键认知：CI 解决的是“合并前风险”。如果 CI 失败，代码不应被合并到主干。实践中，我们通常使用 Git 分支保护规则（Branch Protection）强制要求 CI 通过后才能 merge。

2.2 持续交付（CD）与持续部署（CD）：一字之差，天壤之别

持续交付与持续部署的英文缩写都是 CD，但含义完全不同。为了区分，下文将前者称为 CDelivery，后者称为 CDeployment。

持续交付（CDelivery） 指的是：所有通过 CI 验证的制品，都自动部署到类生产环境（Staging），并随时具备手动一键发布到生产的能力。它的核心特征是“随时可发布，但发布动作由人触发”。这保证了业务团队对生产发布节奏的掌控权，同时消除了“发布前手工打包、配置环境”的重复劳动。

持续部署（CDeployment） 则更进一步：凡是通过自动化测试的代码/制品，自动部署到生产环境，无需人工审批。它适用于对快速迭代要求极高、且具备完善监控回滚能力的业务场景（如 SaaS 服务的后端 API）。

维度	持续集成（CI）	持续交付（CDelivery）	持续部署（CDeployment）
触发时机	代码推送到分支	CI 通过后自动部署到 Staging	Staging 验证通过后自动部署到生产
生产发布方式	不涉及	人工点击“发布”按钮	全自动，无人工干预
核心目标	快速发现集成错误	降低发布风险与成本	消除发布等待时间
适用场景	所有软件项目	需要业务审批的版本发布	高成熟度 DevOps 团队
失败处理	阻止合并	阻止进入生产候选	自动回滚或金丝雀切换

常见误区：很多团队声称“我们做了 CD”，但实际上只做到了 CI + 手动部署脚本。真正的持续交付要求 Staging 环境与生产环境高度一致，且部署过程完全脚本化、参数化。如果 Staging 与生产配置漂移严重，CDelivery 就形同虚设。

2.3 MLOps 基础：当 CI/CD 遇上模型与数据

传统软件的 CI/CD 处理的是“代码变更”，而机器学习项目还引入了两个新的可变对象：数据集与模型权重。数据变了，模型需要重新训练；代码变了，特征管道可能改变。因此，MLOps 在 CI/CD 的基础上扩展出三个额外能力：

数据版本化：使用 DVC（Data Version Control）或 LakeFS 对数据集进行 Git 式版本管理，确保“哪个模型由哪份数据训练而来”可追溯。
模型注册与版本管理：将训练好的模型（如 MLflow 的 model 产物）作为一等公民存入模型仓库，记录超参数、指标、训练代码版本。
模型验证门禁：在部署前自动评估模型在验证集上的表现，并与当前生产模型进行对比（如 A/B 测试或离线指标比较），只有新模型优于基线时才允许上线。

一个典型的 MLOps 流水线（以训练任务为例）可以抽象为以下阶段：

数据提取 → 数据验证 → 特征工程 → 模型训练 → 模型评估 → 模型部署
   │            │            │            │            │            │
   └── 数据版本 ─┘            └── 实验跟踪 ─┘            └── 模型注册 ─┘

其中，模型评估阶段是 MLOps 特有的“质量门禁”。它不仅要看准确率，还要检查是否存在数据泄漏、偏差（Bias）或对特定分组的性能下降。

2.4 核心概念关系图：从代码到模型的自动化阶梯

为了直观理解这四个概念在流水线中的位置与关系，下图展示了从代码提交到模型上线的完整自动化路径，以及各阶段对应的核心问题。

图中自顶向下的四条色带代表了自动化程度的逐级加深：CI 管代码合并，CDelivery 管制品发布，CDeployment 管生产环境变更，而 MLOps 则在每一层之上叠加了数据与模型的版本化、验证与监控能力。值得注意的是，MLOps 并非独立于 CI/CD 的第四种实践，而是将 CI/CD 的原则延伸到数据管道与模型生命周期中。

2.5 案例复盘：一个 AI 项目的流水线演进

某金融风控团队最初只有 CI：每次提交代码后自动跑单元测试，但模型训练与部署完全靠手工。每次模型更新需要数据科学家手动导出权重文件，发给运维同学部署，耗时约 2 小时，且经常出现“训练代码版本与生产模型不匹配”的问题。

团队随后引入 MLflow 进行实验跟踪与模型注册，并将部署脚本化，实现了 CDelivery：模型训练完成后自动注册到模型仓库，Staging 环境自动拉取最新模型进行离线评估。评估通过后，由风控负责人点击“发布”按钮完成生产更新。这一阶段将发布耗时从 2 小时缩短到 10 分钟，且每次发布都有完整的版本记录。

进一步，团队在 Staging 评估中加入了对抗性验证（检查模型对恶意样本的鲁棒性）和公平性指标（不同用户分组的预测差异），并将这些检查全部自动化。当新模型在验证集上的 AUC 不低于当前生产模型，且公平性差异在阈值内时，系统自动执行金丝雀发布——先让 5% 的流量使用新模型，观察 30 分钟无异常后自动全量。至此，该团队实现了真正意义上的 CDeployment + MLOps。

实践建议：不要一开始就追求全自动部署。建议按“CI → CDelivery → CDeployment”的顺序逐步演进，每一步都确保监控、日志与回滚机制到位后再进入下一阶段。对于 AI 项目，优先补上数据版本化与模型注册，这是后续一切自动化的基础。

2.6 常见误区与复盘

误区一：CI 等于“跑一下测试”。真正的 CI 要求测试环境可重复、测试数据隔离、失败信息可追踪，并且必须与代码合并流程强绑定。
误区二：持续交付就是自动化部署到生产。CDelivery 的“交付”意味着制品处于“可发布状态”，但发布动作保留人工审批，这是为了满足合规与业务节奏要求。
误区三：MLOps 就是“给模型训练加个 CI”。MLOps 的核心难点在于数据漂移检测、模型退化监控与自动重训策略，这些远超传统 CI 的范畴。
误区四：所有项目都适合 CDeployment。对于强监管行业（如银行核心系统）或低频版本发布（如嵌入式设备固件），人工审批的 CDelivery 往往比全自动部署更合适。