Version control records infrastructure configuration changes so teams can compare revisions, preserve context, reproduce environments, and maintain a source of truth. In an infrastructure workflow, configuration or scripts are committed before automated deployment and testing. section 1.2.2 section 2.4
Use version control to make infrastructure changes understandable and recoverable:
- Commit configuration changes rather than relying on manual edits, allowing infrastructure state and intended configuration to remain aligned. section 1.2.2 section 2.4
- Write commit messages about why a change is needed and how it affects other infrastructure; the configuration already records what changes. section 2.3.1
- Prefix commits with issue or ticket identifiers when traceability is required, linking implementation history to a requested change. section 2.3.1
- Keep secrets as variables instead of committing them in plaintext, and structure scripts around reproducible create, read, update, and delete actions. section 2.4
Documenting a firewall change
A firewall rule allowing app-network to reach shared-services-network can be committed with a message explaining that the application needs queue access. Adding an identifier such as “TICKET-002” makes the change easier to trace and reconstruct later. section 2.3.1
For collaboration, teams may isolate changes in feature branches or merge frequently through a trunk-based workflow. Feature branches support isolated testing but can become long-lived and conflict-prone; trunk-based development exposes conflicts earlier but depends on a dedicated testing environment. section 7.5 section 7.2.3
