Skip to main content

Workflows — The Plan→Apply Ritual

The builder has one habit that makes a hundred villas as safe as one: never build without showing the blueprint first. Teams using Terraform institutionalize that habit into a workflow — a shared ritual for how a change travels from an idea to real infrastructure.

The Plan → Review → Apply Loop​

The loop has three rules:

  1. Plan before you apply — plan shows the full diff at zero risk.
  2. Review the plan as a team — a plan that says "will replace the database" must be seen by humans before anyone types yes.
  3. Apply only after review — in a shared environment, never skip straight to apply.
Remember

plan is free and changes nothing. Use it aggressively; it's the cheapest safety net in DevOps.

Workspaces — The Same Colony in Different Cities​

The builder often needs dev, staging, and prod versions of the same blueprint. Workspaces keep separate state for the same configuration — think of each workspace as a different city where the colony is being built.

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod
terraform workspace list
terraform workspace show
terraform workspace select prod
variable "env" {
  type    = string
  default = "dev"
}

resource "aws_s3_bucket" "archive" {
  bucket = "library-${terraform.workspace}-${var.env}-archive"
}

Each workspace has its own state and its own real resources, so applying in dev never touches prod.

Careful

Workspaces isolate state, not code. A change applied to the dev workspace still runs the same configuration. That's fine for environments built from one blueprint — but many teams prefer separate backend configurations per environment (one S3 key per environment) for stronger isolation.

Git + Terraform — The Blueprint Lives in Version Control​

The .tf files are code, so they belong in Git. But the state and local provider cache do not:

.gitignore
.terraform/
*.tfstate
*.tfstate.*
.terraform.lock.hcl.tfstate
  • Commit: *.tf, terraform.lock.hcl, your module folder
  • Never commit: .terraform/ (downloaded providers), *.tfstate* (state goes to the backend)

This is where Terraform and Git meet: the Git Deep Dive gives you the branch-and-review habits, and Terraform adds the plan-and-apply ritual on top.

The Git-Driven Workflow (Plan in PR, Apply on Merge)​

A production-safe pattern used by most teams:

  1. Make changes on a feature branch.
  2. CI runs terraform fmt, terraform validate, then terraform plan and posts the result in the Pull Request.
  3. Reviewers approve.
  4. On merge, CI runs terraform apply -auto-approve (or with a manual approval step).
Remember

The plan is the reviewable artifact. Never let apply happen without a plan someone has read — in CI or on a laptop.

Terraform Cloud — The Managed Ritual​

Terraform Cloud is the hosted service that turns the whole ritual into a product: remote state storage, built-in locking, run history, and plans/approvals that happen in the UI instead of a laptop. It removes the need to build the CI wiring yourself. For teams that want the workflow without the plumbing, it's worth knowing about.

Back to the fundamentals: the core commands and the state register behind this ritual. Then practice it in the exercises.