A test environment is a production-like deployment used to check changes without exposing them to customers. It gives developers a place to test integrated changes after local development and before production. Keeping its environment, configuration, and test data close to production makes failures found there more relevant to the customer-facing deployment. section 12.2.5 section 9.3
A practical workflow moves changes through distinct environments:
- Test on a development computer, then test changes integrated with other developers’ work. section 12.2.5
- Deploy to the test environment for a thorough shakedown. Some bugs appear only in a production-like environment. section 12.4.3
- After tests pass, promote changes to the customer-facing environment. A CD pipeline can deploy a test branch to test and a production branch to production. section 12.11
Separate instances can be created by parameterizing Terraform infrastructure. Set an environment variable and derive the application name from it; different values then identify development, test, and production instances. This builds on an existing parameterized Terraform configuration rather than requiring a separate infrastructure definition for each name. section 12.2.5
Listing 12.2 Deriving app_name from environment in Terraform
variable “environment” {} #1
locals {
app_name = “flixtube-${var.environment}” #2
}
The Terraform listing derives app_name from the environment variable, showing the small configuration change used to name separate instances. section 12.2.5
The test environment also helps when a bug is too complex to reproduce on one development computer. Reproduce it there, experiment to identify the components involved, and remove those that do not contribute until the problem is small enough to reproduce locally. A failing automated test can then preserve the reproduction while the fix is developed. section 11.3.1
