AWS CI/CD 实战系列 01:S3 触发 vs CodeCommit 触发 —— 两种 CI/CD 架构怎么选?

系列导读: 本文是《AWS CI/CD 实战:从入门到避坑》系列的第一篇。我们将从架构总览开始,对比两种 CI/CD 触发模式,带你了解 AWS CodePipeline、CodeBuild、CodeDeploy 的协作关系。后续文章将手把手教你搭建完整流水线。


故事背景

2024 年初,AWS 一度宣布取消 CodeCommit 对 CI/CD 流水线的原生触发支持。当时很多团队不得不把代码仓库迁移到 GitHub 或 CodeCommit 之外。但在开发者社区的强烈反馈下,AWS 后来重新恢复了 CodeCommit 的触发能力,并且还增强了与 CodePipeline 的集成。

这意味着现在你同时拥有两种选择

  • 方式一: 通过 S3 上传 artifact 触发构建部署(S3 → Build → Deploy)

  • 方式二: 通过 CodeCommit 代码提交触发构建部署(Commit → Build → Deploy)

两种方式各有优劣,适合不同的场景。本文将帮你理清架构、对比差异、做出选择。


核心组件介绍

CodePipeline

官方定义: AWS CodePipeline 是一项持续交付服务,可用于对发布软件所需的步骤进行建模、可视化和自动化。

简单来说,CodePipeline 就是流水线的编排引擎,它定义了整个 CI/CD 过程的阶段(Stage)和动作(Action)。

一个典型的 CodePipeline 包含:

阶段

动作

说明

Source

代码源

获取代码(S3、CodeCommit、GitHub 等)

Build

构建

调用 CodeBuild 编译代码、运行测试

Deploy

部署

调用 CodeDeploy 部署到目标环境

CodeBuild

官方定义: AWS CodeBuild 是云端完全托管的构建服务。编译源代码、运行单元测试、生成随时可部署的构件。

CodeBuild 负责"干苦力":

  • 编译代码(支持 Go、Python、Java 等 20+ 语言)

  • 运行测试

  • 打包生成可执行文件或 artifact

CodeDeploy

官方定义: CodeDeploy 是一项部署服务,可自动将应用程序部署到 Amazon EC2 实例、本地实例、无服务器 Lambda 函数或 Amazon ECS 服务。

CodeDeploy 负责"最后一公里":

  • 将构建产物部署到目标服务器

  • 支持多种部署策略(就地部署、蓝绿部署、金丝雀等)

  • 出错时自动回滚


方式一:S3 触发模式(S3 → Build → Deploy)

架构图

S3 触发模式架构图

工作流程

  1. 开发者 在本地编译好二进制文件(如 mfmsapp

  2. 上传 到 Amazon S3 指定的 artifact 桶

  3. S3 触发 CodePipeline(通过 S3 事件通知)

  4. CodePipeline 调用 CodeBuild 构建/验证

  5. CodePipeline 调用 CodeDeploy 部署到 EC2 实例

适用场景

场景

说明

第三方仓库迁移

代码在 Bitbucket/GitLab,不想接 webhook

跨团队交付

编译好的二进制文件直接交付,不需要在云上重新构建

手动发布流程

需要审批流程,确认后再上传部署

遗留系统改造

老项目没有 CI/CD,通过手动上传 artifact 过渡

优缺点

✅ 优点:

  • 灵活,代码仓库不限

  • 可以脱离 Git 工作流

  • 适合二进制文件交付的团队

❌ 缺点:

  • S3 事件可能重复触发(需要幂等处理)

  • 没有 Pull Request 触发机制

  • 权限配置复杂(S3 bucket policy + IAM + 事件通知)


方式二:CodeCommit 触发模式(Commit → Build → Deploy)

架构图

CodeCommit 触发模式架构图

工作流程

  1. 开发者 本地修改代码,git commitgit push 到 CodeCommit

  2. CodeCommit 检测到新提交(通过 EventBridge / CloudWatch Events 触发)

  3. CodePipeline 自动拉取代码,调用 CodeBuild 构建

  4. CodeBuild 输出 artifact 到 S3(中间产物)

  5. CodePipeline 调用 CodeDeploy 部署到 EC2 实例

适用场景

场景

说明

原生 AWS 生态

代码已经在 AWS,享受完整的 AWS 集成

自动化发布

每次 push 自动触发构建和部署

团队协作

利用 CodeCommit 的 Pull Request 功能

审计需求

完整的代码变更追踪,符合合规要求

优缺点

✅ 优点:

  • AWS 原生集成,权限统一管理(IAM)

  • 自动触发,零人工干预

  • 支持分支策略(main 自动部署,develop 只构建)

  • 与 EventBridge / CloudWatch Events 深度集成

❌ 缺点:

  • Webhook 触发可能有延迟(通常几秒到几十秒)

  • 跨账号访问 CodeCommit 需要额外配置

  • 历史遗留项目迁移成本高


两种模式对比

对比维度

S3 触发

CodeCommit 触发

代码源

S3 桶(手动上传)

CodeCommit Git 仓库

触发方式

S3 事件通知

EventBridge / CloudWatch Events

构建方式

需要预编译或二次构建

从源码全自动构建

权限管理

S3 bucket policy + IAM

纯 IAM 管理

适用仓库

任意(不限 Git 平台)

CodeCommit / GitHub / Bitbucket

自动化程度

⭐⭐(需要手动上传)

⭐⭐⭐⭐⭐(全自动)

配置复杂度

⭐⭐⭐(中等,S3 事件配置繁琐)

⭐⭐(简单,原生集成)

适合团队

跨团队交付 / 手动审批流程

开发团队 / 全自动 CI/CD

回滚支持

✅(CodeDeploy 自带)

✅(CodeDeploy 自带)


实战案例:mfmsapp 现代化农场管理系统

为了让大家更直观地理解,本系列将使用一个真实案例贯穿始终:

背景: 某农业科技公司(以下简称"XX农业公司")正在开发一个现代化农场管理系统——mfmsapp(Modern Farm Management System App)。该系统用于管理农场的作物信息、库存、灌溉计划等核心业务。

技术栈: Go 语言,编译后为单个二进制文件,./mfmsapp 即可运行。

部署环境: Amazon EC2 实例(Amazon Linux 2023)

版本规划: 系统经历了 v1、v2、v3 三个大版本的演进。本系列将完整演示如何用两种 CI/CD 模式部署这三个版本。


本系列文章导航

篇数

标题

核心内容

01

架构总览:S3 触发 vs CodeCommit 触发

✅ 你正在看这篇

02

S3 触发模式:从零搭建 CI/CD

S3 事件 → CodePipeline → CodeBuild → CodeDeploy

03

S3 模式避坑指南

权限配置、事件重复、artifact 路径

04

CodeCommit 触发模式:从零搭建 CI/CD

EventBridge → CodePipeline → Build → Deploy

05

CodeCommit 模式避坑指南

Webhook 延迟、缓存配置、多分支策略

06

mfmsapp 版本演进实战(v1→v2→v3)

三个版本的代码差异和部署升级

07

权限安全深度解析

IAM 最小权限、KMS 加密、VPC 构建

08

监控与故障排查

CloudWatch 日志、SNS 告警、手动重试

09

进阶:多环境 + 跨区域部署

蓝绿部署、参数管理、并行构建


本文小结

  1. CodePipeline 编排、CodeBuild 构建、CodeDeploy 部署 —— 三剑客协同工作

  2. S3 触发 适合手动流程 / 跨团队交付;CodeCommit 触发 适合开发团队 / 自动化 CI/CD

  3. 两种方式各有优缺点,没有"好坏"之分,只有"适合"与"不适合"

  4. 本系列将以 mfmsapp 为真实案例,手把手教你搭建完整的 AWS CI/CD 流水线


下一篇预告

第 02 篇:S3 触发模式:从零搭建 CI/CD

下一篇,我们将从零开始搭建 S3 触发模式的完整 CI/CD 流水线,包括:

  • 创建 S3 artifact 桶

  • 配置 S3 事件通知

  • 编写 buildspec.yml

  • 编写 appspec.yml

  • 配置 IAM 权限(最小权限原则)

  • 验证部署是否成功


📖 本文引用的官方文档:


本文档内容基于 2026 年 4 月 AWS 官方文档整理。AWS 服务可能随时更新,如遇差异请以 AWS 官方文档 为准。