262 lines
7.5 KiB
Markdown
262 lines
7.5 KiB
Markdown
# 第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 函数和服务组合成复杂的业务流程，并处理错误和重试。
|