Ephemeral Environments
Create and destroy isolated testing environments automatically based on pull requests or other triggers to optimize your development workflow.
Is Ephemeral Environments Right for Your Team?
Consider these key questions to determine if ephemeral environments would benefit your workflow:
If you answered yes to any of these questions, implementing ephemeral environments with Ctrlplane could significantly improve your development workflow and reduce operational overhead.
Scenario
A development team needs to test feature branches in isolated environments before merging to main. Each developer needs:
- A complete replica of the production environment
- Automatic cleanup when pull requests are merged
- Cost optimization for cloud resources
- Integration with their CI/CD pipeline
In this example we will be using the following technologies
- Github Actions for CI/CD
- Kubernetes (GKE) for containerization
We are going to deploy a simple nginx application to the cluster and then test it.
Here is a high level overview of the workflow:
1. Pull Request Resource Creation
When using Ctrlplane for any system, you must first determine what resources represent the existence of your deployment.
In this case, we’ll use GitHub pull requests to determine when ephemeral environments should be created and destroyed.
This approach means Ctrlplane will follow the PR lifecycle:
- Creating the environment when a PR is opened
- Destroying it when the PR is merged or closed
To implement this workflow, we’ll create a GitHub workflow that tracks PR state changes and updates resources in Ctrlplane accordingly.
Here is what it does:
-
When a pull request is opened or reopened:
- Creates/updates a resource in Ctrlplane with metadata about the PR
- Includes details like repository, branch, PR number, and author
- Links back to the GitHub PR for reference
-
When a pull request is closed:
- Automatically deletes the corresponding resource from Ctrlplane
- Helps clean up any associated ephemeral environments
2. Infrastructure Creation
Once the pull request resource is created, we now determine what pipelines need to be take give the state of the Pull Request. In our scenario we will create a GKE cluster for each PR.
If you wanted to speed up the creation of the cluster, you could instead deploy to a namespace in an existing cluster.
3. Application Deployment
Lets create a new github action that will deploy our Nginx application to the cluster.