CI/CD前世今生（持续集成、持续交付、持续部署、Jenkins、Github Actions）

从手工作坊到软件工厂：CI/CD 的诞生

远古时代（2000年前后）

当时开发流程大概是：

开发A ↓ 开发B ↓ 开发C ↓ 手动上传服务器 ↓ 线上炸了

典型情况：

scpapp.jar server:/opt/app

或者：

ftpupload

然后：

sshserver ./restart.sh

问题：

每个人环境不同

A电脑：

Java 8

B电脑：

Java 11

结果：

我这里能运行 你那里为什么报错？

合并后才发现冲突

开发A：

defpay():

开发B：

defpayment():

上线前才发现：

Merge Conflict

发布依赖人工

运维：

今天晚上11点发布

然后所有人等待：

别动代码！

整个公司进入戒严状态。

第一次革命：持续集成（CI）

Martin Fowler 提出了一个理念：

不要等一个月再合并代码。

应该：

每天合并 甚至每小时合并

于是出现：

Continuous Integration

持续集成

流程：

提交代码 ↓ 自动构建 ↓ 自动测试 ↓ 发现问题

而不是：

提交代码 ↓ 一个月后 ↓ 项目炸掉

CI 的核心哲学

不是：

自动运行脚本

而是：

尽可能早发现问题

英文里有个说法：

Shift Left

把问题往左移动。

时间线：

开发 → 测试 → 上线

改成：

编码时 → 发现问题

因为：

越晚发现问题 修复成本越高

Jenkins 时代

大约 2010 年前后。

出现了：

Jenkins

它几乎统治了 CI 世界十几年。

当时流程：

Git Push ↓ Jenkins ↓ 编译 ↓ 测试 ↓ 发送邮件

Jenkins 本质：

自动化任务调度器

例如：

Build Test Deploy

串起来。

为什么 Jenkins 后来被嫌弃？

因为太重。

需要：

自己买服务器 自己维护 自己升级 自己装插件

最后：

维护 Jenkins 的成本 比维护业务系统还高

很多公司都有：

Jenkins 专家

专门修 Jenkins。

第二次革命：CI 即代码

后来大家发现：

流程配置 也是代码

于是出现：

Pipeline as Code

例如：

build:test:deploy:

写进仓库。

这样：

代码 + 流程

一起版本管理。

GitHub Actions 的出现

2019年以后。

GitHub Actions

把 CI 彻底平民化。

以前：

GitHub + Jenkins

现在：

GitHub + GitHub Actions

一步到位。

Actions 本质是什么

很多人以为：

GitHub 帮我运行代码

其实不是。

本质：

GitHub 提供临时服务器

当你：

gitpush

时。

GitHub：

创建一个全新的虚拟机

例如：

runs-on:ubuntu-latest

就是：

启动 Ubuntu

然后：

-checkout-install-test

一步步执行。

执行完：

虚拟机销毁

你看到的 Workflow 到底是什么

例如：

name:CIon:push:jobs:test:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-run:npm install-run:npm test

翻译成人话：

有人 Push ↓ 开一台临时 Ubuntu ↓ 下载代码 ↓ 安装依赖 ↓ 执行测试 ↓ 销毁机器

仅此而已。

CI 为什么和 Docker 越来越绑定

因为：

环境不一致

一直是软件工程最大问题之一。

于是出现：

Docker

理念：

把运行环境一起打包

过去：

代码

现在：

代码 + 环境

CI 流程变成：

Push ↓ Test ↓ Build Docker Image ↓ Push Registry

（Push Registry 是将构建好的Docker镜像推送到镜像仓库）

例如：

Docker Hub # Docker官方镜像仓库，最大的公共镜像平台 GHCR # GitHub容器镜像仓库，与GitHub深度集成 ECR # AWS容器镜像仓库，企业级私有仓库服务

第三次革命：持续交付（CD）

大家后来发现：

CI 只能发现问题。

但：

上线还是人工

于是：

Continuous Delivery

持续交付

流程：

Push ↓ Test ↓ Build ↓ 生成可发布版本

到这里结束。

是否上线：

人工点击

第四次革命：持续部署（CD）

进一步：

Continuous Deployment

流程：

Push ↓ Test ↓ Build ↓ Deploy

完全自动。

例如：

Push main

↓

Actions

↓

Docker Build

↓

Deploy AWS

↓

线上更新

无需人工。

现代互联网公司的流水线

今天的大厂基本都是：

Developer ↓ Git Push ↓ CI ↓ Unit Test ↓ Lint ↓ Security Scan ↓ Build Image ↓ Push Registry ↓ Deploy Staging ↓ E2E Test ↓ Deploy Production

AI Coding 时代为什么更需要 CI/CD

以前：

程序员每天写100行代码

现在：

Claude Code 一天改5000行

问题变成：

代码增长速度 远超人工审查速度

所以很多团队反而更依赖：

• CI
• 自动测试
• 自动检查
• 自动部署

因为：

人工 Review 已经无法验证所有改动。

作为 AI 工程师，你应该掌握什么

不需要成为 DevOps 专家。

但至少要理解：

第一层

能看懂：

.github/workflows/*.yml

第二层

知道：

Trigger # 触发条件，启动工作流的事件或条件 Job # 作业任务，工作流中独立的执行单元 Step # 执行步骤，作业中具体的单个操作 Runner # 运行器，执行作业的计算资源或代理 Artifact # 构建产物，作业生成的输出文件或资源 Cache # 缓存机制，存储临时数据以加速后续执行

是什么意思。

第三层

能自己写：

测试 Docker Build Release Deploy

流水线。

第四层

理解整个工程链路：

Git ↓ GitHub Actions ↓ Docker ↓ Registry ↓ Cloud ↓ Production

当你真正理解这一条链路后，再看 GitHub Actions 的 YAML 文件，会发现它们不再是一堆神秘配置，而只是把软件从开发机运送到生产环境的“流水线说明书”。