Skip to main content
Day to day, changes are made in the dev tenant first. You then update the module to match and roll it out to QA and production.

​
Prerequisites

While terraform plan in dev still shows changes, don’t apply in dev. The module is still the old version, so applying would undo your portal change.

​
A changed resource

Run terraform plan in envs/dev. It lists each attribute that differs, as described in Reading a plan. On each line, the left side is what the tenant has now and the right side is what the module has.
Copy the left-side value into the module and plan again. If the module sets that attribute from a variable, such as webhook_url = var.email_otp_webhook_url, change the value in envs/dev/terraform.tfvars instead. Repeat until the plan reports No changes. For the flow, it’s easier to regenerate the block than to edit it. Use a scratch folder with just the flow’s import, as in Generate code from the dev tenant.
With the dev environment variables set, run:
Then replace the flow = jsonencode(...) part of the module’s block with the generated one. Keep the depends_on lines. Delete the scratch folder when you’re done. -generate-config-out won’t overwrite an existing generated.tf.

​
A new resource

The resources the provider supports, and the import ID each one takes, are listed on the Terraform Registry.
  1. Generate it in a scratch folder with one import block, as above.
  2. Move it into the module, as in Build the module from the generated code.
  3. Add an envs/dev/imports.tf with its module.authsignal. address, as in Import the dev tenant into Terraform.
  4. Plan in dev. Expect 1 to import, 0 to add, 0 to change, 0 to destroy.
  5. Apply, then delete imports.tf and tfplan.
In the other environments, the resource is created, so their plans show 1 to add.

​
A removed resource

Delete it in the dev tenant and remove its block from the module. In dev, the plan has nothing left to do. In the other environments, the plan shows it being destroyed.

​
Roll it out

  1. Commit the module changes and open a pull request.
  2. After it merges, run the QA pipeline.
  3. Check the plan lists only the changes you made. Anything else usually means someone changed that tenant by hand. Find out why before approving.
  4. Approve the apply.
  5. Repeat for production.

​
Edits outside dev

Changes made to existing resources in the QA or production tenants are reverted the next time Terraform is applied there. Anything new added in those tenants isn’t managed by Terraform and is left alone. Dev should be the only tenant anyone edits by hand.
terraform plan -refresh-only in dev lists what changed in the tenant without proposing any changes.