Ephemeral environments for rapid testing of new features on web development

Dennis Ruiz Vasquez | February 21, 2022

 

What is an Ephemeral environment?

Development environments have been around for some time. These are isolated environments where our applications are subject to testing. Developers and organizations that leverage Git workflow put an emphasis on creating an environment for each main branch. But a development environment based on ephemeral environments allows us to temporarily deploy our application in a sandbox so that we can review the full behavior of the application before approving a pull request to a main branch, followed by disposing and reusing resources more efficiently.

One of the most important factors for a successful ephemeral environment workflow is to make the environments look as much like a production replica as possible. For starters, if you use Docker images, the same image that you deploy to an ephemeral environment must be eligible to deploy to your production server. Thinking of memory as an example, if the production server is allocated 2GB of memory, then the ephemeral environment should have that as well. If the ephemeral environment has less memory, say only 1 GB, and a memory-intensive part of the application fails, it is now unclear whether the application would fail if the same image were deployed to production.

Ideally, we need some tools that help us to manage the use of ephemeral environments from start to finish; Currently solutions such as Kubernetes or Nomad Hashicorp help us manage the deployment and self-healing of our applications And we have Terraform, Pulumi and the latest versions of Ansible to work with infrastructure as code (IaC), so what remains for us is to create templates for the implementation of our applications using the tools.

When we have these templates, the ephemeral environments must have the ability to be configured to automatically deploy everything necessary according to certain events within the project, the most usual and recommended being the start of a pull request without ruling out the possibility of creating other environments manually in case a new environment is needed. After all, it is very important to delete the environment to free up and reuse resources.

 

When to use a static environment vs an ephemeral environment?

 

We refer to static environments as those that are long-lived and are not allowed to be destroyed. Depending on how these environments were created and whether any infrastructure-as-code tools were used, long-running static environments can get out of sync with each other. This leads to different dependency versions and bugs that are due to environment quirks and not necessarily code changes.

There are economic considerations involved in maintaining a static environment that remain inactive for a long time, preventing development teams from moving quickly. If an environment can only run and maintain one build and test context at a time, it can be a bottleneck for the development team, which would wait for a new version to be successfully updated. If the team is large, the lost value can be significant

Either way, it is recommended that ephemeral environments be deployed before their deployment to a static environment and are the final step when deploying to production.

 

Picture1-4

 

 

What would be the workflow while working with ephemeral environments?

Generally attached to branches, a developer typically triggers the creation of a new environment by pushing to the branch, and other services (internal and external) automatically run some of the tasks depending on the nature of the application. If all the tests pass, then you can automatically or manually approve the changes and merge them. When working with continuous deployment, these changes are now deployed into a production environment.

With the environment no longer needed, and the branch merged, remove the environment, and the resources it used. Whenever you merge the changes into a mainline branch, you should run further automated tests to ensure that other code changes don’t affect these new changes.


Useful resources and tools:

About Encora

Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.

 

Contact us

 

References

 

 

Insight Content

Categories

Share this Post

Featured Insights

Fill Out Later