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

Question

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

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

CodePipeline 中的源阶段从 GitHub 检索源文件。零个或多个 Lambda 函数可以在提交中更改。此存储库中有多个 Lambda 函数。

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

我只想测试和部署新的或更新更改的 Lambda 函数以及我的 CloudFormation 模板 - 最佳实践是什么(最好没有 Terraform 或 hack)？

Answer 1

关于测试:最佳实践实际上是在部署之前简单地在推送时测试存储库中的所有 lambda 代码。您可能会跳过一些工作，例如使用 github 操作，您只测试已更改的文件，但这肯定需要一些脚本，而且几乎不会增加太多值(value)。每个测试工具都有自己的处理方法(有时您可以简单地将要测试的文件作为参数传递，然后就很容易了，但有时测试工具更像是一种全有或全无的方法，并且变得相当复杂)快)。

另外，我个人并不是taskcat的忠实粉丝，因为它并没有真正增加很多值(value)，而且它不是一个非常直观的工具(在我看来也相对过时)。您需要进行这些类型的测试吗？

关于部署:尝试仅更新已更改的 lambda 时需要考虑一些注意事项。

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

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

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

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

如果您喜欢编程，我建议您了解一下 CDK。它是 cloudformation/SAM 的重大升级，并且可以更好地处理代码捆绑(仅在文件更改时更新)。 CDK 的测试选项也更广泛。