Published on October 2nd, 2015 | by Guest

Developer Commits – A Delivery Promise or A Suicide

SVN Commits – Critical Link in the Developer Daily Habits

When the whole engine of an organization orchestrates to deliver delightful and working solutions to our customers, there is one link in the entire chain of SDLC from the “Idea” to “Working Product” – which is very critical and happens almost every hour in the organization.

This event is “Developer commits to source code repository”. At Mahindra Comviva, we use SVN as source code repository and teams (sizes of 2 to 13 developers) working on the same project get to collaborate and work on the “Source Code” – the DNA of the product.

Some of our field issues/defects reported by customers have been due to sheer mistakes of “Code Merge” or “Missing class file” or “Missing configuration Parameter” into the SVN repository. The cost of minor mistake at times results in an executive travelling all the while to site and holding the fort to pacify the customer. This can be termed as “Suicidal commit” and team works to rollback or make “right” commit to get changes working.

Each of us as developers have below choices in our daily commits of code to repository.

Do not check-in/commit the code unless followed up or asked to
Just check-in/commit irrespective of the software state
Check-in/Commit only post testing the new code added/bug fixed
Check-in as in above (3) but with mandatory meaningful log message

A team that has health habit to commit the code with practice of (4) is far healthier team both in terms of quality and productivity than the rest.

While doing commits, the developers need to follow convention that can help rest of the team and the developer himself. Below case demonstrates the way one should commit the code.

$ svn add SendBulkMessage.java
$ svn commit -m “Added: Support for sending messages to recipients in bulk” SendBulkMessage.java

…post adding additional feature to sending bulk messages say storing notifications…

$ svn commit -m “Updated: Support for storing notifications for bulk messages sent” SendBulkMessage.java

…post fixing the bug in the same file if any…

$ svn commit -m “Fixed: Memory leak while sending bulk messages” SendBulkMessage.java

…post modification of existing functionality for performance…

$ svn commit -m “Updated: For loop and Query optimized for performance” SendBulkMessage.java

… post deleting stale code/comments …

$ svn commit -m “Removed: Unused functions” SendBulkMessage.java

As demonstrated above, it would be really helpful if developers follow the convention (daily habit) of committing with prefix pattern as below:

Added: (when adding new features/functionality)
Updated: (when enhancing the current feature/functionality)
Fixed: (when a bug is fixed)
Removed: (when a functionality is removed or code is cleaned up)
Modified: (when existing function is altered)

Once this is done, a simple command of SVN log with filtering would be able to display the entire history of commits being done by the team for a given release.

And if the team does it consistently, CHANGELOG can be auto-generated using this simple habit and team can trace easily the “snippet changes”.

So simple habit of each developer committing the code with meaningful message as in the format above will make difference the way Software Releases can be tracked and made more useful.

Parting thought – should a technical lead always commit code on behalf of newbie’s in the team? No!! Let the technical leads review the code and let each developer of the team commit his/her code. It is healthier learning to work in collaborative mode than a technical leader or project owner committing the code on behalf of the rest of the team

Author’s Bio:

Mahesh Ghatage is a Technical Manager at Mahindra Comviva. His skills are: