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)