Git Commit Standards for IaC

👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

One common issue I have noticed in projects is the use of poor commit messages.

When making infrastructure changes using Git, it is important to write meaningful commit messages. This keeps your Git history clear and easy to track.

In this edition, I will share a standard practice I have been following for a long time.

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.

Commit Standard

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 other 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]: For introducing new resources (e.g., adding 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’re 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.

Friday Fun

If you want some fun, read this Reddit thread where people argue about what makes a "good" commit message.

If you have suggestions or want to discuss, use the comments section in the web version.

I hope I shared something useful this week.

Wishing you a great weekend!