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:
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.
We also define a concurrency expression to prevent multiple jobs from running at once, in case commits come in close to each other.
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.
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.1jobs:# In this example, we are not actually building and pushing docker imagebuild-and-upload-image:docker: - image:circleci/node:13.8.0steps: - run:name:Build and push docker imagecommand:| 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.
