A couple of years ago I fully embraced a coding practice which has proven its value on numerous occasions: maintaining a release Change Log. Not surprisingly, I do it with a Google Spreadsheet. Here's the mechanics of the process:
I start off with an empty document:
Whenever I finish a feature or bug fix and push it to the customer to review, I add a bulleted item in the Notes column.
And when I get more done, I note it.
And even more done, I note that too.
When I finally do a release, I note the date and version and store them in the appropriate columns.
Finally, I insert a new row above the one I was working with, and that's where I'll note my next set of features and bug fixes.
So what does all this buy me?
The fact that it's a Google Doc means that I can easily share this information with anyone in the organization who might need it. It's also something other developers can contribute to with ease. Tracking all the features completed in one place means that I can inform my customer of the exact release contents before and/or after the release is done. Having the date column allows us to relate the releases to other events and reports. The version column allows me to get to a release's exact code contents with ease (svn up -r 2938, and I'm back to the moment right before the release).
I'm always suspicious about adding process or potentially duplicating information. When I started this practice, I had to convince myself that the change log wasn't something I could auto generate from version control or the bug tracking system. By now, however, I'm more than convinced: whatever work this practice had added, it's delivered far more value.
No comments:
Post a Comment