AWS Lambda - 在 CI/CD 管道中版本控制和提升 lambda 的最佳实践是什么答案

【问题标题】：AWS Lambda - What is a best practice for versioning and promoting lambdas in CI/CD pipelineAWS Lambda - 在 CI/CD 管道中版本控制和提升 lambda 的最佳实践是什么
【发布时间】：2021-01-15 01:54:54
【问题描述】：

我是 AWS Lambdas 的新手，想了解对 lambdas 进行版本控制并将其推广到 CI/CD 管道中更高环境的最佳实践。

作为一个例子，我们假设如下：

我有 3 个环境：dev / ci / prod
我在一个 Git 存储库中有多个 lambda（它们共享一些通用代码）

我看到的过程如下：

共享代码将被打包在单独的层中
每个 lambda 都将单独打包，并重复使用共享层

现在，回到 CI 过程，我需要一些方法来区分一组 lambdas/layers 和一个 env。到另一个。

我的第一个假设是为此目的使用标签：

"Environment=Dev"
"Environment=CI"
"Environment=Prod"

标签可以区分在不同环境中使用的相同 lambda。不幸的是，如果我是正确的，没有办法让多个 lambdas 具有相同的名称（即使标签不同）？

下一个想法是根据环境保留不同名称的 lambda 函数。例如：

mylambda-dev-<DEV_NAME>-<SPECIFIC_BRANCH_NAME> # where <DEV_NAME> is used to differentiate between dev env. for multiple developers
mylambda-ci-<INTEGRATION_BRANCH_NAME>
mylambda-prod

在开发过程中，开发人员将运行 CI 作业，该作业将创建/更新 mylambda-dev-<DEV_NAME>-<SPECIFIC_BRANCH_NAME>
当它处于良好的集成状态时（并且代码合并到集成分支），将有一个 CI 作业将创建/更新mylambda-ci-<INTEGRATION_BRANCH_NAME>
最后，当我们准备好在生产中发布时，会有一个 CI 作业创建具有特定版本 (1、2、3....) 的 mylambda-prod，以使已发布的 lambda 不可变。此外，将创建一个别名以指向生产中的特定版本。此别名会将数字版本映射为对项目更有意义的内容，例如：<PROJECT_NAME>_v1.0.0

同样的过程也适用于层。

这些是我对这个话题的初步想法。任何有助于找到涵盖该主题的最佳实践的帮助/指导/经验都会很棒。

谢谢。

【问题讨论】：

标签： amazon-web-services aws-lambda continuous-integration continuous-delivery

【解决方案1】：

我们对 Lambda 推广的关注是

每个 lambda 都有 -{{ environment }} 例如 my-lambda-dev, my-lambda-stage, my-lambda-prod
每个 lambda 都有 'Smoke' 和 'Live' 别名。

当我们执行 CI/CD 工作时，请按照以下步骤操作

在环境列表上循环（例如 dev-> stage -> prod）

2.1 在当前工作环境（如 5.1.0）上备份“Live”版本的绿色构建

2.2 部署到当前工作环境仅使用“Smoke”别名

2.3 对“Smoke”别名执行测试用例

2.4 如果测试用例全部通过，应用到Live alias，然后继续循环（意思是继续提升到更高的环境）

2.5 如果有任何失败，请回滚到在当前环境及以下环境中备份为 2.1 的版本。然后打破循环

注意：确保所有源事件，使用 Live 版本，而不是 Smoke 版本。

谢谢，

【讨论】：