Workflow for a Continuous Delivery Pipeline for a Lambda Application with AWS CodePipeline
This Blog has been moved from Medium to blogs.tensult.com. All the latest content will be available there. Subscribe to our newsletter to stay updated.
In this blog, I will be providing a workflow on a continuous delivery pipeline for a Lambda Application with AWS CodePipeline.
This blog assumes you have a basic understanding of the AWS Developer tools.
Why Continuous Delivery?
Continuous Delivery is a software engineering approach that automates the entire software release process. Every revision or change in the code that is committed to the repository triggers an automated flow that builds, tests, and then deploys the update.
AWS CodePipeline fits the bill by combining source control, build, and deployment to create a pipeline that runs automatically whenever you make a change to your application’s source code.
CodePipeline makes developers job easy as getting software released to users is often a painful, risky, and time-consuming process and instead helps them concentrate more on the coding part.
Here is a workflow of the continuous deployment which deploys the Lambda application.
CodePipeline is automatically triggered when the code is pushed to the repository. It pulls the files from the repository and stores the artifacts in S3 and triggers a CodeBuild project to convert SAM template to CloudFormation template. The deployment happens via CloudFormation in this workflow and the CloudFormation template has the details of the Lambda function.
At this stage, the CloudFormation template is called to create a CloudFormation change-set with the Lambda function and API Gateway.
We can have an optional approval stage and have the deployment approved before the change-set execution. Once the change-set is executed we can see the Lambda function created in the Lambda console. Any changes pushed to the repository will trigger the pipeline and updates the Lambda function.
You will need a CloudFormation service role which has access to S3, CodePipeline, Lambda, API Gateway, and CloudFormation.
Developers develop their Lambda code and push it to a central repository (AWS CodeCommit). Additional files apart from the Lambda code are needed for this setup. They are template.yaml and buildspec.yml.
Template.yaml or the AWS SAM (Serverless Application Model) template is similar to your CloudFormation template with minor changes and represents the architecture of your serverless application.
A buildspec.yml file is a collection of build commands and related settings like runtime, in YAML format, which is the input to CodeBuild to run a build.
Create a pipeline with the source, build and deploy stages.
For the source provider choose AWS CodeCommit and choose the repository and branch on where you have your code.
For the build stage, choose AWS CodeBuild as the build provider and create a build project for the pipeline by giving the build project a name.
Configure the build project by selecting the suitable parameters, a new service role will be created at this stage.
Note that, though the Buildspec name field is optional you can go ahead and specify your buildspec.yml file name, make sure you give the correct name any mismatch would result in failure at the build stage of your pipeline.
For the deploy stage, choose AWS CloudFormation as the Deploy provider and Action mode as Create or replace a change-set.
The Template field is automatically populated as shown.
Since CloudFormation is the chosen deploy provider a change-set is created in with the stack name already specified.
Execute the change-set for the final deployment of the Lambda function.
Finally, we can see the Lambda function has been created from the CloudFormation Stack in the Lambda console.
I hope this blog has been informative and easy to understand for you. Kindly share your thoughts in the comments section.
