<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1919858758278392&amp;ev=PageView&amp;noscript=1">

CI/CD for Serverless Applications on AWS

Nov 6, 2019 10:00:39 AM By Phil Vuollet


A serverless architecture combined with event-driven design can reduce response time and cost. As usage grows, this architecture allows your system to grow and scale with load. Here’s an example of how one person—Mohamed Labouardy (@mlabouardy)—addresses this.

Mohamed uses a Jenkins master with workers in an autoscaling group to deploy the serverless components. His team uses the Gitflow model as they develop AWS Lambda functions.

Screen Shot 2019-11-06 at 9.52.34 AM

Gitflow model from Mohamed Labouardy’s “CI/CD for Serverless Applications” presentation.

The main stages of the serverless development and CI process are the same as what you’d have in a microservices architecture. The difference lies mainly in the details. For example, Mohamed uses Docker in the build step so that he doesn’t have to install dependencies on the Jenkins servers. Of course, you can take advantage of containers in many similar ways.

After the build stage, Mohamed stages artifacts (the built code) on S3 using the Git commit hash as the artifact name. This helps them keep a link between the artifact and the commit. When it’s time to deploy, the AWS Lambda functions are swapped into the environment.

By the way, you don’t have to use a strictly serverless architecture. You can mix and match serverless components with containerized components and even whole subsystems that run on virtual machines such as AWS EC2.

Mohamed demonstrated the whole process from a CI/CD perspective using his IMDB sample. The code for that is available at https://github.com/mlabouardy/alldaydevops-engine-2019.



The IMDB engine demo from Mohamed Labouardy’s “CI/CD for Serverless Applications” presentation.

The Jenkins file includes many of the standard build stages as follows:

  • Checkout
  • Quality test
  • Unit test
  • Security test
  • Build
  • Push
  • Deploy

The actual mechanism for swapping the Lambda lives in the Jenkins deploy stage. The Jenkins stage uses the AWS CLI to update the Lambda alias. Each Lambda can have multiple aliases, typically one for each version. You simply use the specific alias to point to the version you want to run in any environment.


Lambda function from Mohamed Labouardy’s “CI/CD for Serverless Applications” presentation.

With a CI/CD for a serverless architecture, you can push changes to any environment within under two minutes! Of course, results will vary with size and complexity.

This post was written by Phil Vuollet. Phil uses software to automate processes to improve efficiency and repeatability. He writes about topics relevant to technology and business, occasionally gives talks on the same topics, and is a family man who enjoys playing soccer and board games with his children.

Photo by Alfred