A production-like environment lets developers test an application under conditions closer to production without exposing customers to work in progress. Local testing comes first, but integrated changes also need testing away from the customer-facing environment. A typical path runs from a development computer through integration and test environments before production. section 12.2.5
Use the environment for two practical jobs:
- Test combined changes before release, rather than relying only on each developer’s computer. section 12.2.5
- Reproduce a bug too complex to run locally. Experiment in the test environment, remove components that do not contribute, then move the smaller problem to development and write a repeatable failing test. section 11.3.1
Separate instances can be created from parameterized Terraform configuration. Set an `environment` variable from the command line and derive `app_name` from it; different environment values then give the application resources different names. This provides a way to provision distinct environments, not a guarantee that every production condition has been reproduced. 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 shows how an `environment` input becomes the application name used for separate instances. section 12.2.5
A local production simulation
Build a microservice Docker image, then use `kubectl apply` to create its deployment, pod, and service in Docker Desktop’s local Kubernetes cluster. This is production-like for trying the deployment path, but remains a simulation rather than a production deployment. section 6.8.9
