To make the most of this tutorial, sign up for Serverless Framework’s dashboard account for free:
Serverless application development is great for rapidly spinning up solutions to problems; you complete a little configuration in a serverless.yml file, add some Lambda code to glue it all together and hit
sls deploy. However, this isn't really going to fly when you have multiple team members working on the same code. You can't have multiple developers deploying code at the same time to the same infrastructure, potentially overwriting what each is doing.
The first step to resolving this issue is to allow each developer access to their own AWS account, possibly using the AWS Organisations service that makes managing multiple child accounts to the organisations main account an easy to manage process. But what happens when this all needs to come together preferably in some kind of staging environment?
The Serverless Framework has a feature you may already be familiar with; stages. You can deploy a Serverless Framework to AWS by passing it a stage that can differentiate one stack from another and this means you have the means to have various environments to deploy to.
serverless deploy --stage staging
Now if all services are deployed to the staging environment it means we have some way to do some quality assurance on an application and a collection of services before we deploy this to production. We can run our integration tests, perform some manual confirmation with stakeholders and customers, and then we just do a ...
serverless deploy --stage prod
This in itself has problems. Its great we can break things up as far as environments are concerned, but we probably need more reliable ways to make sure that code gets pushed to the right environments just as a part of the development flow of your developers.
In a more traditional development environment, the software development lifecycle will include a strategy of using branches to indicate the relative promotion of code to staging and development environments. And to that you would also have a CI/CD backend being triggered off of merges into specific branches. Merging into a develop branch deploys code into a staging environment. Merging into master ends up deploying into the production environment. And deployments cannot be made in any other way.
What if we can get these kinds of strategies to work for our Serverless applications? It will help us solve some of these problems
This is actually very simple to do with Serverless Framework Pro's CI/CD feature. There are just a couple of pre-requisites to get up and running:
orgset within that serverless.yml
With that out of the way, lets go to our service in the Serverless Framework Pro Dashboard:
As we can see, there's a handy
enable link we can click on.
Now we just need to connect Serverless Framework Pro to our Github account and follow the Github OAuth prompts to give the required permissions to enable Serverless Framework CI/CD to deploy our services for us.
Once we are connected:
And now comes what we have all been waiting for. Scroll down the the section labelled
This is where we can now link the branches in our repository to stages in our application, and those stages are linked to profiles that help us control how and to which AWS accounts we deploy to.
And that's pretty much. I did say it was easy. Once we match our branch to the right stage, every merge into those branches will automatically begin deployment..
To get started head to the Serverless Framework Pro Dashboard and sign up for free!!
Gareth is a Customer Success Engineer at Serverless Inc