Continuous preview environments: what they are and why they rock
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.
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
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 vercel.com 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 uffizzi.com.
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