Preview Environments help teams avoid a polluted QA environment, yet their ephemeral nature requires some special considerations for your application.
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.
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.
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.
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.
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.
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.