December 1, 2022
6
min read

Preview vs. Persistent Environments

Preview Environments help teams avoid a polluted QA environment, yet their ephemeral nature requires some special considerations for your application.

Reviewing test environment models

Unlike traditional QA or staging environments which often become polluted over time from data accumulation and conflicting commits, Preview Environments are ephmeral and intended to test a single topic branch. Once they reach the end of their useful life, their resources—including their data—are destroyed. This design isolates developer responsibility and simplifies root cause analysis since each environment is associated with a single feature or bug fix. The dynamic nature of Preview Environments, however, presents some unique challenges that are not present in persistent test environments.

Figure 1- Compare and Contrast Table
Figure 2a- Persistent - Shared Test Environment Model - Highly Inefficient. This is the most commonly used model across the software industry. 
Figure 2b- Preview Environment Test Environment Model - Highly Efficient. Emerging in prevalence. For fast growing teams who want to move quickly.
Figure 2c- Hybrid Test Environment Model - Efficient.  Emerging in prevalence.  For teams that want to move quickly while mitigating risk.

Common challenges of a Preview Environment

Test Data

Reviewing against a relevant set of data is critical to the process for many applications.  For Preview Environments to be effective in this scenario the database needs to be seeded with a relevant set of data.  There’s a few common ways this can be done which we will address in separate resources that are coming soon.

Negotiating managed services

If you are relying on various managed cloud-based services for your application these can be a significant challenge to your effective use of Preview Environments. If the service you are using is stateless in nature, you can supply connection credentials to your Preview Environments via environment variables or secrets.

If you can use a containerized service to effectively “mock” a third party managed service such as using a Postgres container to mock your managed cloud service this is extremely effective.  Your Preview Environments can be lightweight and ephemeral while providing the core functionality you aim to test against.

If you have a stateful service that cannot be represented as a container or a virtualized service, then you probably want to connect to it read-only, or not connect at all. If this is a sticking point for your particular application, you will want to look for an infrastructure-as-code based-solution that can help you create/delete instances of your managed service for your Preview Environment.

Dealing with serverless

Connecting environments to serverless platforms like AWS Lambda can be a point of friction. Fortunately many of these can be containerized as an effective substitute to run in your Preview Environments.

Dynamic URLs

Often many services will depend on calls to a static URL (i.e. qa.acme.com). Preview Environments have a dynamic URL which means you may have to do some work to ensure that your team can dynamically interact with key dependencies.

If dynamic URLs follow a predictable format as they do on Uffizzi, that can drastically simplify connecting your backend previews to your frontend previews on Netlify, Vercel, Amplify, etc.

At Uffizzi we are actively working on a solution to enable dynamic updating of backlinks to key services like OAuth and we look forward to posting about that in our Preview Environments Guide.

Getting started with Preview Environments

For certain teams and applications it may make sense to create your own preview tool, but we highly recommend avoiding this route if possible.

It’s extremely costly for two, three, or more engineers to set up, build, and maintain a custom preview environment tool—especially since there’s handful of solutions on the market that will likely fit your needs and which are constantly improving.

For teams who want Preview Environments on their own infrastructure, open-source Uffizzi is the only self-hosted solution of its kind. And for teams that want the ease of SaaS, Uffizzi Cloud provides teams a way to create a Preview Environment using our environments as a service model.  

Uffizzi integrates with any version control system, CI-provider, and container registry. Define your applications with Docker Compose, then use one of our GitHub Actions workflows or GitLab jobs for easy integration.

You can set up a working example in ~1 minute using our quickstart repo.  It can be configured and deployed from GitHub and includes an automatic free account configuration on Uffizzi.