Example structure:
├── workflows
│ └── template.yml
├── versions
│ ├── modules.prod.yml
│ ├── modules.stage.yml
│ └── modules.dev.yml
├── environments
│ ├── prod.tfvars
│ ├── stage.tfvars
│ └── dev.tfvars
├── modules
│ ├── network
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── variables.tf
│ ├── compute
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── variables.tf
├── terraform
│ ├── main.tf
│ ├── variables.tf
│ ├── outputs.tf
│ ├── backend.tf
│ └── provider.tf
└── README.md
└── pipeline.development.yaml
└── pipeline.staging.yaml
└── pipeline.production.yaml
.yml format.workflows folder should be renamed according to the requirements or best practices of the CI/CD tool being used. For example, it can be named .github/workflows for GitHub Actions or .azuredevops for Azure DevOps.workflow folder may not be necessary.pipeline.production.yaml, pipeline.staging.yaml, and pipeline.development.yaml.yml represent pipeline entrypoints for deployment for different environments. When configuring Azure DevOps pipelines, point it to one of these yaml files.production.yml, staging.yml, and development.yml specify module versions or specific configurations that may differ between environments..tfvars) which are used to define different configurations for each environment (e.g., production, staging, development).network and compute.main.tf, variables.tf, and outputs.tf to define the resources, variables, and outputs for that specific module.modules folder may not be necessary.main.tf is the primary entry point where you define the infrastructure.variables.tf defines input variables.outputs.tf defines output values.backend.tf is for backend configuration, such as storing the Terraform state remotely.provider.tf contains provider configurations.A documentation file to describe the project, directory structure, usage instructions, and any relevant details. [^ table of contents ^](#table-of-contents)