As you can see, I am using codePipeline and codeBuild to automate my deployment. My backend is based on Serverless Framework, which deploys lambda functions on firing
sls deploy command. This is the reason, I did not use codeDeploy to do traditional deployment.
buildspec.yml file looks like this:
version: 0.1 phases: install: commands: – apt-get -y update – npm install -g [email protected] build: commands: – cd nj2jp/serverless && npm install post_build: commands: – serverless deploy –verbose artifacts: files: – serverless.yml discard-paths: yes
Now, I have 3 Questions in regards to CodeBuild and Serverless:
Question 1: The command
sls deploy depends on a file called
config.yml which contains secrets such as db password. This file will not be checked into git. What do you think is the best possible way to include
config.yml in codeBuild?
Question 2: Rollbacks can be done with AWS, if we have to deploy traditional EC2 applications using codeDeploy. In case of serverless, we are not using codeDeploy and serverless also supports rollback features. How do we leverage serverless rollback within the codePipeline?
Question 3: Triggering codePipeline when a Pull Request happens. I saw some posts saying, it is not supported by codePipeline. But those posts were from last year, Is Pull Request now supported by codePipeline?
Hack Answers(Not correct, but works. Need better answers from you.)
Answer 1: The
config.yml file can be saved in a private S3 bucket and can be pulled to codeBuild as part of
pre-build setup or We can add all secrets to codeBuild's Env variables. I dont like the second option, as I want to have consistent across all environments. Any better solutions for this problem?
Answer 2: I cannot think of an hack for this. Looking out for answers from you.
Answer 3: I came across some blog posts that use [APIGateway + Lambda + S3] to trigger codePipeline for pull requests. But I feel, this feature has to be provided as an out-of-box one. Is there any updates on the codePipeline for this feature?amazon-web-servicesaws-lambdaserverless-frameworkaws-codepipelineaws-codebuild
If you want to stick with your
config.yml, then the only way to make it work is through hacks similar to what you are already doing since it is not version-controlled.
What I'd suggest is to have your environment variables stored in EC2 Parameter Store which you can reference in your CodeBuild
buildspec.yml. These variables are accessible in your
For local development, you should also use real environment variables versus storing them in
config.yml. Tools such as direnv are great at this.
You can do manual rollbacks by re-running the previous CodeBuild job. I can't think of an easy way to do it automatically like what CodeDeploy does. Maybe a Lambda function can do a post-deploy test and if it fails, it can trigger re-running the previous CodeBuild job.
CodePipelines are tied to a single branch so to make it work on PR branches, you have to do hacks like the article you mentioned. I have resorted to using API Gateway + Lambda + CodeBuild (No CodePipeline) to do this.