Why use Preview Environments?

‍Common benefits of a Preview Environment

Below are common benefits when preview environments become an integral part of your development process.

Unburden your team lead or open-source maintainer

Development Team leads and open-source maintainers bear a huge amount of responsibility. To mitigate merge risks they will often want to see a running version of a Pull Request before they approve it.

Without Preview Environments this means pulling down the branch and running it in their local dev environment. This, of course, can be time consuming—multiply it by the number of developers on the team, and this becomes their whole job.  More importantly each maintainer may do this with a different environment set-up which makes standardization impossible and makes for an inefficient code review and deployment cycle.  If your application has a number of dependencies the challenge here is multiplied.

Catch bugs before merging

Identifying bugs prior to merging will save time and headaches for your Development Team lead. If you merge buggy code to a trunk branch, you’ve made an unforced error.

You won’t be able to cut a new release to production without 1.) Reverting your changes (=RISKY) or 2.) Waiting for the bugs to be fixed. And, of course, if you’ve broken a shared environment all testing will grind to a halt.

With a Preview Environment you can review code in a standardized, holistic way which drastically improves the odds of catching bugs early. You can use Preview Environments to run automated tests or conduct manual exploratory testing—either way your team lead will thank you for keeping dirty code out of a trunk branch.  

That’s not what I had envisioned

Ensuring continuity between what is designed and what is implemented is a ubiquitous organizational challenge. Preview Environments solve this by enabling your team to bring in all the key stakeholders early in the process.

Would you rather find out the product owner doesn’t like how something was implemented right after you code it, or a week later when they see it for the first time? Create end to end visibility across your entire organization.

Standardizing how you operate

Preview Environments enforce a best practices process that can be replicated across all of your teams.

For example how one team lead pulls code to run in their local environment will not necessarily match how another does it. Preview Environments as part of your Continuous Integration represent a best practice that all teams can follow.

Circumvent the automated test queue

As automated testing matures for any project, the queue against a single or limited number of environments becomes its own bottleneck.

This “queuing effect”—waiting up to several hours for tests to run—will only grow over time and continue to slow your team down. A Preview Environment enables faster feedback loops. Previewing can be done in parallel so that a single buggy commit does not hold up the entire forward progress of all the working commits.