5 commit tips to learn from Philips developers if you are using Jira

[#1]

Yakov Yukhnovetsky works as DevOps engineer for Philips, the multinational technology company. His team develops IntelliSpace Genomics - an application built on Philips Healthsuite with workflows for pathologists, oncologists, and researchers. It streamlines collaboration, offers a comprehensive molecular picture, and delivers actionable reports for a better path towards precision care.

He shared some of the rules their developer team uses to keep a disciplined code commit practice that also makes the development process more manageable.

Yakov, how long have you been with Philips?

I joined Philips two years ago and currently I’m a DevOps engineer. After being a C/C++ programmer for ages, I’m enjoying this new phase of my career.

At Philips you maintain a strict commit policy system for the source code of your products. What made you introduce these set of rules?

Before, our developers’ behavior was like in the wild west: they committed code without bothering themselves to add meaningful comments. So, when you looked at a branch’s history, you could see things like a single dot or some vague comments like "fixed".

By looking at the code history, it was almost impossible to understand what work has really been done. We couldn’t match commits with Jira issues and it was absolutely impossible to figure out what was fixed from the last build, or which features were introduced, which bugs were fixed and so on. This dragged down our performance.

We had to look for a solution that could help us maintain a commit history order by enforcing some configurable rules in a friendly but strict way. We found Better Commit Policy for Jira on the Atlassian Marketplace and it was a perfect fit for us.

Better Commit Policy is a Jira app that allows us to create highly customizable commit rules that we can apply to our repositories. We use Git, but you can use it with many different Version Control Systems, including centralized ones. Those rules are then enforced when developers commit code either locally or when they push code to the server.

What are the 5 best rules that work for your team to keep a consistent code change history?

The most effective rules differ from project to project, but I’m happy to give a few highlights from our rule set.

1. The first rule – that I think is a must – is to reference a Jira issue in your commit. No discussion was needed here, I think its importance is obvious for everyone on the team.

2. Then we require the referenced issue to be in "In Progress" status. You know, my boss is a perfectionist and he wants everybody to put issues that we work on in "In Progress" or in "To Do" or whatever the correct status is, so the Jira board truly reflects the current status of the project at any moment.

3. The referenced Jira issue can’t be just any issue, it must also be assigned to the committer. Sometimes people think it’s too much of a restriction, but if you think about it, it’s a very useful practice. It urges team members to always have the right assignees on Jira issues and it also adds clarity to who actually worked on a task.

4. On a more stricter side, we have a rule that requires that the referenced Jira issue must belong to an active Sprint. It makes easier to track the Sprint flow. It’s not something I use frequently, but Scrum masters love it.

5. This is not really a rule, but I would like to mention the ability to bypass the commit policy checks when needed. As a DevOps engineer, I often need to commit small changes, when there is no time or need to document everything I do in Jira. It’s not something that is used by the team, just a nice "maintenance" option for me to sometimes circumvent the rules.

What benefits did your team gain by using Better Commit Policy for Jira?

I think the benefits are obvious: now the work on bugs and features is much more correlated to Jira issues, so the development process is much more manageable. We no longer waste any time on finding what task or reason made a commit necessary.

What's your message to anyone thinking about trying Better Commit Policy?

I absolutely recommend using the local commit verification feature, if you use a distributed version control system like Git or Mercurial.

This way the hook scripts are also installed on every developer's computer and the changes are immediately checked when committed, not only when they are pushed to the server. The advantage of this method is that the developers get used to the rules much faster. They need to pay attention to the commit message every time and can’t ignore it. Fewer mistakes get pull requests approved faster and code reviews more expedited when it's time to merge to production.

Another advantage is that if Better Commit Policy rejects a commit, the reason is also explained in a clearly worded rejection message. So it can be corrected immediately, not days or weeks later when the code is pushed to the server and the details are no longer crystal clear.

A slight disadvantage of the local commit verification is that the hook scripts need to be installed on every developer’s computer individually, which could be a headache to manage and maintain. But it’s still better to do it this way, than trying to figure out why is the push rejected days or weeks later, especially if several commits were pushed together.

Conclusion

This example of the team at Philips shows that discipline in software development is a must, especially if you work on a mission-critical software product.

Organize your code change history by giving Better Commit Policy a try!