What is a preview environment?
A preview environment is a shareable pre-production environment designed for viewing and interacting with new features or code changes. Preview environments are typically created once a branch is ready to share with other team members for code review or design feedback. Preview environments are meant to be short-lived — they’re spun down after team members are done reviewing.
Why do teams use preview environments?
Most engineering orgs have a single-digit number of staging environments. It is best practice to only use static staging environments for branches that are nearly production-ready, which means they should be approved by multiple team members and tested at length before they hit staging.
Anything and everything you’re working on deserves feedback from your team and other stakeholders. However, there’s only so much you can do during a screenshare call. Getting a team member to recreate your local dev environment just for a quick code review is a pain and not an efficient use of time.
Preview environments eliminate the lift for getting more eyes on your code changes. They’ll have similar infrastructure to your production, so you’ll get results more representative of how your features will actually perform after a deployment. Since they’re easily shareable, you can send out an SSO-enabled link to collaborators for quick and async reviews.
As a developer, you shouldn’t need to do any of this manually — once you’ve integrated preview environments with your repository to respond to GitOps webhooks, they should spin up automatically on a PR/MR.
Where do preview environments fit into the SDLC?
Preview environments are often used as “post-commit” environments. You won’t be actively developing against them, rather they’ll showcase your “rough draft” feature in its most current state. You can keep iterating with them and they will automatically update to reflect your latest code changes, but the majority of your development still happens in your local dev environment or your cloud dev environment.
Here’s a sample non-production environment workflow:
- Local dev environment: for iterating and developing features that do not require external integrations
- Cloud dev environment: for developing against more complex integrations and for features that require infrastructure parity
- Preview environment: for sharing features that are either WIP or ready for review
- Staging environment: for code changes that have been tested/previewed extensively
What counts as a preview environment?
While the term “preview environment” is used pretty loosely, there are a few features that these environments must have to best serve your team for previewing and reviewing:
Preview environments are full-stack
Your preview environments should be pretty close infrastructure-wise to your staging and production, if not identical. They should include all necessary services, integrations, dependencies, and a production-like database.
While Netlify and Vercel offer preview deployments, these are not exactly preview environments — they are only previews of a fraction of your entire stack. When it comes to preview environments, staging/prod parity is extremely important so you can get authentic end-to-end application behavior.
Preview environments are GitOps-enabled
You (or anyone else on your team) shouldn’t have to create, update, or destroy your preview environments. The last thing you need is one more context-switching task, regardless of how small it might be.
Since preview environments should be GitOps enabled, they will follow the flow of major events and code changes in your repo. This means that they can be configured to provision on a PR/MR, update on any subsequent commits, and spin down on a merge or a timeout. This way, preview environments just happen, no overhead involved.
Preview environments are isolated
Unlike staging or production, preview environments are meant to be broken. In fact, breaking them is encouraged — always better to find the weak spots early on instead of after a prod deploy!
When you want to keep this low-stakes, you’ll want to make sure you’re not sharing services or dependencies between environments. This way, when you take down one preview environment, you haven’t also taken down any other environments (including prod).
Preview environments are easily shareable
Preview environments live on the cloud, not your machine. There should be almost no friction when spinning them up. Sharing them should be as simple as sending a link to a team member or stakeholder.
However, like any non-production environment, preview environments are not meant for wide audiences. They should be gated with SSO to prevent non-authorized visitors from accessing them, and should include the proper HTTP headers to prevent search engine indexing.
How can I get preview environments?
Environment management platforms like Shipyard are a one-stop shop for preview environments. Shipyard handles the provisioning, building, life cycle management, data, and integrations required for the best developer experience when it comes to using preview environments in your release process. Try it out yourself today or book a demo to learn how Shipyard can fit into your org.
