In this guide, I’ll explain what Framework Pro preview deployments are, why you might want to take advantage of them and then show you how to enable these on your own applications. I’ll use a version of a song vote counting service I created called Serverless Jams to help illustrate this and you can follow along with me step by step.

So What Are Preview Deployments?

You might be familiar with the concept of preview deployments from frontend tooling like Netlify that allow you to create a preview of frontend builds before they are merged into a production website.

Well, we at Serverless thought - “Why don’t we have that for our backends?”

In the past, the answer to this question has been simple - it costs too much. In the days of expensive, sprawling backend infrastructures it took far too much money and developer time to replicate these environments effectively for testing and staging - let alone for every PR.

But with serverless applications, managed services, and microservice architectures that’s no longer the case. Take a typical AWS microservice with the serverless framework. What resources are included? Probably some of these:

• Lambda Functions
• API Gateway Endpoints
• DynamoDB Tables
• SQS Queues
• SNS Topics
• S3 Buckets
• SSM Parameters

What characteristics do these resources share? They’re virtually all pay-as-you-go or pay-per-use/invocation style services or can be configured very cheaply. This means, we can create an entire separate stack of our infrastructure for every feature branch without spending much at all.

Why Use Preview Deployments?

The preview deployments benefits for frontend code are clearly apparent - you get some preview URL of a deployment and you can see what changed and make sure it looks great. So what do we really get out of doing something similar for the backend? Let’s take a look.

Automated Tests and Serverless Safeguard

When you create your Preview Deployment, the Framework Pro CI/CD system will still run any Safeguards you have configured for the default profile. You’ll also still have any automated tests you have setup run against the deployment. This gives you all the same benefits you might otherwise have waited until a staging environment to check against.

They Can Supplement Existing CI/CD

You can use Preview Deployments in combination with Serverless CI/CD for stages like production and staging. Or, you can use them in addition to whatever existing CI/CD tools you have. Already using another tool for your workflow? Great! You can still add Preview Deployments without disrupting any of your existing processes!

A Clean Environment for Code Review

Because you’re spinning up an entire set of infrastructure, it’s open season for your code reviewers to play with the API endpoints and infrastructure resources.

They can run manual tests to confirm the deployment meets expectations, run API contract tests against the API endpoints that are created or integrate the feature branch into local frontends for a fuller test experience. This can be especially helpful when you want validation from a frontend team on the expected functionality for a new API. And because the preview branch is discrete from other environments they don’t have to worry about stepping on any toes during the review.

After this, they can go straight back to the PR, and make sure that any issues and feedback they discover are addressed before the PR is even merged into a staging environment.

Automated Spin Up and Spin Down

Because these resources are all spun up automatically by opening the PR, there’s no manual process for the developer or reviewers to create a full environment to test against. The best part is that when the PR is finally closed or merged you can configure your deployment to automatically remove the infrastructure resources that were created in AWS.

#serverless #ci/cd