DEVOPS

An environment of one’s own

How we gave each developer their own serverless development environment and integrated it into our PR process

Originally published on Altostra

Personal Branch Deployments

Here at Altostra we rely heavily on our deployments feature in our development process. To those of you who aren’t familiar with it yet, A Deployment is a live release of your project in a specific environment — with the added value that you can have multiple deployments in the same environment at the same time.

During our development process, our developers are free to deploy their currently under-development version of any service to the Dev env and test it in a fully working environment. We call these Branch Deployments.

You might be asking you how we prevent our Dev env from exploding with numerous stale deployments (not to mention the costs) — well, that’s easily done with our expiring deployments — we set them to auto-delete within 5 days from creation.

Not long ago, one of our developers noticed that we sometimes discover issues only when our new feature reach the integration-test phase — and wondered why we aren’t running these test before the PRs are approved, and not after.

So with the help of GitHub Actions, that’s exactly what we did.

How to do it

In this post we’ll learn how to automatically create a new deployment in Dev whenever a PR is opened or updated on a basic Altostra API service project.

You can read more about the basic API project we’re going to use here, and read more about GitHub Actions here.

If you haven’t integrated your Altostra project with GitHub action before, you can learn how to do it on our [previous post]

Using GitHub Actions to automatically deploy PR branches

Creating a GitHub Action workflow

In your project, under the project root, create a new file (or update the existing file) called altostra-ci.yaml, under .github/workflows

Copy-paste the following code to the file:

This GitHub Action workflow tells GitHub to run the “Deploy PR” job whenever someone opens or updates a PR to master branch.

Each time it will:

• Checkout the code
• Install dependencies
• Config the Altostra CLI
• Use the Altostra API key to push the latest version to the Altostra repository
• Deloy the current version to a deployment named after the branch name
• Run your tests (If you added them)

Let’s see it in action

Now that we have the new workflow updated, let’s take an existing project and test it.

We’ll take an existing project, create a new branch, and create a PR to master. We expect the GitHub Actions workflow to start automatically and create a new deployment with our branch name in our Dev account.

Works! We added a feature to our code, opened a PR, and had it deployed to our Dev env on AWS automatically!

Wrapping up

Using Altostra deployment with GitHub Actions (or any other CI/CD, for that matter) is a great way to automated your testing and deployment processes, and generally to make the deployment process easier — especially when it comes to serverless cloud environments.