Using Vercel for CI and CD to Support Team Collaboration

I’ve been looking for a cloud build tool that can run a project’s tests, then compile and build that code. In the past, I’ve used AWS CodeBuild, GitHub Actions, Azure devOps Pipelines, and CircleCI (among others) to run builds on remote servers and validate new code.

I recently used Vercel hosting for the first time, and it made me and my team more efficient in two ways:

1. By utilizing continuous deployment to arbitrary environments, it’s been easier to get more input from design and stakeholders on in-progress work.
2. Using Vercel as a CI tool and a hosting solution reduces the number of tools we need.

Our Setup

I found it very easy to set up Vercel for hosting my team’s Next.js application. It was a simple matter of logging into Vercel via GitHub and accepting the permissions. After that, I was able to quickly deploy the app to a Vercel domain name.

Vercel also provides an environment variable management interface, which is pretty standard and comparable to the other hosting tools I’ve used. I found it easy to use this interface to manage the different variables needed for the different environments of dev, staging, and production. For example, my team’s app relied on an external identity provider and connected to different versions of that service for staging and production.

• We set up our hosting so that the primary branch main was the production branch and contained code available to real users. This branch was affiliated with a custom domain name as well.
• Our staging branch contains any code that has already gone through a peer-review process (often a pull request) and has been reviewed by a designer to validate any visual design implementation. This is the environment our internal testers and any internal stakeholders would use for final testing before a release.
• The feature branches contain code in progress that is not ready to be merged. When someone creates a pull request in GitHub, these feature branches are automatically deployed to unique URLs. This means that, in addition to reviewing the code during a PR, the whole team can also review it from a user’s perspective. This is particularly useful to me when completing feature work that has a visual or usability component that may require input from the designer on my team. I can simply link them to the deployment of the PR, and they can weigh in on whether the feature is matching what they envisioned.

Code Review as Feature Review

Hosting was my primary reason for using Vercel, but after setting up our app, I realized that commits in GitHub now had build status indicators. At first, these status indicators were the result of running a build step and deploying the artifacts. This is because the default build command in Vercel for Node apps is the build script.

I wanted those status checks to include the result of running our test suite and code linting. To achieve this in our Node app, I added a new entry in the package.json scripts called buildAndTest which runs the linter, performs a build, and executes the tests. Then in Vercel, I updated the project settings so that the buildAndTest script is run instead of just built. Now work is only deployed (to pre-prod environments) if the tests pass. And status indicators on commits in GitHub reflect the test and lint status as well.

Using Vercel in these two ways has worked so far for my team and has provided us new ways to bring more of the team into the pull request and feature delivery process.