物界前沿
零基础入门AI编程100讲150期: 什么是CI/CD？ CI/CD 是让代码从写完到上线尽可能自动化、标准化的工程流程，目标是更快、更稳、更少出错地交付。本期用通俗方式讲清 CI 与 CD 的区别，以及持续集成、持续交付和持续部署如何通
从提交代码到安全上线 CI CD 图文教程
根据 AI编程大白视频整理的入门教程与编辑测评
写完代码只是软件交付的起点。代码还要经过构建、测试、打包、部署和验证，才能稳定地交到用户手中。CI/CD 的作用，就是把这条容易出错的人工流程变成一条可重复、可追踪、可自动执行的交付流水线。
本文根据 AI编程大白的《零基础入门 AI 编程 100 讲第 150 期 什么是 CI/CD》整理。原视频约 6 分 04 秒，本文经作者授权改编，截图均来自原视频。观看原视频。文中的“视频讲解”用于复述原视频观点，“教程补充”和“编辑测评”用于帮助读者理解应用条件与边界。
图 1：CI/CD 的核心作用，是把写完代码到上线交付之间的流程自动化、标准化。视频 00:10。
一 为什么需要 CI CD
没有固定流程时，发布软件往往依赖人工记忆：开发者在自己的电脑上编译，手动运行几项测试，把文件发给运维，再由运维登录服务器操作。每个人的步骤可能不同，环境也可能不同。一次遗漏、一个错误版本或一项未执行的测试，都可能让发布失败。
CI/CD 解决的并不是“怎么把代码写出来”，而是“怎样持续把代码可靠地交付出去”。可以把它理解成一条软件生产线：每次代码变化都会触发一套明确的检查；通过后产生可以部署的软件包，再按照既定策略进入测试环境或生产环境。
视频把它概括为“软件交付方式升级”。这句话抓住了重点：CI/CD 不是某一款软件，也不是单个按钮，而是一套由版本管理、自动化检查、环境管理、发布策略、监控和回滚共同组成的工程流程。
二 CI 是什么
CI 的英文是 Continuous Integration，中文通常译为“持续集成”。它要求开发者频繁地把小批量代码合并到共享代码库，每次提交或合并都自动进行检查。
图 2：持续集成强调频繁合并和自动检查，尽早发现不同代码之间的冲突。视频 00:35。
一个常见的 CI 流程包括以下环节：
1. 开发者把代码推送到 Git 仓库，或者提交合并请求。
2. 流水线自动拉取当前代码和依赖。
3. 执行构建或编译，确认项目能够生成可运行产物。
4. 执行单元测试和接口测试，检查已有功能是否被破坏。
5. 执行代码规范、安全漏洞和依赖风险检查。
6. 汇总结果，并把成功或失败状态反馈给开发者。
图 3：视频展示的自动检查项目包括构建、单元测试、接口测试、规范扫描、安全扫描和依赖检查。视频 01:02。
这里最关键的不是“测试项目越多越好”，而是每一项检查都能稳定重复，并且失败时能阻止问题继续向后流动。例如，编译失败就不应生成发布包；关键单元测试失败就不应合并主分支；发现高危漏洞时应暂停部署。
怎样判断 CI 已经起作用： 团队每次提交都能看到一份明确结果，失败信息能定位到具体环节，通过的提交才有资格进入下一阶段。只在发布前偶尔运行一遍脚本，还不能算持续集成。
图 4：问题在开发阶段被发现，修复成本通常低于上线后再排查。视频 01:43。
视频强调 CI 能够“早发现问题”。原因很直接：改动规模越小，可能的原因越少；发现时间越早，开发者对刚才的改动记忆越清楚。等大量代码堆积后再统一测试，冲突、缺陷和责任范围都会变得更难判断。
三 CD 的两种含义
CD 常见的两种解释是 Continuous Delivery 和 Continuous Deployment，分别对应持续交付与持续部署。二者前面的流程非常相似，区别集中在生产发布的最后一步。
图 5：持续交付保留人工确认，持续部署在检查通过后自动上线。视频 02:07。
持续交付
代码通过构建、测试和预发布验证后，始终保持“可以发布”的状态。是否真正推到生产环境，由负责人根据业务时间、风险、审批要求或市场计划作出决定。
它适合需要变更审批、存在明确发布窗口、监管要求较高，或者仍希望由人判断业务风险的团队。
持续部署
只要代码通过所有自动化关卡，就由流水线自动部署到生产环境。人工不再逐次点击发布，但团队仍需要监控、告警、灰度控制和自动回滚来约束风险。
它适合自动化测试成熟、发布频率高、变更可以拆得很小，并且系统具备完善观测能力的团队。
容易混淆的地方： 持续部署并不是“没有审核”。代码评审、分支规则、自动测试和安全策略本身就是审核机制，只是审核被提前并固化在流水线中。持续交付也不是手工完成所有步骤，它通常只把最终生产发布保留为人工确认。
四 一条完整流水线怎样工作
传统发布的问题不只是慢，还包括大量等待和信息传递。开发完成后要发邮件、准备说明、联系运维、等待批准；失败后再回到开发阶段重新处理。步骤越依赖人工，结果越难稳定复制。
图 6：传统发布中的手工部署、审批、环境准备和故障处理容易形成等待链。视频 02:22。
CI/CD 会把可确定的步骤固定下来。一次代码提交进入流水线后，每一步都有输入、输出和状态，失败时停在对应环节，不让未经验证的产物继续向后移动。
图 7：拉取代码、安装依赖、构建、测试、生成制品和部署环境形成固定流程。视频 02:54。
下面用一个网站功能更新作为例子：
1. 开发者完成“购物车优惠券”功能，推送分支并创建合并请求。
2. CI 自动安装锁定版本的依赖，编译前端和后端代码。
3. 单元测试检查优惠计算，接口测试检查订单服务调用。
4. 规范检查、安全扫描和代码评审全部通过后，代码合入主分支。
5. 流水线生成带版本号的软件包或容器镜像，并保存到制品库。
6. 同一份制品部署到测试环境，执行集成测试和冒烟测试。
7. 持续交付模式下，负责人确认后发布；持续部署模式下，规则满足后自动发布。
8. 发布后监控错误率、响应时间和业务指标；异常时停止放量或回滚到旧版本。
这里有两个经常被忽略的原则。第一，测试环境和生产环境应使用同一份构建产物，避免临时重新打包。第二，失败结果也必须可见，不能为了让流水线显示绿色而跳过不稳定测试。
图 8：小批量、高频率发布能缩小单次变更范围，降低排查和回退成本。视频 03:08。
把一次大版本拆成多个小版本，通常更容易定位问题。小版本不代表功能没有规划，而是把交付单元拆小，让每一次上线都更容易测试、观察和回滚。
图 9：统一运行环境、配置和依赖，可以减少“本地正常、线上失败”。视频 03:42。
环境一致性同样重要。团队需要明确运行时版本、依赖版本、配置来源和基础设施差异。容器可以帮助封装应用与依赖，但数据库、网络、密钥和外部服务仍需单独管理，不能因为用了容器就假定所有环境完全相同。
图 10：视频给出的典型流程覆盖提交、CI、测试、制品、测试环境、批准和生产发布。视频 04:03。
五 发布策略怎样降低风险
流水线可以自动执行发布，但仍要决定新版本怎样替换旧版本。视频重点展示了蓝绿部署和金丝雀发布。
图 11：两种策略都通过控制流量来降低一次性全量替换的风险。视频 04:30。
蓝绿部署： 同时保留旧环境和新环境。新版本先部署到未接收正式流量的环境，验证后切换流量；出现问题时可以迅速切回旧环境。优点是回退直接，代价是需要准备两套环境，并处理数据库兼容问题。
金丝雀发布： 先让少量用户访问新版本，观察错误率、延迟和业务指标，再逐步扩大流量。它能够在真实环境中控制影响范围，但要求系统可以分流，并且团队提前定义“继续放量”和“立即回退”的指标。
教程补充：滚动发布也是常见方式，即逐批替换运行实例。无论使用哪种策略，数据库变更都应尽量保持向前、向后兼容，否则应用回退后可能无法读取已经改变的数据结构。
六 CI CD 为什么会更快
速度提升并不是因为机器单独执行某一步一定比人快，而是因为等待、交接和重复劳动减少了。开发者可以更早获得反馈，测试和构建可以并行，发布步骤可以重复执行，故障也能依靠日志和版本记录更快定位。
图 12：人员负责方案、评审和判断，机器负责重复构建、测试、打包和部署。视频 04:42。
真正值得追求的指标不是“每天发布多少次”，而是一次改动从提交到得到有效反馈需要多久、发布失败率多高、故障后恢复需要多久。发布次数增加但失败率和恢复时间同时恶化，并不能证明流程更成熟。
七 上线 CI CD 需要哪些前提
CI/CD 不是写一个配置文件就能安全上线。视频给出了四项关键前提：自动化测试、分支与代码评审、监控告警、回滚方案。
图 13：缺少质量关卡和故障处理能力时，自动化只会让错误更快进入生产环境。视频 05:26。
落地前可以逐项检查：
代码是否统一进入版本库，主分支是否受到保护。
每次提交是否能自动构建，依赖版本是否可以复现。
核心逻辑是否有可靠的自动化测试，而不是只追求覆盖率数字。
软件包或镜像是否带有唯一版本，能否追溯到具体提交。
环境配置和密钥是否安全管理，是否避免写进代码仓库。
发布前后是否有健康检查、错误率、延迟和业务指标。
蓝绿、金丝雀或滚动发布是否有明确的停止条件。
旧版本和数据是否支持回退，团队是否真正演练过回滚。
发布权限、审批记录和操作日志是否满足团队管理要求。
建议从最短闭环开始：先让一个项目做到“提交后自动构建并执行核心测试”，稳定后再加入制品管理、测试环境部署和生产发布。一次把所有工具全部接入，往往会产生一条难以排查的新流水线。
八 编辑测评
视频讲得清楚的地方： 它用手绘画面把 CI、持续交付和持续部署分开说明，并把“自动检查”“小步发布”“环境一致”“发布策略”和“实施前提”串成完整逻辑。尤其是最后强调测试、评审、监控和回滚，避免把 CI/CD 简化成自动上线按钮。
需要读者继续补齐的部分： 视频属于概念入门，没有演示 GitHub Actions、GitLab CI、Jenkins 等工具的实际配置，也没有展开数据库迁移、密钥管理、制品仓库、审批权限和指标阈值。看懂视频后，读者已经能够判断流水线应包含什么，但还不能仅凭这些画面直接搭建生产系统。
适合谁： 适合第一次接触软件交付流程的开发者、产品和运营人员，也适合需要与研发团队沟通发布过程的管理者。已经负责生产平台的工程师，则应把本文作为概念清单，再结合自己的技术栈制定测试、部署、监控和回滚标准。
图 14：CI 负责频繁集成和尽早发现问题，CD 负责稳定快速交付或部署，最终目标是可靠升级软件交付方式。视频 05:55。
CI/CD 的价值可以用一句话概括：让每次代码变化都沿着一条可验证的路径走向用户。工具会更换，平台会升级，但频繁集成、自动检查、固定产物、环境一致、渐进发布、持续监控和随时回退这些原则不会轻易过时。
原作者：AI编程大白。本文为经作者授权整理的图文教程与编辑测评，图片来源于原视频。原视频链接。
经作者授权整理。原视频链接：https://www.douyin.com/video/7652365140377046298
发布于 2026-06-17
连续更新【AI编程100讲】系列课程 10年开发经验