If you have end-to-end (E2E) tests set up on a platform like GitHub actions or CircleCI, you can configure these tests to run in an ephemeral Release environment. The flow will be:
Create a new Release environment.
Run the E2E tests in this new environment.
Destroy the environment.
Running E2E tests in an ephemeral environment ensures that they run on a "clean slate", which gives you confidence that tests do not rely on any unknown state that might exist in a long-running environment. Testing in an ephemeral environment also reduces costs because the environment is destroyed as soon as it's no longer needed.
Configuring GitHub Actions for E2E testing with Release
To integrate Release with GitHub Actions and run end-to-end tests, you can structure your GitHub Action main.yml file into four jobs:
Build and upload the image.
Create the Release environment.
Run E2E tests.
Delete the Release environment.
We'll cover an example of how to do each step below. If you prefer, you can find the entire example config file in our .
Building and uploading your tests as a Docker image
Our first job, build-and-upload, will build and upload the image of our application to test or (as in the example below) fetch the images from a registry. Our example has a backend and a frontend as separate images, so we'll fetch each of those and save them to a temporary directory. We use the latest Ubuntu image from GitHub for this.
We also have some standard GitHub Actions boilerplate to define the credentials we need and define the trigger.
The next job we define is create_environment, and this is where most of the Release-specific configuration needs to be. We pull a Docker image that includes the Release CLI and use it to create a new Release environment. We use the Release Account ID and Release Application ID defined earlier, pulled from our GitHub Secrets.
Note that you'll need to change the command to install the dependencies you need and run your own tests in this step.
Destroying the Release environment
Our last job is to clean up the Release environment once the tests have run. We call the job delete_environment and it uses the Release CLI image. The delete_environment job needs access to your Release Account ID, App ID, and the Environment ID that was created in the previous step.
To integrate Release with CircleCI and run end-to-end tests, you can structure your CircleCI config.yml file into four jobs:
Build and upload the image.
Create the Release environment.
Run E2E tests.
Delete the Release environment.
Building and uploading your tests as a Docker image
Our first job, build-and-upload-image, will build the image of our application to test or (as in the example below), fetch these images from a registry. Our example has a backend and a frontend as separate images, so we'll fetch each of those and save them to a temporary directory. We use a Node image from CircleCI to run this.
We also have some standard CircleCI boilerplate to specify the target version.
version: 2.1
jobs:
# In this example, we are not actually building and pushing docker image
build-and-upload-image:
docker:
- image: circleci/node:13.8.0
steps:
- run:
name: Build and push docker image
command: |
mkdir tmp
echo "Building docker image..."
echo "Push docker image..."
echo "232490755822.dkr.ecr.us-west-2.amazonaws.com/awesome-release/react-express-mongodb/backend:main" > tmp/backend_image.txt
echo "232490755822.dkr.ecr.us-west-2.amazonaws.com/awesome-release/react-express-mongodb/frontend:main" > tmp/frontend_image.txt
- persist_to_workspace:
root: .
paths:
- tmp/*
Creating the Release environment
The next job we define is create-release-environment, and this is where most of the Release-specific configuration needs to be. We pull a Docker image that includes the Release CLI and use it to create a new Release Environment. For this to work, you'll need to make sure your Release Account ID and Release Application ID are in the appropriate environment variables.
Note that you'll need to change the command to install the dependencies you need and run your own tests in this step.
Destroying the Release environment
Our last job is to clean up the Release environment once the tests have run. We'll call the job delete-release-environment, and it uses the Release CLI image and needs access to your Release Account ID, App ID, and the Environment ID that was created in the previous step.
