Preview Environments: What They Are and How to Use Them

Lukas Gentele
Gaurav Singh
7 min read

An “environment” is typically a space in which software can undergo either experimental/temporary uses or permanent uses. We often create them for specific purposes and name them accordingly, such as indicating whether an environment setup is for development, testing, production, etc. Setting up an environment is essential to any software development life cycle (SDLC) all the way through to production.

Furthermore, code review is an important part of software development and delivery. During development, you often create multiple branches in a Git repository and merge them based on the need. Without review, you might not know if you’re getting a good pull request (code containing no bugs) or not. This is where Preview Environments come into play.

A preview environment, also known as an “ephemeral environment,” helps teams to track and test any code changes without the help of code reviewers or testers having to configure everything on their own machines. In simple words, the preview environment contains all the code of your pull request in order to test changes easily.

In this article, we’ll explore preview environments in brief and learn how one can use preview environments to ease the SDLC testing process.

#What Is a Preview Environment?

A preview environment is a cloud environment that helps in testing code changes before merging them to the original (master) branch of any Git repository. It helps in increasing the development velocity of a team by reducing the time taken to merge any new feature. Preview environments have a short life cycle because they have the same lifetime as an event that triggers their creation, like a pull or merge request. They get created when you create a PR, and they get destroyed when the PR is successfully merged or closed.

Preview environments have become a crucial part of CI/CD workflow. Consider a scenario where a team of engineers works on certain products and develops different features. Now, for different engineers, the development environment is not the same, so the staging environment is also shared between them. And due to the shared environment, the code is broken down into different parts. In this scenario, QA has to wait until the complete code gets fixed to test each feature. This problem gets more complex when each feature contains multiple integrations, different data, or connector sources so the DevOps team cannot provide a different environment on time.

So to solve the problem, we bring a preview environment into the picture. Nowadays, they are mostly used by DevOps engineers and QA. Each change is tested in a separate environment and automatically gets merged, and then tested, then merged, and the process goes on without any flaws.

#Preview Environments with Kubernetes

Kubernetes is an open-source, scalable platform used for managing containerized applications and automating deployment. There are different ways of easily creating a temporary environment with Kubernetes, so there’s no need for a static test environment. But the efficient and simple way is to use a namespace for each pull request that is provided by Kubernetes. Hence you can easily deploy a preview environment into Kubernetes, which provides optimized resource allocation, fast application start up, etc.

#When Do Preview Environments Matter?

Now, let’s go through some issues that indicate preview environments might be beneficial for your organization:

  1. New PRs take a long time to merge.
  2. Code freezes in a development environment.
  3. You have a big team of engineers (more than 4) using the shared environment.
  4. Testing of code changes takes more time than manual testing on the local machine.
  5. You want to improve the collaboration and feedback cycle between team members.

#Benefits of Using Preview Environments

Preview environment serves multiple benefits to the CI/CD life cycle, because they allow for easy automation of the test environment and reviewing of the code changes in a separate environment. Let’s take a look at some of these benefits in more detail below.

#Reduce the Feedback Cycle and Promote Faster Delivery

Preview environments speed up new releases of any product because they help in facilitating a faster feedback cycle. Suppose a developer commits a new PR for a defect fix or feature. The preview environment will then check the integration and changes in a separate environment, and if everything works fine, then it’ll automatically merge the code with the master. So you don’t need to wait for the merge to observe the code changes. Hence they allow releasing of the hotfixes without overriding the staging environment.

#Reduce Costs and Increase Time Savings

As preview environments have a short life, this means they get destroyed with the merge of PR after approval, which removes the need for permanent infrastructure and results in reducing the cost of the test and production environments.

The automatic provisioning and de-provisioning of environments reduces much time spent manually setting up the environments, and apart from this, the bill amount from the DevOps team also decreases because they need to spend less time and effort and there are fewer resources being consumed.

#Increase Work Responsibility

Preview environments help teams to engage with each other and observe the live changes from each side. This results in a better understanding of code and increased responsibility. In this way, developers or designers learn more and improve upon their mistakes.

#Improve Review Process and Overall Product Quality

Preview environments make the product development process more streamlined, because as they unite all teams together, they still maintain the collaboration between automation testers, manual testers, designers, and developers. Each piece of feedback can be easily recorded, iterated on, and taken care of with the utmost priority. This results in better product quality overall.

#Standardize the Common Operating Process

Generally, in the CI/CD workflow, any team can pull code and run it on a local environment. And the approach followed by them could be different from other teams, which can create further merge conflicts. So, the preview environment provides a standard and best practice that every team can replicate and each team can follow.

#Working on Preview Environments

The workflow of a preview environment is very simple. To understand the complete step-by-step process of how a single code change gets tested and merged using the preview environment, follow the below-listed steps.

  1. Create the pull request
  2. Create the preview environment
  3. Submit the changes and update the environment
  4. Merge pull request
  5. Remove the environment

For further explanation, suppose a developer is writing code on a local branch to include a new feature in an existing product. The name of the preview environment can be based on the name of the feature. That way, correct naming helps in distinguishing the different preview environments. Now, when a developer pushes their code from the local branch to the remote branch, the new PR gets created and a new preview environment is initiated, containing everything that is required for a smooth testing of code changes. Furthermore, you can access it through its unique URL. The testing team can access the changes through that URL, and they can test the changes in that separate environment. After successful testing, the PR gets merged into the master branch, and the preview environments can be automatically destroyed.

There are multiple platforms that provide preview environment functionality, and one of the most popular ones is Loft. Loft allows you to spin up a preview environment for every pull request and branch with a simple click. To test new features, conduct end-to-end and user acceptability testing, or simply to give a team member a taste of what will be included in the upcoming release, spin up an instance of your application with Loft.


Preview environments are a convenient way to test and merge code changes when you’re working with a team of engineers on a large code base and require regular pull and push commands. You’ve learned what a preview environment is, and how preview environments are beneficial for QA and DevOps engineers to lower their efforts in debugging the code.

Furthermore, we’ve also gone over the product feedback and review process cycle that gets advanced and improved while using preview environments. It should now be clear how important preview environments are to the CI/CD workflow. So if you’re ready to use preview environments, consider trying Loft.

This post was written by Gourav Bais. Gourav is an applied machine learning engineer skilled in computer vision/deep learning pipeline development, creating machine learning models, retraining systems, and transforming data science prototypes to production-grade solutions.

Sign up for our newsletter

Be the first to know about new features, announcements and industry insights.