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

2019年7月28日 194次阅读

我创建了一个简单的节点表达MongoDB应用程序,它有3个API端点来执行基本的crud操作.

如果我将此部署到Heroku作为服务并使用bitbucket-pipeline来执行CI-CD,这将为我完成这项工作.除此之外,我可以让Heroku管道拥有多个阶段的环境,如开发和生产.

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

现在回到无服务器,我已经将我的API端点作为lambda函数部署到AWS,而这是目前唯一存在的环境(让我们说DEV).

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

那里的所有解决方案都没有暗示(也许我错过了一些)推广实际的代码,这些代码在dev env上进行了尝试和测试.而是部署一组新代码,这是一个限制吗？

最佳答案 选项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中.

点赞