Kubernetes preview environments grant developers access to their WIP features in a production-like state early on in the deployment pipeline. Here’s a 30,000-foot view on what they are, how they’re used, and why they’re important.
What are Kubernetes preview environments?
Kubernetes preview environments are on-demand deployments of a branch or PR that you want to test and preview. They use similar services and data to production, so you can run end-to-end tests against them, and get a real sense for how your code changes will fare in production.
Ideally, these preview environments spin up when a PR is opened, and use GitOps to update on code changes to reflect your SSOT repository.
What are some preview environment use cases?
Kubernetes preview environments are a step up from your local dev environment or your CDE. They’re built from your latest code changes, so you can preview a WIP feature alongside all services, integrations, and data. They solve the “but it works on my machine” problem: getting something off of your machine and onto your real prod-like infrastructure is less of a lift.
This opens a lot of doors, especially earlier on in your deployment lifecycle. Some of the most obvious benefits are:
- E2E and integration testing. Usually these have to wait until staging/prod, but with Kubernetes preview environments, you can do it at the PR level (or before).
- Code reviews. Instead of struggling to rebuild your local environment, your peer can view and interact with your feature in a Kubernetes preview environment, to get the context they need behind your code changes.
- User acceptance testing (UAT). Product usually has to wait for a feature to hit staging before they test their UAT workflows. By testing against a preview environment, they can give immediate feedback and the engineering team can make changes right after.
- Design reviews. A screenshare or screenshot doesn’t quite go 1:1 with a Figma mockup. Your designer or product team can see the frontend changes live, and make sure sizing and interactive elements work as intended.
How does a Kubernetes preview environment work?
The workflow around a Kubernetes preview environment is pretty intuitive. These environments respond to your development flow automatically (thanks to GitOps). That way, they improve DevEx; they don’t add to your cognitive load or create unnecessary steps, they just respond to your repo events. DORA research found that teams with on demand self-service, or ability to provision infrastructure on their own, tend to perform better and have lower frustration.
Usually, the workflow goes like this:
- A developer creates a PR for a finished or WIP feature
- The PR triggers the provisioning/build of a preview environment
- CI/CD pipeline runs using the unique environment link, executes unit, E2E, and integration tests
- Peers visit the PR and click the environment link for code + design reviews
- (Optional) the developer makes any requested changes and the environment updates, repeat steps 2-4
- The PR gets approved and merged, and the environment spins down
Having the Kubernetes preview environment in play makes this loop shorter, since it happens earlier on in (and even during) feature development.
Core features + attributes of preview environments
Preview environments are most valuable when they’re built to fulfill a few QoL requirements. Without those principles guiding their design, they can detract from your DevEx and may be just another tool for engineers to learn.
At minimum, preview environments are best served by:
- A SSO gate and RBAC. You should be able to granularly control who can access the preview environment. You shouldn’t have to implement login logic on your own, use an external auth provider.
- Unique, patterned URLs. Much of the value of preview environments stems from their ability to be easily shared. You should be able to generate URLs that match a branch/PR/feature name, and send them out to your team for review (or expect the pattern in your CI/CD pipeline).
- GitOps enablement. Preview environments shouldn’t require manual intervention for basic code events (excluding pausing/reviving an environment when needed). They should integrate with your SSOT and update on every code change, and spin down after a given timeout.
Why do teams like Kubernetes preview environments?
TLDR: they make development, testing, and deployment easier.
Engineering managers like to optimize for developer experience (DevEx). They want to make life easier for developers through tooling and processes, so that devs can get in “flow” and produce high-quality software. DevEx usually results in more reliable software (fewer outages/rollbacks/bugs), and more frequent deployments.
Good DevEx takes a lot of separate steps to achieve. You’ll need to find ways that your developers are negatively impacted/inconvenienced, and solve for those. This might mean adopting new tools, dealing with tech debt, catching up on docs, conducting surveys, or hiring DevEx engineers.
Kubernetes preview environments cover a lot of ground when it comes to solving for DevEx. They help developers get feedback (product, design, testing, performance, etc.) without infrastructure delays. They also act as a staging environment before the staging environment; sometimes it can be nearly impossible to catch certain performance issues until staging, and k8s preview environments help fill in that gap*.*
Teams benefit from the independence they gain from preview environments, and managers are happier knowing that their DORA metrics are improving and their developers are more satisfied with their day-to-day.
Shipyard: Kubernetes preview environments made easy
If you’re looking for an all-in-one managed Kubernetes preview environment platform, you’re in luck. That’s what we do best — we automate the lifecycle of preview environments, taking your Docker Compose and transpiling it into best-practices Kubernetes. It’s as simple as opening a PR: Shipyard will drop a link to a full-stack preview environment ready for testing, previewing, and sharing. Give it a try for free and see for yourself!
