Member-only story
Terraform Collaboration and the Problem of Shared Environments
Working collaboratively with Terraform can be unexpectedly challenging — even when team members are making changes that seem mutually exclusive. Despite Terraform’s inherently idempotent nature, teams often find themselves in conflict when they share a single integration environment.
Consider two developers working on separate feature branches: one is adding an Azure Front Door, and the other is integrating Event Hub-based ingestion into Azure Data Explorer (Kusto). If they’re both working in the same environment — say, a shared “dev” integration environment — applying their changes becomes a zero-sum game. One developer runs terraform apply to provision the Front Door, while the other does the same to provision the Event Hub. But because Terraform builds a complete and consistent picture of infrastructure state from the configuration, each application attempt risks overwriting the other’s changes. The Front Door may be removed by the Event Hub deployment and vice versa, creating a frustrating tug-of-war.
This type of churn — where changes are inadvertently undone by others — isn’t the result of malicious intent, but of shared context and incomplete coordination.
