I've been meaning to write this blog post for a while now. During the last SUCON Europe in Dublin, I had the opportunity to talk with Matt and Glenn Glenn from Vercel about one of our current projects. One of the most challenging aspects of transitioning from old technology to new is letting go of past practices.
In the past, many of us developers, including myself, relied on DTAP (Development, Testing, Acceptance, Production) environments to ensure our software performed as expected. However, with the introduction of XM Cloud and Vercel, this process has evolved significantly. Vercel allows you to create environments for each branch and/or Pull Request (PR), simplifying the workflow for testers and frontend developers. No longer can we hide behind the excuse that "it works on my machine." Now, every PR can be quickly verified to ensure everything functions correctly before submission.
The ability to create an environment for each branch opens up new possibilities in our development process. However, not everything is perfect. We still face the realities of project requirements. While developers might love the ability to create, test, and push new features instantly, product owners might prefer a more controlled approach, necessitating a staging or pre-production environment before deploying to production.
Vercel anticipated this need and created a playbook documentation page for such scenarios. However, this solution only works seamlessly with a Github repository, which was not the case for us.
TIP: Use Vercel in combination with a Github repository. If this isn’t possible, be prepared to face some limitations, such as needing a separate staging domain.
In our case, we had to disable the Auto-assign Custom Production Domains feature. This can be done in the Git settings of your project. For more information, check out the Vercel documentationVercel documentation.
Once this feature is disabled, you will need to manually promote the staged production build to the live production environment. Promotion involves pointing the custom domain bindings to the specific build, making it quick and easy to switch between build versions and revert if something goes wrong.
However, since we are not using an attached Github repository, we can't differentiate between environment settings. While you could implement a workaround in the head application to manage this, we preferred not to hack it. As a result, the environment settings are shared between production and all staged production builds.
Another thing to keep in mind is that as soon as you connect a custom domain to a non-preview build, it will be exposed to the world. Anyone can connect to your instance. The good news is that the Vercel domain remains protected. So, find a way to announce these unique staging URLs to your team for testing.
To summarize this process visually, we would have something like this:
