A production environment and a short-lived feature environment can use the same Terraform code without being the same deployment. Each deployment is a distinct workspace: it has its own configuration and state, the record of resources Terraform currently manages. Multiple deployments can share a backend while keeping their state in separate locations. section 1.2.6 section 1.2
Deployment also names the act of changing that infrastructure. Running `terraform apply` locally or through automation runs a deployment. The result is not merely a new bundle of files: it is the managed infrastructure and an updated state. Because infrastructure may be in use during an upgrade, even a limited change carries risk. section 8.2.1 section 8.2
One environment, one deployment path
Suppose two teammates make changes to a long-lived environment. If both apply from their laptops, state locking prevents simultaneous jobs but does not prevent one person from deploying without the other’s code. Instead, they push changes to a shared Git repository and let a centralized system deploy from that source of truth. Local applies remain useful for a temporary environment used by one developer. section 8.2.1 section 1.2.6
A reliable deployment path needs more than an apply command:
- Give the deployment runner credentials and network access to every platform it must manage, including private environments. section 8.2.4
- Queue changes to the same environment rather than running them concurrently, and allow for resources that take a long time to create or modify. section 8.2.4
- Use CI checks and automation to support frequent, small deployments without manual steps during the run. section 8.2.3
