我创建了一个简单的 node express MongoDB 应用程序，它有 3 个 API 端点来执行基本的 crud 操作。 如果我将其作为服务部署到 Heroku 并使用 bitbucket-pipeline 执行 CI-CD，这将为我完成这项工作。最重要的是，我可以让 Heroku 管道拥有多个阶段的环境，例如开发和生产。
在完成上述所有操作后，我的管道就完成了，并且对此感到高兴。
现在回到无服务器，我已将我的 API 端点作为 lambda 函数部署到 AWS，这是目前唯一的环境（比如说 DEV）。
现在如何在无服务器架构中实现类似于前面提到的管道？
那里的所有解决方案都不建议（也许我错过了一些）将在开发环境中尝试和测试的实际代码推广到生产环境。而是部署一组新代码，这是一个限制吗？
【问题讨论】：
标签： deployment continuous-integration release-management serverless-framework serverless-architecture
选项 1
假设您正在开发 Node Serverless 应用程序，部署一组具有相同 git 提交 ID 和 package-lock.json/yarn.lock 的新代码应该会产生相同的环境。这可以通过对不同阶段执行多个部署命令来实现，例如
sls deploy -s dev
sls deploy -s prod
有多种因素可能导致部署的环境不同，但这种风险应该非常低。这是您可以实施的最简单的 CI/CD 解决方案。
选项 2
如果您想不惜一切代价避免选项 1 带来的风险，您可以在管道中拆分包和部署阶段。在从已签出的代码库部署之前创建包：
sls package -s dev --package build/dev
sls package -s prod --package build/prod
根据需要存档，然后进行部署：
sls deploy -s dev --package build/dev
sls deploy -s prod --package build/prod
选项 3
这是选项 2 的改进版本。我没有尝试过这个解决方案，但它应该 theoretically be possible。 选项 2 的问题是您必须多次执行打包命令，这可能不可取 YMMV。为避免多次打包，请先创建包：
sls package -s dev --package build
然后部署：
# Execute a script to modify build/cloudformation-template-update-stack.json to match dev environment
sls deploy -s dev --package build
# Execute a script to modify build/cloudformation-template-update-stack.json to match prod environment
sls deploy -s prod --package build
如果您在build/cloudformation-template-update-stack.json 中有以下资源，例如：
"MyBucket": {
"Type": "AWS::S3::Bucket",
"Properties": {
"BucketName": "myapp-dev-bucket"
}
},
你在sls deploy之前执行的脚本结果应该将CF资源修改为：
"MyBucket": {
"Type": "AWS::S3::Bucket",
"Properties": {
"BucketName": "myapp-prod-bucket"
}
},
这个选项当然意味着您的应用程序中不能有任何硬编码的资源名称，每个资源名称都必须从 serverless.yml 注入到您的 Lambda 中。
【讨论】：