So to recap, here’s what we’ve created so far.

All of this is neatly committed in a Git repo.

So far we’ve been deploying our app locally through our command line — npx sst deploy. But if we had multiple people on our team, or if we were working on different features at the same time, we won’t be able to work on our app because the changes would overwrite each other.

To fix this we are going to implement a CI/CD pipeline for our full-stack serverless app.

What is a CI/CD Pipeline

CI/CD or Continuous Integration/Continuous Delivery is the process of automating deployments by tying it to our source control system. So that when new code changes are pushed, our app is automatically deployed.

A CI/CD pipeline usually includes multiple environments. An environment is one where there are multiple instances of our deployed app. So we can have an environment called production that our users will be using. And development environments that we can use while developing our app.

Here is what our workflow is going to look like:

  • Our repo will be connected to our CI/CD service.
  • Any commits that are pushed to the production branch will be automatically deployed to the production stage.
  • Any PRs will be automatically deployed as preview environments.

Our workflow is fairly simple. But as your team grows, you’ll need to add additional dev, staging, or preview environments.

CI/CD for Serverless

There are many common CI/CD services, like GitHub Actions, Travis CI or CircleCI. These usually require you to manually configure the above pipeline. It involves a fair bit of scripts and configuration.

SST makes this easier with the SST Console’s Autodeploy feature. It also shows you all the resources in your app and allows you to monitor and debug them.

We should mention that you don’t have to use the SST Console. And this section is completely optional.

Let’s get started with setting up the SST Console.