Continuous preview environments: what they are and why they rock

minute read

What are continuous preview environments

Continuous preview environments (CPEs) are ephemeral testing environments that are dynamically created when a Pull Request is opened and terminated when the Pull Request is closed. They are called ‘continuous’ because they constitute an integral part of the continuous integration pipeline, and allow for in-progress development branches to be deployed and reviewed pre-merge. They are set up to run automatically and on-demand to provide a continuous feedback loop during development, rather than in separate QA environments. 

Image taken from

Why are continuous previews so useful

There are a number of reasons why you should consider making continuous previews (CPs) part of your development process:

  • CPs offer the opportunity to review code in a holistic way, by deploying a realistic setup of the code on your Pull request
  • The Pull request can be reviewed in the deployed environment before merging, so any changes and improvements to the code can be implemented faster. This means the feedback cycle gets shorter and the product delivery is sped up
  • CPs lower costs because smaller feature branches are short-lived, and PEs only live as long as a feature does - the environments can be closed down faster, keeping things economical
  • Developers can test their features in isolation, without worrying that they might break a long-lived shared environment
  • CPs help nurture cross-functional and t-shaped teams. As the feature is automatically deployed when the pull request is created and redeployed when changes are done to the code, the developer is closer to the integration process and gets more comfortable with releases as well as better understanding the DevOps practices
  • CPs bring QA into the development process for a truly “continuous collaboration between Development and Product”
  • Preview environments create a visual/touchable representation of the reviewed feature, which allows even non-technical team members and stakeholders to review without having to read or understand the code. This encourages better collaboration and provides a more mixed feedback

Questions to tackle when adopting continuous previews

So you have decided to adopt CPs for your workflow - great. You will face some interesting challenges as you introduce your team and stakeholders to this method:

  • What is required to reduce the time it takes for the pipeline to spin up the preview environments with all the necessary pieces?
  • How do you spin up and tear down together resources that are hosted in different systems or using different providers?
  • How do you remove all the pieces of the environment when the Pull request is closed without leaving any unwanted resources behind?
  • What resources are needed to tear down preview environments during non-working hours to reduce costs?
  • How do you identify interconnected services and their dependencies? (e.g. identify what service should be spinned up first so the second one can connect to it)
  • Related to this, how do you create predictable URLs that can be used before a service comes up?
  • When you have a new code change, how do you only redeploy the services that were updated?
  • How do you track the environment creation process and communicate its status to developers?  

Tech to help you set up continuous previews

There are several ways you can set up continuous previews in your work. For instance the excellent makes deploying previews for most front-end components a snap, but if you want your previews to be truly full-stack you will need more. At Lola Tech, we like using Uffizzi, an open-source engine that lets you create continuous preview environments for APIs and full-stack applications. Its ability to spin out individual development branches with the click of a button has enabled our team to collaborate much more effectively on a recent time-sensitive project for a research institute.  

A little more about Uffizzi

We have listed a few features and characteristics that we are particularly enamoured with below. But why not give it a go and find out for yourself: You can learn more about the technology, sign up for a live demo or create a free account on

  • Using docker-compose, the Uffizzi platform lets you deploy any service that can be containerised
  • Using a single docker-compose file you can control all the containers that you want to be deployed, and more:
  • Choose which service should receive the incoming traffic
  • Select whether to create the preview on Pull Request opened
  • Select whether to delete the preview on Pull Request closed
  • Give feedback on the Pull Request (as a comment) showing that the preview is ready and where it can be found
  • You can also set it to delete your environment after X hours (which helps reduce costs)

There is also:

  • A user-friendly dashboard where you can see your environment together with container logs
  • A well-maintained set of Github Actions and a Gitlab reusable workflow are available, as well as a Uffizzi CLI that helps with CI pipelines

Finally, it's worth mentioning that:

  • Uffizzi is cross-platform and can be used with any Version Control System, Continuous Integration System and Container Registry 
  • The tool is free to use for open source projects
  • The support team is responsive and helpful, which is always nice

Further reading

For those interested in finding out more about continuous preview environments, there is a lot of great information out there. A few suggestions to get you started:

Have a project in mind? Let's talk.

Contact us