# 第28天：CI/CD——代码从提交到上线的自动化流水线

## 今天你将学到什么

今天学习 CI/CD（持续集成/持续部署）——让代码从开发者提交到最终上线的整个过程自动化。不再需要手动打包、手动上传、手动重启服务器。

---

## 为什么需要 CI/CD

### 没有 CI/CD 的世界

传统的部署流程：

1. 开发者写完代码，在本地测试通过
2. 把代码打包成压缩文件，通过 FTP 上传到服务器
3. SSH 登录服务器，停止旧服务
4. 解压新代码，安装依赖
5. 启动新服务，祈祷不出问题
6. 出问题了？手动回滚到上一个版本

**问题**：
- 容易出错（手动操作步骤多）
- 速度慢（一次部署可能要半小时）
- 不敢频繁部署（怕出问题）
- 回滚困难（上一个版本在哪？）
- 不同人部署方式不一样（"你是怎么部署的？"）

### 有 CI/CD 的世界

```
开发者提交代码 → 自动测试 → 自动构建 → 自动部署 → 上线完成
```

整个过程自动化、可重复、可追溯。出问题一键回滚。

**类比**：CI/CD 就像工厂的自动化生产线。原材料（代码）放上去，经过一道道自动化工序（测试、构建、部署），最终产出成品（上线的应用）。不需要工人在每个环节手动操作。

---

## CI 和 CD 分别是什么

### CI（Continuous Integration）持续集成

**核心思想**：开发者频繁地把代码合并到主分支，每次合并都自动运行测试。

```
开发者提交代码
    ↓
自动拉取代码
    ↓
自动运行测试（单元测试、集成测试）
    ↓
测试通过？
  ├── 是 → 代码合并成功 ✓
  └── 否 → 通知开发者修复 ✗
```

**好处**：
- 问题早发现（提交后几分钟就知道有没有 bug）
- 避免"集成地狱"（多人同时开发，最后合并时冲突一堆）

### CD（Continuous Delivery / Deployment）持续交付/部署

**持续交付**：代码随时可以部署到生产环境（但需要人工点击"部署"按钮）。

**持续部署**：代码通过所有测试后自动部署到生产环境（全自动，无需人工干预）。

```
CI 通过
  ↓
自动构建（打包、生成镜像）
  ↓
自动部署到测试环境
  ↓
自动运行集成测试
  ↓
部署到生产环境（自动或手动审批）
```

---

## AWS 的 CI/CD 服务

AWS 提供了一套完整的 CI/CD 工具链：

| 服务 | 作用 | 类比 |
|------|------|------|
| CodeCommit | 代码仓库 | 类似 GitHub（存放代码） |
| CodeBuild | 构建服务 | 编译代码、运行测试、生成产物 |
| CodeDeploy | 部署服务 | 把构建产物部署到服务器 |
| CodePipeline | 流水线编排 | 把上面的步骤串联成自动化流程 |

### CodePipeline——流水线的指挥官

CodePipeline 把各个阶段串联起来：

```
源代码阶段          构建阶段           部署阶段
(CodeCommit/       (CodeBuild)       (CodeDeploy/
 GitHub)                              ECS/Lambda)
    ↓                  ↓                  ↓
代码变更触发 → 编译+测试+打包 → 部署到目标环境
```

你只需要定义流水线的各个阶段，CodePipeline 自动按顺序执行。

### CodeBuild——构建工人

CodeBuild 负责：
- 拉取源代码
- 安装依赖
- 编译代码
- 运行测试
- 生成构建产物（JAR 包、Docker 镜像等）

**特点**：按构建时间付费，不用维护构建服务器。

### CodeDeploy——部署专家

CodeDeploy 支持多种部署策略：

| 策略 | 说明 | 风险 |
|------|------|------|
| 一次性部署 | 所有实例同时更新 | 高（全部失败就全挂） |
| 滚动部署 | 分批更新，每批一部分实例 | 中（部分失败可以停止） |
| 蓝绿部署 | 启动一套新环境，切换流量 | 低（随时可以切回旧环境） |
| 金丝雀部署 | 先给 5% 用户用新版本，没问题再全量 | 最低 |

---

## 一个完整的 CI/CD 流程示例

### 场景：Web 应用部署到 ECS

```
1. 开发者推送代码到 GitHub
       ↓
2. CodePipeline 检测到代码变更，触发流水线
       ↓
3. CodeBuild 阶段：
   - 拉取代码
   - 运行单元测试
   - 构建 Docker 镜像
   - 推送镜像到 ECR
       ↓
4. 部署到测试环境：
   - 更新测试环境的 ECS 服务
   - 运行集成测试
   - 测试通过 ✓
       ↓
5. 人工审批（可选）：
   - 团队负责人确认可以上线
       ↓
6. 部署到生产环境：
   - ECS 滚动更新
   - 新版本容器启动
   - 健康检查通过
   - 旧版本容器停止
       ↓
7. 部署完成，通知团队
```

整个过程从代码提交到上线，可能只需要 10-15 分钟。

---

## 部署策略详解

### 蓝绿部署

```
当前状态：
  用户 → ALB → 蓝色环境（v1.0，正在服务）
              绿色环境（空闲）

部署新版本：
  用户 → ALB → 蓝色环境（v1.0，正在服务）
              绿色环境（v2.0，部署中...）

切换流量：
  用户 → ALB → 绿色环境（v2.0，开始服务）
              蓝色环境（v1.0，待命，随时可以切回）

确认无误后：
  销毁蓝色环境，释放资源
```

**优点**：切换瞬间完成，回滚也是瞬间（切回旧环境）。
**缺点**：需要双倍资源（两套环境同时存在）。

### 金丝雀部署

```
阶段 1：5% 流量到新版本
  用户 → ALB → 95% → v1.0
              → 5%  → v2.0  ← 观察有没有错误

阶段 2：没问题，扩大到 25%
  用户 → ALB → 75% → v1.0
              → 25% → v2.0  ← 继续观察

阶段 3：全量切换
  用户 → ALB → 100% → v2.0 ✓
```

**优点**：风险最小，问题只影响少量用户。
**缺点**：部署时间较长。

---

## 基础设施即代码（IaC）

### 问题：手动创建资源不可重复

你在控制台上点点点创建了一套环境。下次要创建一套一模一样的测试环境，你还记得每个配置项吗？

### 解决方案：用代码定义基础设施

**CloudFormation**：AWS 的 IaC 服务。用 YAML/JSON 文件描述你要创建的所有 AWS 资源。

```
一个 CloudFormation 模板可以定义：
- 1 个 VPC + 子网 + 路由表
- 1 个 ALB
- 1 个 Auto Scaling Group + 启动模板
- 1 个 RDS 数据库
- 所有的安全组和 IAM 角色
```

**好处**：
- 可重复：同一个模板可以创建多套一模一样的环境
- 可版本控制：模板放在 Git 里，变更有记录
- 可审查：基础设施变更和代码变更一样走 Code Review
- 可销毁：一键删除整套环境，不留残余资源

**类比**：CloudFormation 模板就像建筑图纸。有了图纸，可以在任何地方建出一模一样的房子。

---

## 今天的小测验

1. CI 和 CD 分别解决什么问题？
2. 蓝绿部署和金丝雀部署各自的优缺点是什么？
3. 为什么说"基础设施即代码"很重要？它解决了什么问题？
4. CodePipeline、CodeBuild、CodeDeploy 各自的职责是什么？

---

## 延伸阅读

- [CodePipeline 用户指南](https://docs.aws.amazon.com/codepipeline/latest/userguide/)
- [CodeBuild 用户指南](https://docs.aws.amazon.com/codebuild/latest/userguide/)
- [CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/)
- [CloudFormation 用户指南](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)

---

## 明天预告

明天学习 Step Functions——AWS 的工作流编排服务。了解如何把多个 Lambda 函数和服务组合成复杂的业务流程，并处理错误和重试。