7.5 KiB
第28天：CI/CD——代码从提交到上线的自动化流水线
今天你将学到什么
今天学习 CI/CD（持续集成/持续部署）——让代码从开发者提交到最终上线的整个过程自动化。不再需要手动打包、手动上传、手动重启服务器。
为什么需要 CI/CD
没有 CI/CD 的世界
传统的部署流程：
- 开发者写完代码，在本地测试通过
- 把代码打包成压缩文件，通过 FTP 上传到服务器
- SSH 登录服务器，停止旧服务
- 解压新代码，安装依赖
- 启动新服务，祈祷不出问题
- 出问题了？手动回滚到上一个版本
问题：
- 容易出错（手动操作步骤多）
- 速度慢（一次部署可能要半小时）
- 不敢频繁部署（怕出问题）
- 回滚困难（上一个版本在哪？）
- 不同人部署方式不一样（"你是怎么部署的？"）
有 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 模板就像建筑图纸。有了图纸，可以在任何地方建出一模一样的房子。
今天的小测验
- CI 和 CD 分别解决什么问题？
- 蓝绿部署和金丝雀部署各自的优缺点是什么？
- 为什么说"基础设施即代码"很重要？它解决了什么问题？
- CodePipeline、CodeBuild、CodeDeploy 各自的职责是什么？
延伸阅读
明天预告
明天学习 Step Functions——AWS 的工作流编排服务。了解如何把多个 Lambda 函数和服务组合成复杂的业务流程，并处理错误和重试。