DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Code Inventory and Tracking Releases

10.14.2012
| 6674 views |
  • submit to reddit
You know by now that Code Inventory is something of an obsession with me. Like it or not, most of us, whether developers or sysadmins, work in a service industry. It’s fast and furious, and we don’t have time to build features that nobody wants. With sufficient test coverage, there’s no code that can’t be released within a day of pushing to the repository.

Lettuce seeds by photofarmer
Creative Commons LicenseDwight Sipler

A couple of years ago, I showed you how to Visualize Small Batch Sizes with Git by plotting day-to-day the amount of changed source code lines that hadn’t yet been released to production. While this graph gave immediate feedback about the “drift” of development from operations (live), it’s not something easily digested by upper management. What do these guys really care about? It’s all about the releases silly!

Commits are “Units of Work”

Easily understood and very simple to calculate.

code inventory by release and git commits
Tracking number of code lines changed can easily be misleading with a copy/pasting, package refactoring or adding a new javascript library.

What was in the release?

Clicking on the release shows Pivotal Tracker stories worked on and the actual commit revision ID in github.

contents of release
The PT story types also give a good indication what the main work type was – user features, chores or bugfixes.

Cause and Effect

Now you’re able to show quite clearly to the organization how often you do releases (and even what your releasing). If tagging releases is ‘crawling’, then you are now at the ‘walking’ phase. What would it take to really stretch our legs out and get ‘running’?

Showing the impact of a release is the next logical step. Did you manage to grow traffic? Has the response time of the site improved? See any more bugs after the release? These are all fairly easy to track, and plotting them as a backdrop to the releases demonstrates the real impact your team is having on the bottom-line.

What other metrics make sense here? What would you expect to see? And what would really be kick ass? Share your thoughts on twitter using the #codeinventory hash tag!

Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)