CI/CD Pipeline for Serverless Apps using Jenkins and Chalice

Pipeline for Serverless App

This journey started about a year ago, when we started to talk about serverless technologies such as AWS Lambda, API Gateway. We had a plan to move APIs from Docker to Serverless due to the many advantages it gives and possess. From the reduction of cost in usage and execution to the massive reduction in OpEX it gives and the many advantages serverless brings.

These are few of the advantages of serverless brings to the table. But moving to serverless technologies possess a huge challenge for the dev team who have to start learning the principles that govern serverless functions and architecture. The other headache is the deployment model. You do not want to give all your users full access to the AWS Console to deploy functions and you return to so your infrastructure in a beautiful chaos. Automation is a great method that can be used to reduce this chaos. Also help you delivering quality feedback on every deployment. It also gives the ability to run any type of test during the Continuous Integration process even before it gets to deployment.

We will be talking about two of the popular serverless application frameworks; Chalice and Serverless. Chalice is built with python and can be used to write serverless python applications. Chalice is language and platform specific; Python and AWS. Serverless framework on other hand is a direct opposite of this. Serverless supports a set of languages such as NodeJS, Python, Golang, C# and Java. Unlike Chalice, Serverless framework can be used on AWS, Azure and GCP.

Our focus is not in the difference between them and the usage, that could be another conversation but in how they can be used in a deployment pipeline. Both of them have very similar architecture, with our focus basically on the configuration file they come with. Chalice has a JSON structured configuration file while Serverless has a YAML structured configuration file.

Basic Chalice config.json file

Basic Serverless serverless.yml

These are the configurations that determine how the application will run in dev, test and production environments.

In both Chalice and Serverless, the syntax to deploy the applications after development is same. For Chalice chalice deploy while in Serverless Framekwork, serverless deploy .

Infusing this into the deployment pipeline showed is as follows:

1. Code is checked-in on the version control service (Github, Bitbucket, Gitlab, Azure Repos etc)
2. A webhook has been configured in the repo which triggers a Jenkins job that has been initially configured
3. The repo already has a Jenkinsfile written to perform the deployment operation
4. This automatically deploys the Serverless application using the configurations stated in the file.
5. The status of the build is also sent to slack to help with feedback of the status of the build done by Jenkins

Sample Jenkinsfile

The example Jenkinsfile for this was for Chalice; but to use thesame configuration for Serverless, the line for deployment just needs to be updated for serverless. So instead of the chalice deploy on like 35 and 36 we edit it to serverless deploy . Also the --stage parameter signifies staging and production. Yes, it gives you the ability to deploy either from staging or production. We just talked about a basic pipeline deployment.

All Devops principles can be employed in serverless applications and get the best out of them. Both Chalice and Serverless also gives you the ability to test locally before code is checked into version control for continuous integration and continuous delivery. Other operations like monitoring and alert can also be used on serverless applications.