<p>You may want to use <a href="https://www.terraform.io/cloud" rel="nofollow noreferrer">Terraform Cloud</a> this will allow you to publish your modules from the project repos to a registry and you can then consume these modules from another repo containing the terraform that you use for the IaC deployments you then need to work out what the pipeline triggers for this repo will be.</p>
<p>Terraform cloud will also give you remote storage of the tfstate files and you will need a state per environment that you deploy. Azure DevOps and GitHub (and probably all other CI/CD providers) let you define environments and associate variables with them so you can use these to define which state file and resource group to target along with any other environment specific values you may need to use.</p>

CC BY-SA 4.0
2021-11-12T13:48:41.127Z
I am afraid of having conflicts between diffrent "infra buckets" if they ran on same Azure subscription. How Terraform cloud solves that?
Wojtas.Zet
CC BY-SA 4.0
2021-11-12T15:35:27.503Z
To avoid conflicts you ensure that the pipeline uses the correct state file and resource groups for the "infra bucket". For example, if you have multiple stages for dev, test, prod infra then use a pipeline environment to group the variables for state and resource groups. TF Cloud is more for the module registry (so you can keep the module definitions in the project repo) and remote state storage which makes them easy to consume but you could achieve the same for example by using a blob storage for the state and publish the modules to Azure DevOps Artifacts.
Aquila Sands
CC BY-SA 4.0
2021-12-16T12:55:27.720Z
I'm already dealing with this but in AWS, I had a discussion about this [here](https://devops.stackexchange.com/questions/14470/terraform-organising-modules-code-for-multiple-projects/14472#14472). And you are completely correct you do not need TF Cloud, you can achieve this by yourself with S3 or SA.
Kristian Kanchev
CC BY-SA 4.0
2021-11-11T14:44:27.337Z
2021-11-11T14:44:27.337Z
Aquila Sands
<p>I know terraform a bit, but in the past I worked just with one terraform repository serving all infrastructure (with modules per provider/function).</p>
<pre><code>infrastructure
   |- modules
   |   |- gcp
   |       |- main.tf
   |       |- variables.tf
   |   |- vsphere
   |       |- main.tf
   |       |- variables.tf
</code></pre>
<hr />
<p>Now I have following situation:</p>
<ul>
<li>one Azure subscription</li>
<li>Need for multiple separated infrastructure &quot;buckets&quot; - per 2 different projects, and I would like to separate test/dev (which should be more ephemeral) from production servers (long life).</li>
<li>Need to hand over the infra per project in the future</li>
</ul>
<p>Is it convenient and feasible to have:</p>
<ul>
<li>a bit of terraform code in each project repository, to keep it together</li>
<li>many tfstates on same Azure subscription (one state per each infra bucket) that are isolated on Azure side by (resource groups?)</li>
</ul>
<p>Any advice Guys?</p>

<terraform><azure><terraform-module>
[Multiple projects, one Azure subscription], Terraform - feasibility of distributed configuration
Wojtas.Zet
# [Multiple projects, one Azure subscription], Terraform - feasibility of distributed configuration

(Asked by: username_0 on 2021-11-10)

I know terraform a bit, but in the past I worked just with one terraform repository serving all infrastructure (with modules per provider/function).
infrastructure
   |- modules
   |   |- gcp
   |       |- main.tf
   |       |- variables.tf
   |   |- vsphere
   |       |- main.tf
   |       |- variables.tf


Now I have following situation:

one Azure subscription
Need for multiple separated infrastructure "buckets" - per 2 different projects, and I would like to separate test/dev (which should be more ephemeral) from production servers (long life).
Need to hand over the infra per project in the future

Is it convenient and feasible to have:

a bit of terraform code in each project repository, to keep it together
many tfstates on same Azure subscription (one state per each infra bucket) that are isolated on Azure side by (resource groups?)

Any advice Guys?

**Tags:** terraform, azure, terraform-module


---

## 1 answers

### Answer by username_1 on 2021-11-11. Score: 0

You may want to use [Terraform Cloud](https://www.terraform.io/cloud) this will allow you to publish your modules from the project repos to a registry and you can then consume these modules from another repo containing the terraform that you use for the IaC deployments you then need to work out what the pipeline triggers for this repo will be.

Terraform cloud will also give you remote storage of the tfstate files and you will need a state per environment that you deploy. Azure DevOps and GitHub (and probably all other CI/CD providers) let you define environments and associate variables with them so you can use these to define which state file and resource group to target along with any other environment specific values you may need to use.

> **Comments:**
> **username_0**: I am afraid of having conflicts between diffrent "infra buckets" if they ran on same Azure subscription. How Terraform cloud solves that?  
> **username_1**: To avoid conflicts you ensure that the pipeline uses the correct state file and resource groups for the "infra bucket". For example, if you have multiple stages for dev, test, prod infra then use a pipeline environment to group the variables for state and resource groups. TF Cloud is more for the module registry (so you can keep the module definitions in the project repo) and remote state storage which makes them easy to consume but you could achieve the same for example by using a blob storage for the state and publish the modules to Azure DevOps Artifacts.  
> **username_2**: I'm already dealing with this but in AWS, I had a discussion about this [here](https://devops.stackexchange.com/questions/14470/terraform-organising-modules-code-for-multiple-projects/14472#14472). And you are completely correct you do not need TF Cloud, you can achieve this by yourself with S3 or SA.  

---

