Setting Up a Git Repository for Infrastructure as Code

Infrastructure as Code (IaC) turns server, network and virtual machine configuration into versioned, reviewable files. A well-structured Git repository gives an Australian IT team a reliable change history, repeatable deployments and a safer way to manage VMware environments across a data centre, cloud platform or home lab.

The repository should be more than a folder containing Terraform, Ansible or PowerCLI scripts. It needs clear ownership, predictable naming, documented workflows and safeguards around credentials. Whether your team operates from Sydney, Melbourne or a Brisbane-based home lab, the same foundations make automation easier to maintain.

Define The Repository’s Purpose

Start by deciding what the repository owns. A VMware automation project might manage vSphere clusters, templates, virtual machines, port groups and policies, while a separate repository handles application deployment. Keeping the scope focused prevents unrelated scripts from becoming a difficult-to-navigate collection of operational shortcuts.

Write a concise README.md before adding substantial code. Document the target vCenter instances, supported versions, required tools and the process for making changes. Include the expected timezone for scheduled jobs, particularly when teams work across Perth, Adelaide and the eastern states using different local times.

A useful repository should answer three practical questions: what does the code deploy, how is it tested, and who approves production changes? These details matter in regulated environments such as Canberra government departments and in smaller organisations where one administrator may hold several responsibilities.

Initialise Git With A Clean Baseline

Create the repository locally, configure the default branch and make the first commit only after adding essential housekeeping files:

mkdir vsphere-iac
cd vsphere-iac
git init -b main
touch README.md .gitignore
git add README.md .gitignore
git commit -m "Initialise infrastructure repository"

Use .gitignore to exclude Terraform state, generated plans, local variable files, Python virtual environments, IDE settings and sensitive output. Git history is persistent, so a password accidentally committed to a private repository still needs to be treated as exposed. Rotate it promptly and remove it with an appropriate history-rewriting tool.

Select a branching model that matches your team. Pull requests are suitable for most infrastructure changes, while a small home lab may use a main branch with short-lived feature branches. Protect the default branch, require successful checks and keep commit messages specific enough to explain operational intent.

Build A Predictable Directory Layout

A consistent file structure reduces the time needed to locate variables, modules and environment-specific settings. Separate reusable components from deployment data, and avoid putting every environment into one oversized playbook or script. For VMware, common divisions include inventory, roles, modules, templates and environment variables.

A simple layout could look like this:

.
├── README.md
├── .gitignore
├── ansible/
│   ├── inventories/
│   ├── playbooks/
│   └── roles/
├── terraform/
│   ├── modules/
│   └── environments/
│       ├── lab/
│       └── production/
├── powershell/
└── docs/

Core repository conventions

• Use lowercase names with hyphens or underscores consistently.
• Keep reusable modules separate from environment configuration.
• Store examples in files such as terraform.tfvars.example.
• Record tool and provider versions explicitly.

For teams supporting both a Melbourne office and a Sydney colocation facility, environment directories make differences visible without duplicating every module. The same approach works for a local NBN-connected lab and a production platform hosted in an Australian cloud region.

Protect Secrets And State

Never commit vCenter passwords, API tokens, private keys or encrypted state files without understanding the protection model. Use environment variables, a secret manager or the credential facilities provided by your automation platform. Ansible Vault can protect encrypted variables, while Terraform state should use a secured remote backend with access controls and locking.

Separate sensitive values from ordinary configuration. A committed file should describe what a deployment needs, not reveal the credentials used to perform it. Add pre-commit scanning with tools such as Gitleaks or detect-secrets, and make secret scanning part of the pull request pipeline.

State deserves particular care because it may contain IP addresses, resource identifiers and provider data. Restrict access according to job responsibilities, enable encryption in transit and at rest, and establish a recovery process. Australian organisations should also align storage and retention decisions with internal governance and applicable privacy obligations.

Make Changes Easy To Review

Infrastructure code should be readable by someone who did not write it. Use descriptive variable names, comments for unusual decisions and small modules with a single purpose. Pin provider, collection and package versions so a future run does not silently introduce a breaking change.

For VMware practitioners, Ansible vSphere deployments provide a useful model for separating automation logic from inventory and variables. A similar principle applies when PowerCLI scripts are stored beside documentation: include the expected parameters, permissions and rollback procedure rather than relying on tribal knowledge.

Checks worth automating

• Format and lint Terraform, YAML and PowerShell.
• Validate syntax and provider configuration.
• Run unit or molecule tests where practical.
• Generate a plan for review before applying changes.

Review details to record

• The target environment and expected impact.
• Any maintenance window or service dependency.
• The rollback or recovery method.
• The person responsible for the deployment.

A pull request should show the proposed infrastructure difference, not just a code diff. Require an approval from an appropriate technical owner, especially when the change affects shared clusters, production networking or systems supporting customers in the Australian market.

Connect Git To Deployment Workflows

Once the repository is stable, connect it to a CI/CD platform such as GitHub Actions, GitLab CI or Azure DevOps. A typical pipeline checks formatting, validates configuration, scans for secrets and produces a plan on every pull request. Applying changes should normally be a separate, protected job that requires approval.

Use separate credentials and permissions for validation and deployment. A read-only identity can inspect vCenter during a plan, while the apply job receives narrowly scoped write access. Store those credentials in the CI platform’s secret store rather than in repository variables committed alongside code.

Document how to respond to failed jobs, drift and urgent changes. A controlled break-glass process is safer than allowing administrators to bypass Git whenever an incident occurs. For teams operating on AEST or across multiple Australian sites, include maintenance windows in UTC as well as local time to avoid scheduling mistakes.

A repeatable virtual machine workflow can also benefit from a clear build reference such as this VMware build guide. Adapt the principles to your platform, then commit the resulting configuration and operational notes so future rebuilds do not depend on a single administrator.

Create the repository, add the README and ignore rules, then commit one small, validated change. Build the checks gradually and document each decision as the automation grows. This gives your infrastructure a dependable source of truth that can support a home lab today and a production VMware estate tomorrow.