Question

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

在完成上述所有工作后，我将完成我的管道并对此感到高兴。

现在回到Serverless，我已经将我的API端点作为lambda函数部署到AWS，而这是目前唯一存在的环境（让他们说DEV）。

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

那里的所有解决方案都没有建议（也许我错过了一些）推广实际的代码，这些代码在dev env上进行了尝试和测试。而是部署一组新代码，这是一个限制吗？

Answer 1

选项1

假设您正在开发无服务器无应用程序，使用相同的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的问题是你必须多次执行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注入您的Lambdas。

用于无服务器应用程序的部署（CI-CD）管道

1 个答案: