我创建了一个简单的 node express MongoDB 应用程序,它有 3 个 API 端点来执行基本的 crud 操作。
如果我将其作为服务部署到 Heroku 并使用 bitbucket-pipeline 执行 CI-CD,这将为我完成这项工作。最重要的是,我可以让 Heroku 管道拥有多个阶段的环境,例如开发和生产。
在完成上述所有操作后,我的管道就完成了,并为此感到高兴。
现在回到无服务器,我已经将我的 API 端点作为 lambda 函数部署到 AWS,这是目前唯一的环境(比如说 DEV)。
现在如何在无服务器架构中实现类似于前面提到的管道?
那里的所有解决方案都没有建议(也许我错过了一些)将在开发环境中尝试和测试的实际代码推广到生产环境。而是部署一组新代码,这是一个限制吗?
最佳答案
选项 1
假设您正在开发 Node Serverless 应用程序,部署一组具有相同 git commit ID 和 package-lock.json/yarn.lock 的新代码应该会产生相同的环境。这可以通过对不同阶段执行多个部署命令来实现,例如
sls deploy -s dev
sls deploy -s prod
有多种因素可能导致部署的环境不同,但这种风险应该非常低。这是您可以实现的最简单的 CI/CD 解决方案。
选项 2
如果您想不惜一切代价避免选项 1 带来的风险,您可以在管道中拆分包和部署阶段。在从已 checkout 的代码库部署之前创建包:
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 的问题是您必须多次执行 package 命令,这可能不是 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 注入(inject)到您的 Lambda 中。
关于无服务器应用程序的部署 (CI-CD) 管道,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48947073/