How to Build Software Defined Test Environments with Codeherent’s Terraform Integration

Testing software with permanent Test Environments can be problematic for a whole host of reasons, not least of which is lack of knowledge of configuration and the tendency for such environments to develop a Snowflake Configuration as they inevitably evolve over time. Codeherent’s Testbay module can help to combat these issues by providing the tools to easily build and destroy test environments on demand through its integration with Terraform.

If you’re familiar with Testbay’s custom workflow system, you might already know that you can use it to trigger external tasks such as running a Jenkins job or raising a Jira ticket. We’ve now added two new action types to this system: Terraform Create and Terraform Destroy. These actions can be used to build replicable, immutable, software defined test environments. A typical workflow involving Terraform might look something like this: Build -> Test -> Destroy. Here’s how you might do this:

Create the Workflow

Building a workflow which leverages Terraform is simple. After adding an appropriate name, create a Build stage and add an new action, for Action Type select Terraform Create and fill in the Terraform configuration for the resources that you would like the action to build. Here we are building an EC2 running Ubuntu as described in the Terraform getting started guide. Notice that we are not providing our AWS Access Key ID and Secret but rather a reference to a secret. Codeherent understands the string “$aws.awsAccessKeyId” to mean use the variable “awsAccessKeyId” from the integration “aws” and will automatically inject these secrets when required. These secrets are configured within the Admin portal. We’re currently working on a much more extensive secrets system that will support more generic secrets.

We also create a Destroy stage, with an action to destroy the environment. To destroy the environment simply select the Terraform Destroy action type, no payload is required. Codeherent automatically associates any resources built in prior stages with the current workflow run i.e the environment booking / request. This stage will destroy all resources built in prior stages and remove all state data.

Future Work

We’ve only just scratched the surface of what we can do by leveraging Terraform and have many more features in the pipeline. Short term we intend to add support for Hashicorp’s HCL (the default configuration language now used by Terraform, currently Codeherent Terraform actions only support JSON form). Furthermore, we also plan to add a selection of default templates for users to select from as well as add support for configurations defined withing version control.