手动scp扛不住了：小团队用AWS三件套把Flask部署自动化跑通

前阵子我手上有个 Flask 项目要上生产，团队就五六个人，但发布频率不低，手动 scp 加重启已经扛不住了。我花了一周时间在 AWS 上把 CodePipeline、CodeBuild、CodeDeploy 三件套串起来，中间踩了几个坑，但跑通之后确实省心。这里把整个搭建思路和我实际的做法记下来，供你参考。

三个服务各自干什么

先说清楚分工，免得后面看流程时混淆。

• **CodePipeline**：全托管的持续交付编排器。你定义好"源码 → 构建 → 测试 → 部署"这条链路，它负责按顺序驱动每一步。除了原生 AWS 服务，它也接 GitHub、Bitbucket 这些第三方代码源。
• **CodeBuild**：全托管的持续集成。你给它一个构建脚本，它帮你拉代码、跑编译、跑测试、产出 artifact。不用自己维护构建机。
• **CodeDeploy**：自动化部署执行器。它把上一步产出的软件包推到你指定的目标上——Amazon EC2、AWS Fargate、AWS Lambda 都支持。

我的判断是：这三者拆开用价值有限，真正好用是因为 CodePipeline 把它们编排成了一条流水线，你只需要在控制台（或 CloudFormation）里声明阶段，剩下的它替你调度。

我实际怎么串起来的

我的流水线分四个阶段，对应关系很简单：

• 源码阶段：从代码仓库拉取变更，触发流水线。
• 构建阶段：交给 CodeBuild。我配置了一个 CodeBuild 项目，buildspec 里写好了 `pip install -r requirements.txt` 加上 pytest 那套。CodeBuild 自动拉源码、执行脚本、把产物打成 tar 包。
• 测试阶段：和构建合在同一个 CodeBuild 项目里跑，没单独拆。
• 部署阶段：CodePipeline 检测到构建产物就绪后，自动触发 CodeDeploy，把包推到目标 EC2 实例上。

这里我踩过一次坑：第一次部署上去 Flask 没起来，后来排查发现是 `requirements.txt` 在 CodeDeploy 的解压目录里路径不对，导致 `pip install` 装到了错误的 Python 环境。解决办法是在 `appspec.yml` 的生命周期事件（`AfterInstall` 和 `ApplicationStart`）里写清楚工作目录和启动命令，之后就没再出过这个问题。

审批环节：我为什么加、怎么加

纯自动化听起来很爽，但生产环境我始终觉得"人看一眼"不能省。所以在构建和部署之间我插了一个审批动作：

• 在 CodePipeline 里加一个 Approval 类型的 action，指向一个 SNS topic。
• 每次流水线走到这一步，指定的审批者会收到 Amazon SNS 的通知邮件，里面有变更摘要和流水线详情链接。
• 审批者点"批准"，流水线继续往下走，CodeDeploy 开始部署；点"拒绝"，流水线直接停住，等团队排查或回滚代码。

我实测下来，这个环节对合规审计特别有用——每次部署都有明确的"谁批的、什么时候批的"记录，不用事后翻日志。

跑通之后的感受

整套东西跑稳之后，从 git push 到生产环境更新，中间不需要人手动介入（除了审批那一下）。交付周期确实缩短了，而且因为每次构建都走同一套脚本，环境漂移的问题基本消失。AWS 这套 DevOps 工具链给我的感觉是：单看每个服务都"够用"，但编排起来之后才真正形成闭环，敏捷性和可控性同时在线。

References

• 统一DevOps流程：供应商协作的关键
• 实现 GitLab 与 AWS CodeCommit 的流畅集成
• 探索DevOps之旅：自动化运维、治理与运营的协调融合