A Safe Team Workflow

Scenario: Two pull requests both pass validation, but applying the first invalidates the second plan.

Collaboration needs shared state, locking, version-controlled configuration, a consistent runner, identity, plan review, and serialized apply. Plans are snapshots: merge or infrastructure changes can make them stale. CI should format, validate, lint/test, initialize deterministically, plan, publish the full diff securely, require appropriate approval, then apply the reviewed artifact or generate a controlled post-merge plan.

Analogy: A flight checklist and control tower coordinate competent pilots. Skill alone does not prevent two aircraft using the same runway.

A worked configuration

terraform fmt -check -recursive
terraform init -input=false
terraform validate
terraform plan -detailed-exitcode -out=change.tfplan

Use exit code 2 from -detailed-exitcode to distinguish changes from errors. Restrict secrets and plan artifacts, cancel superseded runs, and ensure only one system is authorized to apply a workspace.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-remote-state-locking Terraform lab. Open /labs/terraform and choose slug tf-remote-state-locking; the lab runs real Terraform against the offline FakeCloud provider.