如何通过AWS CodePipeline和CloudFormation仅部署GitHub中变更的Lambda函数

1. 先规范仓库目录结构 #

先对齐目录规范，为后续变更检测提供基础，推荐目录结构如下：

repo-root/
├── template.yaml          # SAM根模板
├── lambdas/
│   ├── function-a/        # 每个Lambda独占独立目录
│   │   ├── src/           # 业务代码
│   │   ├── tests/         # 对应单元测试用例
│   │   └── requirements.txt
│   └── function-b/
│       ├── src/
│       ├── tests/
│       └── requirements.txt
└── taskcat-config.yaml    # taskcat校验配置

所有Lambda的代码、依赖、测试用例都和对应目录绑定，避免跨目录混存。

2. 新增变更检测阶段 #

在CodePipeline的源阶段之后、测试阶段之前，新增一个CodeBuild运行的变更检测步骤：

• 提前将上一次成功部署的提交哈希存储在SSM Parameter Store这类持久化存储中
• 步骤内执行git diff --name-only <上一次成功提交哈希> <本次提交哈希>提取所有变更文件路径
• 遍历所有Lambda的根目录，匹配变更文件所属的Lambda目录，输出变更Lambda列表存入构建产物changed_functions.json
• 如果变更列表为空，直接终止流水线后续步骤，无需执行测试和部署

3. 差异化执行测试任务 #

测试阶段读取上一步输出的changed_functions.json，仅针对变更的Lambda执行对应操作：

• 循环进入每个变更Lambda的目录，执行对应Python单元测试，任意Lambda测试失败直接终止流水线
• 全量执行taskcat CloudFormation模板校验，避免单个Lambda的变更误影响其他资源的模板配置，也可以根据需求仅校验和变更Lambda关联的模板段

4. 利用SAM原生能力实现差异化部署 #

SAM本身已经内置增量部署逻辑，不需要额外开发自定义部署逻辑：

• 执行sam package打包时，SAM会自动为每个Lambda的代码包计算SHA256哈希，未变更的Lambda会直接复用之前上传到S3的代码包，无需重复打包上传
• 执行sam deploy时，CloudFormation会比对模板中Lambda的代码哈希和线上运行版本的哈希，仅哈希发生变化的Lambda会触发更新，未变更的函数不会重新部署

5. 流水线收尾配置 #

部署成功后，更新SSM Parameter Store中存储的上一次成功部署的提交哈希，供下一次流水线运行做变更检测使用。如果需要可追溯，可以把本次变更的Lambda列表、测试结果、部署结果存入CloudWatch Logs留存。

注意事项 #

• 不要修改SAM自动生成的Lambda代码哈希逻辑，避免破坏原生增量部署能力
• 如果SAM模板中把多个Lambda的配置写在同一个嵌套模板里，建议按Lambda维度拆分嵌套模板，方便后续更精准的变更校验
• 单元测试必须和对应Lambda代码绑定存储在同一目录下，避免出现测试用例和业务代码不匹配的问题

内容的提问来源于stack exchange，提问作者Jerezle