In our post covering ephemeral testing environments, we looked at their general principles and advantages. They help you quickly spin up environments that emulate your production environment, but with the changes you need to test ready to go.
But how do you create these ephemeral/sandbox environments in a continuous manner? There are many ways, and Humanitec is one of them.
What is Humanitec?
Humanitec is a continuous delivery API, meaning you can hook up any continuous workflow to our service, and it creates environments for you as you request them, typically based on a push to a version control branch. Behind the scenes, Humanitec handles deploying to Kubernetes instances hosted on a variety of cloud providers, creating the environment for you and providing any other services your environment might need, such as databases, messaging queues, DNS, or caches.
Sandbox environments
Sandboxed testing environments help review UI changes or functionality changes. You can provide testing teams or beta tester users with specific links for accessing an environment and gather feedback from them.
A sandboxed environment can be more than just a link provided to users. There’s no need to serve particular links to particular users explicitly, you can use one public URL for testing, and proxy different users to different sandbox environments without them realizing. This practice is a common technique for many large technical teams, where they test features on particular regions or user groups somewhat seamlessly.
Use cases for sandboxed environments
1. Parallel feature development
Sandboxed environments give your team the ability to test features in parallel, without blocking static testing environments for use. Instead, they provide access for different groups of team members or users to dedicated environments, and the ability to monitor usage and gather feedback before deciding on a set of features that make it into production.
2. Parallel testing of feature flags
A common way to test feature combinations is using feature flags, which let you hide unfinished features in the same codebase behind toggles. A downside of this approach is ensuring that you test all combinations of toggles are ready for production. Extending the use case above, you could dynamically generate environments that cover each combination of feature toggles, and run tests in parallel across each of those environments.
3. Parallel testing of microservice versions in different combinations
Another use case is for internal testing combinations of dependency versions. This is useful if you’re using a Microservices architecture for your application, or if you want to test changes to the infrastructure that underpins your environments, and not break and that team members share. With dynamically-created sandbox environments, you can test each combination of versions you plan to deploy to a shared test or production environment. It gives you a full picture of any hidden dependencies and the effects that changing them might have.
The challenges of sandboxed environments
Tools like Humanitec as well as infrastructure-as-a-service setups make creating sandbox environments relatively straightforward, the complexities and disadvantages come more in management and cost. When creating environments is easy, you can quickly forget that these environments take resources and infrastructure to run, and thus cost can build.
Keeping track of the myriad environments you have isn’t just a cost concern, but also requires keeping track of what features you are testing in which environment, and the feedback and metrics coming from each of the environments. There is no real point in maintaining so many sandbox environments if the feedback you get from them is poorly managed or tells you little useful.
Your use cases for sandboxed environments
Sandboxed environments can streamline the workflows of developers, test engineers, testers, test managers, and many others involved in development workflows.
I feel the ease of creating sandbox environments using tools such as Humanitec without the involvement of other developers or DevOps engineers, opens the doors for the use cases above, plus many other creative use cases I’ve not considered.
Your perfect CD tool
I wrote this post based on a combination of experience and opinion, and you shouldn’t treat any of what I’ve mentioned as definitive practices to follow. That aside, I have some questions for all of you reading this.
- What are some other creative potential use cases of sandboxed environments?
- As we move forward with building Humanitec, what features do you feel are missing from other similar tools that would make adopting sandboxed environments easier and more useful to you?
Feel free to share your thoughts with me and let’s talk in one of my upcoming webinars.
