4

我创建了一个简单的 node express MongoDB 应用程序，它有 3 个 API 端点来执行基本的 crud 操作。如果我将其作为服务部署到 Heroku 并使用 bitbucket-pipeline 执行 CI-CD，这将为我完成这项工作。最重要的是，我可以让 Heroku 管道拥有多个阶段的环境，例如开发和生产。

在完成上述所有操作后，我的管道就完成了，并为此感到高兴。

现在回到无服务器，我已经将我的 API 端点作为 lambda 函数部署到 AWS，这是目前唯一的环境（比如说 DEV）。

现在如何在无服务器架构中实现类似于前面提到的管道？

那里的所有解决方案都没有建议（也许我错过了一些）将在开发环境中尝试和测试的实际代码推广到生产环境。而是部署一组新代码，这是一个限制吗？

4

1 回答 1

1

选项1

假设您正在开发 Node Serverless 应用程序，部署一组具有相同 git commit 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 的改进版本。我没有尝试过这个解决方案，但理论上应该是可行的。选项 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 注入到您的 Lambda 中。

于 2018-05-22T21:37:26.827 回答