文章目录
- [从手工作坊到软件工厂：CI/CD 的诞生](#从手工作坊到软件工厂：CI/CD 的诞生)
- 第一次革命：持续集成（CI）
-
- [Continuous Integration](#Continuous Integration)
- [CI 的核心哲学](#CI 的核心哲学)
- [Jenkins 时代](#Jenkins 时代)
-
- [为什么 Jenkins 后来被嫌弃？](#为什么 Jenkins 后来被嫌弃？)
- [第二次革命：CI 即代码](#第二次革命：CI 即代码)
-
- [Pipeline as Code](#Pipeline as Code)
- [GitHub Actions 的出现](#GitHub Actions 的出现)
-
- [Actions 本质是什么](#Actions 本质是什么)
- [你看到的 Workflow 到底是什么](#你看到的 Workflow 到底是什么)
- [CI 为什么和 Docker 越来越绑定](#CI 为什么和 Docker 越来越绑定)
- 第三次革命：持续交付（CD）
-
- [Continuous Delivery](#Continuous Delivery)
- 第四次革命：持续部署（CD）
-
- [Continuous Deployment](#Continuous Deployment)
- 现代互联网公司的流水线
- [AI Coding 时代为什么更需要 CI/CD](#AI Coding 时代为什么更需要 CI/CD)
- [作为 AI 工程师，你应该掌握什么](#作为 AI 工程师，你应该掌握什么)
从手工作坊到软件工厂：CI/CD 的诞生
远古时代（2000年前后）
当时开发流程大概是：
text
开发A
↓
开发B
↓
开发C
↓
手动上传服务器
↓
线上炸了典型情况：
bash
scp app.jar server:/opt/app或者：
bash
ftp upload然后：
bash
ssh server
./restart.sh问题：
每个人环境不同
A电脑：
text
Java 8B电脑：
text
Java 11结果：
text
我这里能运行
你那里为什么报错？合并后才发现冲突
开发A：
python
def pay():开发B：
python
def payment():上线前才发现：
text
Merge Conflict发布依赖人工
运维：
text
今天晚上11点发布然后所有人等待：
text
别动代码！整个公司进入戒严状态。
第一次革命：持续集成（CI）
Martin Fowler 提出了一个理念：
不要等一个月再合并代码。
应该：
text
每天合并
甚至每小时合并于是出现：
Continuous Integration
持续集成
流程：
text
提交代码
↓
自动构建
↓
自动测试
↓
发现问题而不是：
text
提交代码
↓
一个月后
↓
项目炸掉CI 的核心哲学
不是：
text
自动运行脚本而是：
text
尽可能早发现问题英文里有个说法：
Shift Left
把问题往左移动。
时间线：
text
开发 → 测试 → 上线改成：
text
编码时 → 发现问题因为：
text
越晚发现问题
修复成本越高Jenkins 时代
大约 2010 年前后。
出现了：
Jenkins
它几乎统治了 CI 世界十几年。
当时流程：
text
Git Push
↓
Jenkins
↓
编译
↓
测试
↓
发送邮件Jenkins 本质：
text
自动化任务调度器例如：
groovy
Build
Test
Deploy串起来。
为什么 Jenkins 后来被嫌弃？
因为太重。
需要：
text
自己买服务器
自己维护
自己升级
自己装插件最后：
text
维护 Jenkins 的成本
比维护业务系统还高很多公司都有：
text
Jenkins 专家专门修 Jenkins。
第二次革命：CI 即代码
后来大家发现：
text
流程配置
也是代码于是出现：
Pipeline as Code
例如：
yaml
build:
test:
deploy:写进仓库。
这样：
text
代码
+ 流程一起版本管理。
GitHub Actions 的出现
2019年以后。
GitHub Actions
把 CI 彻底平民化。
以前：
text
GitHub
+
Jenkins现在：
text
GitHub
+
GitHub Actions一步到位。
Actions 本质是什么
很多人以为：
text
GitHub 帮我运行代码其实不是。
本质：
text
GitHub 提供临时服务器当你：
bash
git push时。
GitHub：
text
创建一个全新的虚拟机例如：
yaml
runs-on: ubuntu-latest就是：
text
启动 Ubuntu然后：
yaml
- checkout
- install
- test一步步执行。
执行完：
text
虚拟机销毁你看到的 Workflow 到底是什么
例如：
yaml
name: CI
on:
push:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install
- run: npm test翻译成人话：
text
有人 Push
↓
开一台临时 Ubuntu
↓
下载代码
↓
安装依赖
↓
执行测试
↓
销毁机器仅此而已。
CI 为什么和 Docker 越来越绑定
因为：
text
环境不一致一直是软件工程最大问题之一。
于是出现：
Docker
理念：
text
把运行环境一起打包过去：
text
代码现在：
text
代码 + 环境CI 流程变成：
text
Push
↓
Test
↓
Build Docker Image
↓
Push Registry（Push Registry 是将构建好的Docker镜像推送到镜像仓库）
例如：
text
Docker Hub # Docker官方镜像仓库，最大的公共镜像平台
GHCR # GitHub容器镜像仓库，与GitHub深度集成
ECR # AWS容器镜像仓库，企业级私有仓库服务第三次革命：持续交付（CD）
大家后来发现：
CI 只能发现问题。
但：
text
上线还是人工于是：
Continuous Delivery
持续交付
流程：
text
Push
↓
Test
↓
Build
↓
生成可发布版本到这里结束。
是否上线：
text
人工点击第四次革命：持续部署（CD）
进一步：
Continuous Deployment
流程：
text
Push
↓
Test
↓
Build
↓
Deploy完全自动。
例如：
text
Push main↓
text
Actions↓
text
Docker Build↓
text
Deploy AWS↓
text
线上更新无需人工。
现代互联网公司的流水线
今天的大厂基本都是：
text
Developer
↓
Git Push
↓
CI
↓
Unit Test
↓
Lint
↓
Security Scan
↓
Build Image
↓
Push Registry
↓
Deploy Staging
↓
E2E Test
↓
Deploy ProductionAI Coding 时代为什么更需要 CI/CD
以前：
text
程序员每天写100行代码现在：
text
Claude Code 一天改5000行问题变成：
text
代码增长速度
远超人工审查速度所以很多团队反而更依赖：
- CI
- 自动测试
- 自动检查
- 自动部署
因为：
人工 Review 已经无法验证所有改动。
作为 AI 工程师，你应该掌握什么
不需要成为 DevOps 专家。
但至少要理解：
第一层
能看懂：
yaml
.github/workflows/*.yml第二层
知道：
text
Trigger # 触发条件，启动工作流的事件或条件
Job # 作业任务，工作流中独立的执行单元
Step # 执行步骤，作业中具体的单个操作
Runner # 运行器，执行作业的计算资源或代理
Artifact # 构建产物，作业生成的输出文件或资源
Cache # 缓存机制，存储临时数据以加速后续执行是什么意思。
第三层
能自己写：
text
测试
Docker Build
Release
Deploy流水线。
第四层
理解整个工程链路：
text
Git
↓
GitHub Actions
↓
Docker
↓
Registry
↓
Cloud
↓
Production当你真正理解这一条链路后，再看 GitHub Actions 的 YAML 文件，会发现它们不再是一堆神秘配置，而只是把软件从开发机运送到生产环境的"流水线说明书"。