如何使用 aws codepipeline 和 cloudformation 在 github 中仅部署更改的 lambda 函数？

Question

我正在使用 CodePipeline 将包含 Lambda 函数的 CloudFormation 模板部署为 AWS::SAM::Functions。

CodePipeline 由我在 GitHub 上的主分支中的提交触发。

CodePipeline 中的 Source Stage 从 GitHub 检索源文件。零个或多个 Lambda 函数可能会在提交中发生变化。此存储库中有几个 Lambda 函数。

我打算在测试阶段通过 taskcat 运行 CloudFormation 模板和 Lambda Python 代码的单元测试，然后将 CloudFormation 模板和 Lambda 函数部署到生产环境。问题是，我不知道如何区分已更改和未更改的 Lambda 函数或自动部署这些 Lambda 函数。

我只想测试和部署新的或更新更改的 Lambda 函数以及我的 CloudFormation 模板 - 对此的最佳做法是什么（最好没有 Terraform 或黑客）？

Answer 1

关于测试：最佳实践实际上是在部署之前简单地测试 repo 中的所有 lambda 代码。您可能会跳过一些工作，例如仅测试已更改文件的 github 操作，但这肯定需要一些脚本，而且几乎不会增加太多价值。每个测试工具都有自己的处理方式（有时您可以简单地将要测试的文件作为参数传递，然后很容易，但有时测试工具更像是一种全有或全无的方法，它变得非常复杂快）。

另外，我个人不是 taskcat 的忠实粉丝，因为它并没有真正增加很多价值，而且它不是一个非常直观的工具（也是相对过时的 IMO）。您是否有理由需要进行这些类型的测试？

关于部署：尝试仅更新已更改的 lambda 时有一些注意事项。

首先，cloudformation 已经自动执行此操作：只要 lambda 的 cloudformation 资源不改变，lambda 就不会更新。

但是，SAM 有一个小问题，因为它会在每次管道运行时重新打包 lambda 代码并更新 lambda 的 CodeUri 属性。因此 lambda 得到更新（即使代码可能保持不变）。

要解决此问题，您有多种选择：

1. 只需接受 SAM 更新您的函数，即使代码可能没有更改。
2. 在本地构建 SAM，并在您的管道中部署时使用 --cached 和 --cache-dir 选项。确保推送您设置为缓存目录的文件夹。
3. 使用与 SAM 不同的文件打包工具。一些自定义脚本或其他仅在文件更改时将您的代码推送到 s3 的脚本。

如果你喜欢编程，我建议你看看 CDK。这是 cloudformation/SAM 的重大升级，它更好地处理代码捆绑（仅在文件更改时更新）。 CDK 的测试选项也更广泛。