Serverless Development Workflow

Guilherme Waess
Jul 1 · 5 min read

Hello hello,

Recently I’ve started my adventure in the serverless world using AWS and after the fun part of managing connection (database, token validations and so on) and of course test it on my local environment, it’s time to quickly define and configure the development workflow, the way that the team will develop features then test it before production and finally hit production time

If you need to create this kind of setup, I’m here to share a bit of my experience about how to do it. My objective here is to help you from the time that you created your local feature branch, going through the continuous integration process until finally delivery the code to production.

I’m not a big specialist in AWS so feel free to share your thoughts/suggestions on comments, I’m pretty sure that there are different ways to do the exact same that I will describe below, so I’d love to read it :)

The stack:

For this post, we’ll be using:


So let’s start defining the environments:

Local: It’s is your local environment, connection with your local database and running your local code.

Stage/Dev: Is the stage after your feature was accepted on the Pull Request, time to run tests and make the checks before production.

Production: Well, self-explained :)

Branch strategy:

Master: production code

Develop: stage/dev code

feature-branch: local code


Let’s start with the project structure, it’s a basic “hello world” with lambda with a few additional files.

Project structure

Note the following files: serverless.yml, local-secrets.yml and config.yml, they are the focus of this article.

Looking inside the serverless.yml

Explaining the file:

Custom block: will define all custom configuration, so the serverless framework will be able to understand a few configurations that our project need.

  • stage: this is the stage of the workflow, it will grab the current stage from the options sent by serverless start command*, if none is sent the fallback is ‘DEV’. (You will see the command on the circle ci config.yml)
  • environment: here we are defining the environment variables, our code will access this later, note that I’m using two ways to put the value inside each variable, the MESSAGES is defined inside serverless.yml but the SECRETS values are defined inside the environment, in our case, CircleCi, if the current environment doesn’t have these variables, the fallback will be local-secrets.yml. Confused? Ok, let go a bit deeper inside the DB value:

Provider Block: here you will tell to serverless all configuration that he will set on the provider (in our case, AWS).

  • stage: here we are telling which stage we are deploying
  • environment: here we are getting the values to set on our server environment, note that the MESSAGE is also defined accordingly to the current stage.

A quick look into the local-secrets.yml:

Ok, serverless.yml is ready, what about the handler?

It’s a simple hello world but using our environment variables


All set, moving to CircleCi configuration:

Excluding the few very specific configurations, the deploy command is important here, when the current building branch is master, the serverless command should be with PROD flag. If it is the develop branch, then DEV flag.

One step more that we cannot forget is the environment variables on the circle ci:

Circle Ci Environment Variables

So last but not least, we should configure AWS to receive this code right?

Let’s create a new user and we will call him serverless-agent:

If you have doubts about how to create and give the permissions for this user, or create the user access keys, you can follow this tutorial. Could be a good thing if you create one specific user for production deploys and others for development.

Once you have the user created, the keys are saved on environment variables you are good to start with your deployment.

Develop branch building

After success on both builds, you will be able to access your AWS Lambda console and see how the serverless framework built and created all necessary resources to make the lambdas work.

Prod and Dev applications

Inside each application, you can see and manage all the resources involved in this process.

And here go the result of hitting the hello-world API that we just deployed:

Dev Deployed
Prod Deployed

It’s all folks, hopefully, this article can save you some time ;)

Btw: You can access the code used to create this article here


Guilherme Waess

Written by

Javascript Engineer, clean code lover and unit tests advocate :)