Improved Change Detection and Stack On-Boarding for Terraform and OpenTofu

Our latest release of Terramate CLI (0.15.4) and Terramate Catalyst beta adds support for OpenTofu's specific file extension .tofu in Terrramate Change Detection and Stack On-Boarding.

How can you benefit from Change Detection and Stack On-Boarding in day-to-day IaC-related tasks?

What is Stack On-Boarding

Stack On-Boarding is mainly used in Day-0 and is very helpful for new users of Terramate to get started in less than 5 minutes. It allows users to execute a single command terramate create --all-terraform and enhance every repository having multiple Terraform Root Modules with Terramate Stack Orchestration, Code Generation, Scaffolding, and improved maintainability capabilities.

Terramate searches for directories and initializes a stack.tm.hcl file in directories that define a Terraform or OpenTofu backend configuration. That is all it needs to get started and takes only a few seconds.

What is Change Detection

Change Detection, on the other hand, is helpful every day IaC is changed and deployed. It reduces the execution time by identifying changes made inside of stacks and changes inside stack dependencies.

The Terraform and OpenTofu Integration (that now supports .tofu files) scans code inside stacks for references to local TF modules and marks a Terramate stack as changed when there is a change in a local module used.

Changes in remote modules are detected as a direct change to the stack, as the code itself will be referencing the remote version and change when this version is adjusted. Reminder: It is best practice to avoid static references like latest or main that will not be able to detect version updates until downloaded, and can introduce unwanted changes to the infrastructure.

Once all changes have been identified, Terramate allows running commands like terraform plan or terraform apply only in the changed stacks using the terramate run --changed command.

To get a preview of the changed stacks terramate list --changed can be helpful.

Change Detection Benefits for your Teams

This benefits day-to-day tasks in multiple ways:

• Reduced execution time, as not all stacks need to be planned and/or applied, leads to
  • Lower costs due to savings in the required build minutes of CI/CD
  • Improved DORA lead time for changes due to fast reviewability and fast deployments, but also due to faster feedback in error cases when connected to Terramate Cloud to notify about issues and successes.
  • Improved DORA deployment frequency as more changes can be delivered with less time waiting for results. (Note: Terramate Cloud tracks DORA metrics for each deployment with close-to-zero additional effort once Terramate Orchestration is in place)
• Reduced blast radius: It is best practice to split monolithic configurations into multiple stacks so that a deployment of unrelated resources to the cloud does not risk accidentally changing or even destroying a production database or similar hard-to-recover cloud services.
  • Change Detection helps to not execute unchanged stacks in the first place, reducing the risk even further.
• Improved Team collaboration: A broken stack on your main branch does not block other stacks from being changed and deployed, as all stacks are independently planned, executed and applied - especially when you follow a merge-and-apply process. A broken stack can happen due to
  • A failed deployment that produced errors and is being fixed by other team members (when using the recommended merge-before-apply Strategy)
  • A partially applied pull request (when using the merge-after-apply strategy), leading to a drift on the main branch due to in-progress applies and rendering affected stacks as drifted.
  • A detected drift (e.g., when synchronized to Terramate Cloud) does not block adding new stacks or changing other stacks, as we do not require the drift to be resolved before new changes can be applied.

This again improves DORA metrics, as such blockers no longer increase lead time to changes.

The New Way of Doing Infrastructure

At Terramate, we believe in a world where infrastructure engineers can achieve 10x their output while massively reducing tedious & manual Infrastructure-as-Code work. Teams can increase productivity and happiness by reducing complexity without investing a lot of (frustrating) time into refactoring already existing setups. And organizations can remove the infra bottleneck with minimal risk and change, getting their infra ready for the demands of an agentic, enhanced work world without spending a fortune on new resources.