Transient test environments

"Works on my machine" - A developer

These four words have been said by almost all developers. If you dig into the underlying issue there's potential to make your build pipeline more robust and be able to better support a scaling engineering team.

If you have more than one developer on your team you've also likely run into a problem where you're both working in similar areas - when your change goes out to QA they report a bunch of issues with parts that don't relate to what you've been working on. The key problem is testing isolated change-sets. This only gets harder the more people you have on the team.

OK - how can we make this better? What if a PR spun up a complete replica of your production environment, with sanitized data, once you marked it as 'ready for test'? This entire environment would only have your changes on it so you wouldn't be able to play the blame game with other developers!

Tools/things to make this happen

• You need to have control of a domain name and subroutes. I managed to write a simple CLI app to add CNAMES via the Cloudflare API, I'm sure whatever you're using will have something similar. I picked pr-2344.company.co.nz (2344 was the PR number from Github), you could also use branch names (mybranch.company.co.nz) but you could run in to conflicts so YMMV.
• You need to have containerized (or similar) your front end (bonus points for also doing your backend!). This is not an easy step but has a LOT of other benefits, especially for a scaling company. If you just have a bunch of files or a SPA, you can deploy to s3 (or whatever platform you like)
• You may need to tweak CORS so your PR front end can communicate with your test/dev backend (if you haven't containerized that part yet)
• Authentication (if you have it), needs to be OK with running on a subdomain. This is usually fine, you may need to tweak redirects to ensure it plays nicely.
• You need some sort of trigger to spin up the application. You can use webhooks from GitHub and watch for specific tags being added to a pull request, or you can just build each time a PR is pushed to origin.

So what are the key benefits to take away from this?

• Test in isolation! Having stable data and a small change-set is KEY for testing. If you are currently testing in a standalone test environment and frequently get your data changed/blown away, I feel your pain!
• Forced in to thinking about containerization! This is generally an afterthought for new companies as you usually have bigger fish to fry, but it's a lot easier to start with than to migrate to - so keep this in mind when starting a new project.
• Enable developers to treat an environment like their local environment! There's a lot more ownership involved when an entire environment is your own. If there are issues on there it can only be either existing or related to your change-set.
• Demo-able and shareable environments before they hit the main code-base! With these environments, you can just share the URL to BAs / PMs or even your end-users. Since the code never hits the production branch you don't have to worry about blocking the build pipeline to get a change out.

Side note: I think there's no need for a development environment with this strategy. A test environment is still required to test the aggregate of changes together and should be gated by QA.

Netlify currently does this all for you and has an excellent platform to get you started! https://docs.netlify.com/domains-https/custom-domains/multiple-domains/