AWS codeBuild/codePipeline with serverless framework

Question

我正在为我的应用程序自动执行Deployment Pipeline。这里是自动化架构，我想出了：

正如你所看到的，我使用codePipeline和codeBuild自动化部署我。我的后端基于Serverless Framework，它在发射sls deploy命令时部署了lambda函数。这是原因，我没有用codeDeploy来做传统的部署。 buildspec.yml文件看起来像这样：

version: 0.1 

phases: 
    install: 
    commands: 
     – apt-get -y update 
     – npm install -g serverless@1.9.0 
    build: 
    commands: 
     – cd nj2jp/serverless && npm install 
    post_build: 
    commands: 
     – serverless deploy –verbose 

artifacts: 
    files: 
    – serverless.yml 
    discard-paths: yes 

现在，我有3方面问题到CodeBuild和无服务器：

问题1：上的文件的命令sls deploy取决于称为config.yml其中包含诸如db密码之类的秘密。这个文件不会被检入到git中。你认为在codeBuild中包含config.yml的最佳方法是什么？

问题2：回滚可以用AWS做，如果我们不得不使用部署codeDeploy传统的EC2应用程序。在无服务器的情况下，我们不使用codeDeploy和无服务器也支持回滚功能。我们如何利用代码管道内的无服务器回滚？

问题3：当发生合并请求时触发代码管线。我看到一些帖子说，CodePipeline不支持它。但那些帖子是从去年开始的，现在是否支持code Pullline支持请求？

哈克答案（不正确的，但作品需要从你更好的答案。）

答1：的config.yml文件可以保存在私人S3桶，可以拉到codeBuild作为pre-build setup的一部分或者我们可以将所有秘密添加到codeBuild的Env变量中。我不喜欢第二种选择，因为我想在所有环境中保持一致。这个问题有什么更好的解决方案

回答2：我想不出这个问题。寻找你的答案。

答3：我所有使用[APIGateway + Lambda + S3]一些博客文章来触发codePipeline为引入请求。但我觉得，这个功能必须作为一个开箱即用的功能来提供。有关此功能的codePipeline有更新吗？

Answer 1

问题1

如果要坚持你的config.yml，那么只能让它的工作方式是通过类似于你已经在做的事情，因为它不是版本控制的黑客。

我所建议的是让你的环境变量存储在EC2参数存储器中，你可以在CodeBuild buildspec.yml中引用它。您的serverless.yml使用${env:VARIABLE_NAME}可访问这些变量。

对于本地开发，您还应该使用真实的环境变量与将其存储在config.yml中。诸如direnv之类的工具在这方面非常出色。

问题2

您可以通过重新运行以前CodeBuild工作做手工回滚。我想不出一种像CodeDeploy所做的那样自动完成的简单方法。也许一个Lambda函数可以进行部署后测试，如果失败，它可以触发重新运行以前的CodeBuild作业。

问题3

CodePipelines被束缚在单一分支，从而使其在PR分支工作，你必须做像你提到的文章黑客。我已转向使用API网关 + LAMBDA + CodeBuild（无CodePipeline）来做到这一点。