When two people deploy Terraform changes from separate laptops, state locking prevents simultaneous runs but does not stop one person from overwriting changes the other has not pulled. GitOps replaces those competing deployment points with a shared Git repository as the source of truth and centralized deployment from its code. section 8.2.1 section 8.3
A GitOps-managed system expresses desired state declaratively, keeps a versioned and immutable history of it, has agents pull that state automatically, and continuously reconciles the running system toward it. “Continuously” means reconciliation keeps happening, not that every change is corrected instantly. Terraform supplies declarative configuration and can reconcile differences, but it needs a larger system to run reconciliation continuously. section 8.3 section 8.3.2
A practical path from proposed change to deployment is:
- Pull the current code, create a branch, and test locally; temporary environments can be deployed from a local machine for testing. section 8.3.1
- Open a pull request. Run automated tests and a speculative Terraform plan, address failures and review feedback, then obtain approval. section 8.3.1
- Merge into main and deploy from main. Keep tests, validation, linters, and security scans in the workflow: automated deployment without those safeguards makes mistakes harder to catch. section 8.3.1
Deployment on merge is not enough for continuous reconciliation: infrastructure can drift afterward. A Terraform plan can detect differences, and applying it can correct them. A CD platform can run checks on a schedule; teams concerned about unreviewed changes may enable drift alerts without automatic correction. section 8.3.2 section 8.6.4
