Ephemeral environments are a growing trend because they can replace or reduce the time spent in staging environments, thus significantly cutting down on development costs.
In this article, we’ll cover what ephemeral environments are, their benefits in the development cycle, how Environment as a Service enables fast and reliable deployment, and how Bunnyshell can help.
What Are Ephemeral Environments?
Ephemeral environments are environments meant to last for a short amount of time. For example, they could be as short as the lifecycle of a CI/CD pipeline, or they could last for a few weeks (the length of a sprint).
However, regardless of their expected lifetime, the idea behind remains the same: ephemeral environments are supposed to be created, used for a limited period, and then discarded. Because of this, they’re also known as ‘on-demand environments’, ‘dynamic environments’, ‘temporary environments’, ‘sandbox environments’, or ‘short-lived environments’.
Ephemeral Environments Characteristics
1. Ephemeral environments should be a replica of your production environment. As ephemeral environments are mainly used for testing purposes, they should look as close to your production environment as possible. Otherwise, if a test fails, it would be almost impossible to determine whether it will also fail in production as well since the conditions differ (and this kind of defeats the purpose of testing).
2. The creation of ephemeral environments should be automated. Since you already know what they should look like (a copy of your production environment), you can automate their creation using templates (and here’s where an Environment as a Service solution can help). With templates, you can automate the creation of an ephemeral environment on certain events, such as pull requests.
3. Ephemeral environments should use replicated data. This comes back to ephemeral environments being a replica of your production environment - in order to achieve this, the two should use the same version of the database and have the same data sets available to them. This means that the database attached to the ephemeral environment should not be shared with any other environment as it will also be removed as part of the cleanup process.
4. Ephemeral environments should be shareable. If their main purpose is testing, then they do their job best when you can gather feedback from multiple sources and stakeholders such as developers, QAs, product managers, and even customers.
Benefits of Ephemeral Environments in the Dev Cycle
The main reason organizations adopt ephemeral environments is because they accelerate the software development cycle; developers can review changes visually and also share their work with non-technical team members (such as designers, for example) using a link to the proposed revision.
Other benefits of ephemeral environments include:
- removing the staging / QA bottleneck: traditionally, organizations use a staging or QA environment to merge and test all code before pushing it into production. The problem is, they only have one or very few of these environments, so, as the organization grows, this becomes a bottleneck that slows down the development cycle. Enter ephemeral environments - now you have a limitless supply of environments you can use for testing. As every code branch is contained in its own isolated environment, it becomes its own integration environment, so you no longer need a single testing and integration environment to merge all code before pushing it into production.
- allowing early and often feedback: the earlier in the development cycle you identify quality issues, the more you can reduce rework and improve development velocity. Ephemeral environments help minimize rework by enabling all stakeholders to become part of the development process. For example, QAs, designers, product managers, or even customers no longer have to wait until a developer finishes coding to see changes, they can offer feedback as the feature is being built.
- limiting rework, thus increasing development velocity: Continuous Integration (CI) focuses on the idea that you should continuously test your code as it’s being pushed. The problem is, most CI systems only perform unit tests (they test small units of code, not the entire system), while Integration and Smoke tests (which test the system as a whole) are left until the code is merged to the main branch in the staging environment. If any issues are found at that stage, it’s already too late; you’ll need rework to get them fixed. Even more, if there’s only one staging environment available, this will create bottlenecks. Ephemeral environments allow Integration and Smoke tests to be run right after the environment is created, thus ensuring they’re performed as frequently as unit tests and allowing you to find issues early in the development process.
- allowing for experimentation with infrastructure: infrastructure changes are costly both in terms of money and time, and they can slow down your team’s velocity. But with ephemeral environments, testing the new infrastructure can be done in isolation, so it doesn’t affect other developers.
- they enable Agile / Scrum: today, many organizations follow Agile / Scrum practices, but their infrastructure and technology are not always adapted to iterative software development. These workflows focus on early and frequent feedback, and ephemeral environments are the perfect tool to enable that.
How to Deploy Ephemeral Environments
We strongly suggest you use Infrastructure as a Code (IaaS), and containers as they make using ephemeral environments easier. Alternatively, there are also Environment as a Service platforms that can automatically create new testing environments for you as you push code (like Bunnyshell). By keeping your infrastructure as code and resources reproducible, you can recreate the same environments repeatedly and keep the configuration of your environments identical.
![[object Object]](https://images.prismic.io/bunnyshell-blog/598b54cd-f317-4b70-a6f5-5bfa0e84eddd_Icon%20White%20on%20Blue.png?ixlib=gatsbyFP&auto=compress%2Cformat&fit=max)
Automated Ephemeral Environments
Ready to Automate Ephemeral Environments?
Bunnyshell automatically creates ephemeral environments on every pull request and tears it down with every merge close. Give your developers power of self-served environment creation and turbocharge your development cycles.
Creating an Ephemeral Environment
Usually, the creation of a new ephemeral environment is triggered when a developer pushes code to a branch and runs unit, integration, and / or functional tests. If the code passes all the tests, it can be merged with the main branch and deployed into production. The most common deployment types are blue-green deployments, dark launches, canary launches, and feature flags.
Once merged, the ephemeral (test) environment is no longer needed and can be discarded, along with the resources it used.
Constantly Need New Ephemeral Environments: How about EaaS?
As you constantly need to test new features and code changes, creating and removing environments can become time-consuming. But with an EaaS solution, you can improve the speed at which new environments are created and ready for use and feature branches can be integrated, reduce costs, and allow your developers to focus on the code instead of the environment.
You may also like:
> Creating and Deploying Ephemeral Environments
> [Video] Well, It Worked In My Local Environment
> [Video] Creating Automated Testing Pipelines with Environment as a Service
Enable High Velocity Development
Breakaway from the inability to quickly deploy isolated environments of any specification.