Git Commit Standards for Infrastructure Code

In this blog, you will learn practical commit standards for infrastructure code.

This is also part of my company's onboarding documentation for new team members.

From day one, as soon as they start committing infrastructure code to Git, they follow these standards.

Note: This is an opinionated piece focused specifically on infrastructure code, not application code. Standards may differ across organizations, but I am sharing this based on my experience.

Commit Standards

Usually, when working with infrastructure code, you pick tasks from Jira or other tools. These tasks may come from your own team or as tickets created by different teams.

In either case, a basic commit standard should include the task ID, the action taken, and a brief description of the commit.

[Jira-ID][Action] - Short Description     

Action could be Add, Update, Change, xChange, Delete, etc.

For example,

1. [Add]: To introduce new resources (e.g., add a load balancer).
2. [Update]: For modifying existing resources (e.g., tweaking an EC2 instance type).
3. [Change]: For altering configurations or logic (e.g., modifying a VPC CIDR).
4. [xChange]: For breaking changes that disrupt existing functionality (e.g., removing a legacy subnet routing table).

Example: [CR-135][Add]

After the - or :, add a brief message (50-72 characters ideally) describing what’s being done.

Avoid vague terms like "fix stuff". Be specific.

Few examples,

1. [CR-135][Update] - Modify EC2 instance to t3.medium
2. [CR-152][Change]: Adjust subnet CIDR to 10.0.3.0/24
3. [CR-167][Add]: New S3 bucket for logs
4. [CR-189][Update] - Fix prod bucket policy #deploy-prod
5. [CR-204][xChange]: Kicked out the old server, new one’s the boss now

Why task ID in commit?

Because the task ID ties each commit directly to a specific task or ticket, making it easy to follow the trail from the code change back to the original purpose or requirement.

This is especially useful in projects with multiple contributors or when you are debugging later and need to understand why a change was made

Jira Git Integration

Tools like Jira offer Git integrations that allow you to track each Jira story or task through commit messages.

For example, each Jira ticket (e.g., CR-145) represents a specific infrastructure change.

When a DevOps engineer makes code changes for that Jira ticket, they simply need to include the task ID in the commit message using the standard format mentioned earlier.

By including a task ID (e.g., INFRA-123) in the commit message, Jira’s integration automatically scans and links the commit to the corresponding story, issue, or ticket in its system.

This enables Jira to display details such as the number of branches, commits, and pull requests (PRs) associated with each task.

Here is an example.

This makes tracking changes for specific tasks easier.

If something goes wrong, you can quickly trace it back and collaborate with the DevOps engineer who made the changes.

Over to you.

Do you think commit standards should be mandatory in all DevOps teams?

How does your team define commit actions?

Comment below.