CI/CD

Continuous Integration / Continuous Deployment

也常被叫作：持续集成持续交付自动构建自动发布流水线流水线

部署与运维通常止于「运行时」约 1 分钟读完

你可能会这么说

「每次改完代码都要手动传到服务器，太麻烦，能不能让机器自动帮我做？」

CI/CD Continuous Integration / Continuous Deployment

用一条自动化流水线把「检查、构建、测试、部署」串起来，改完代码自动走完，不用人肉传文件。

CI（持续集成）和 CD（持续交付/部署）常常被一起说，但你要分清楚一半：CI 管到「代码是健康的」——每次改动自动跑一遍检查、构建、测试，任何一步挂了就当场亮红灯；CD 管到「健康的代码真的上线了」——构建产物自动传到线上。很多工具把这两件事做进同一条流水线，于是你看到的是一个「改完代码 → 自动发布」的完整链条。

对不懂技术的人来说，CI/CD 最大的价值不是「省了手动点几下」，而是把「能跑」这件事变得可重复、可回看。手动部署最大的问题不是慢，而是每个人每次做法不一样，出问题说不清是这次哪步错了。流水线让每一步都有记录、有日志、失败了有明确的红点，你能问 AI「这一步为什么挂」，而不是对着一个黑盒子猜。

也要清醒一点：流水线是自动的，不代表它是安全的。一个自动部署的流水线，一旦跑起来，就是把「改完就上线」这个权力交给了配置。该跑的检查没跑、测试被跳过、部署前没人确认——这些才是自动化的真实风险。自动化放大的不是好结果，而是你的检查有多严。

长什么样真实可交互，不是截图

你提交代码→CI 检查→构建→测试→部署到线上

✕ 常见坑测试步骤被跳过
失败也照样部署（没拦住）
改了配置没人知道

✓ 健康的流水线每一步有日志可回看
测试挂了红灯，部署停住
真正的产物就是被部署的东西

右边第二行是核心：CI 的意义在于「没通过就拦下来」。如果失败还照常发布，那自动化只是在把错误更快地散播出去。

拆开看，里面有这几块

1
触发器 Trigger
什么事件会启动流水线——通常是「代码推送到某个分支」，也可能是定时或手动。
2
构建 Build
把源码编译成能运行的产物。构建失败是最好的失败，它当场告诉你。
3
测试 Test
自动跑的检查。这一步最容易被人为跳过，跳过等于没设 CI。
4
产物 Artifact
构建出来的、真正会被部署的那个东西。和源码是两回事。
5
部署步骤 Deploy step
把产物送到线上。这一步通常需要环境变量和密钥，也是最该谨慎的一步。
6
日志 Logs
每一步的原始输出。出问题时这是你唯一能对 AI 说「贴给我看」的东西。

常见的有哪几种

纯 CICI only

只管检查和测试，部署还是手动。风险最低的起步方式。

用在：第一次搭，先让「能跑」变得可重复

CI + 自动部署CI + auto deploy

测试通过后自动上线。省事，但要把「哪些分支能自动部署」定死。

用在：团队已稳定、改动频、有回滚

CI + 灰度CI + canary

自动部署到一小部分用户，观察没问题再全量。

用在：用户量大、改动有风险

容易搞混？这样区分

CI/CD ≠ 构建 Build

构建只是 CI 流水线里一步（把源码变产物）。CI/CD 是这条流水线的整条。AI 说「构建通过了」，只证明产物出来了，不证明测试过了、更不证明上线了。

看构建

CI/CD ≠ 部署 Deployment

部署可以是手动的；CI/CD 强调的是自动且每次一致。你可以手动部署，也可以在 CI/CD 里部署。部署是「做什么」，CI/CD 是「怎么每次都自动做对」。

看部署

CI/CD ≠ Git Git

Git 是管代码版本的工具；CI/CD 是被某个事件（比如往 Git 推代码）触发的自动化流程。Git 是仓库，流水线是流水线，别混成一个东西。

看 Git

什么时候用得上

第一次搭流水线

先只做 CI：提交代码自动检查 + 测试，部署先保持手动。地基稳了再加自动上线。

自动部署

测试通过后自动发到线上。定死「哪个分支才允许自动部署」，别让任何推送都能上线。

流水线挂了

让 AI 把挂掉那一步的原始日志贴给你，问它「这步原本该做什么、为什么没拦住」。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】给我的项目 [项目名/目录] 搭一条 CI/CD 流水线
【范围】只新建流水线配置文件和说明文档；不改业务代码、不改构建方式
【分两步，不要合并】
  第一步：只做 CI——推送代码后自动执行检查 + 构建 + 测试，任何一步失败就亮红灯、**阻止部署**，先贴给我看跑通后的日志
  第二步：我说确认后，再加自动部署
【必须说清】
  1. 触发条件是什么（哪个分支、什么事件会启动）
  2. 部署步骤会用到哪些环境变量和密钥，这些值存在哪里，会不会出现在日志里
  3. 哪些分支允许自动部署，哪些不允许
  4. 出问题怎么手动回滚
【边界】不要读取或输出任何真实密钥；不要在流水线日志里打印敏感信息；不要改动构建脚本本身
【交付】告诉我文件放在哪、推送一次代码后在哪看流水线结果，并把首次运行的原始日志贴给我

「分两步」在这里尤其值钱：很多自动化事故发生在「还没想清楚部署权限就顺手加上了自动上线」。先让检查跑通、看清密钥存哪，再谈部署。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

推送一次真实的代码改动，去看流水线页面，能看到它真的被触发、按步骤跑完，每一步有原始日志。
故意制造一个会挂的检查（或改坏一行），确认流水线变红并停住，没有继续往下部署。这直接验「拦得住」才是 CI 的意义。
找到「部署到哪、用哪个分支」的配置，确认自动部署只对你允许的分支生效。
看日志里有没有把密钥或敏感值打印出来（搜索密钥名的开头字符）。
问清并确认回滚方法：某次自动部署出问题，怎么退回去。

它常这么糊弄你

「CI/CD 已配置完成」——但流水线根本从没被真实触发过，只是配置文件写好了。要求推送一次看真实运行日志。
测试步骤被 skip 或直接删掉，声称「配置了」。检查流水线每一步到底执行了什么。
「检查失败了，但部署还是执行了」——这是最危险的糊弄：自动化没拦住失败，等于没设。
在日志里打印密钥，声称「这是方便调试」。密钥一旦出现在日志，就等于泄露了。
用本地手动运行冒充流水线跑通。流水线必须在平台/服务器上真实触发，不是在你机器上点一下。

CI/CD 最高能验到「运行时」层：在你真实的环境里跑通、失败被拦。要说到「生产」层，还需要线上观察、告警、回滚演练这些更长链条的东西，不是搭条流水线就够。

考考你选一个你觉得对的

搭好了 CI/CD，怎么最快验出它是真的而不是摆设？

想再深挖一点靠谱出处

GitHub Actions 文档GitHub Docs ↗CI/CD（持续集成 / 持续交付）Wikipedia ↗GitLab CI/CD 文档GitLab Docs ↗

# CI/CD (Continuous Integration / Continuous Deployment)

> 用一条自动化流水线把「检查、构建、测试、部署」串起来，改完代码自动走完，不用人肉传文件。

**你可能会这么说**：每次改完代码都要手动传到服务器，太麻烦，能不能让机器自动帮我做？

CI（持续集成）和 CD（持续交付/部署）常常被一起说，但你要分清楚一半：CI 管到「代码是健康的」——每次改动自动跑一遍检查、构建、测试，任何一步挂了就当场亮红灯；CD 管到「健康的代码真的上线了」——构建产物自动传到线上。很多工具把这两件事做进同一条流水线，于是你看到的是一个「改完代码 → 自动发布」的完整链条。 对不懂技术的人来说，CI/CD 最大的价值不是「省了手动点几下」，而是把「能跑」这件事变得可重复、可回看。手动部署最大的问题不是慢，而是每个人每次做法不一样，出问题说不清是这次哪步错了。流水线让每一步都有记录、有日志、失败了有明确的红点，你能问 AI「这一步为什么挂」，而不是对着一个黑盒子猜。 也要清醒一点：流水线是自动的，不代表它是安全的。一个自动部署的流水线，一旦跑起来，就是把「改完就上线」这个权力交给了配置。该跑的检查没跑、测试被跳过、部署前没人确认——这些才是自动化的真实风险。自动化放大的不是好结果，而是你的检查有多严。

**也叫**：持续集成、持续交付、自动构建、自动发布流水线、流水线

## 你可以这样告诉 AI

```text
【任务】给我的项目 [项目名/目录] 搭一条 CI/CD 流水线
【范围】只新建流水线配置文件和说明文档；不改业务代码、不改构建方式
【分两步，不要合并】
  第一步：只做 CI——推送代码后自动执行检查 + 构建 + 测试，任何一步失败就亮红灯、**阻止部署**，先贴给我看跑通后的日志
  第二步：我说确认后，再加自动部署
【必须说清】
  1. 触发条件是什么（哪个分支、什么事件会启动）
  2. 部署步骤会用到哪些环境变量和密钥，这些值存在哪里，会不会出现在日志里
  3. 哪些分支允许自动部署，哪些不允许
  4. 出问题怎么手动回滚
【边界】不要读取或输出任何真实密钥；不要在流水线日志里打印敏感信息；不要改动构建脚本本身
【交付】告诉我文件放在哪、推送一次代码后在哪看流水线结果，并把首次运行的原始日志贴给我
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 推送一次真实的代码改动，去看流水线页面，能看到它真的被触发、按步骤跑完，每一步有原始日志。
- [ ] 故意制造一个会挂的检查（或改坏一行），确认流水线变红并停住，没有继续往下部署。这直接验「拦得住」才是 CI 的意义。
- [ ] 找到「部署到哪、用哪个分支」的配置，确认自动部署只对你允许的分支生效。
- [ ] 看日志里有没有把密钥或敏感值打印出来（搜索密钥名的开头字符）。
- [ ] 问清并确认回滚方法：某次自动部署出问题，怎么退回去。

常见糊弄：
- 「CI/CD 已配置完成」——但流水线根本从没被真实触发过，只是配置文件写好了。要求推送一次看真实运行日志。
- 测试步骤被 skip 或直接删掉，声称「配置了」。检查流水线每一步到底执行了什么。
- 「检查失败了，但部署还是执行了」——这是最危险的糊弄：自动化没拦住失败，等于没设。
- 在日志里打印密钥，声称「这是方便调试」。密钥一旦出现在日志，就等于泄露了。
- 用本地手动运行冒充流水线跑通。流水线必须在平台/服务器上真实触发，不是在你机器上点一下。

来源：https://mickerbook.com/reference/t/ci-cd/