Software Maintenance: tools

If there's one thing I've learned in my years as a Support Manager, it's that tools are critical.

We could just depend on the heroics of individuals, but why waste their time doing tedious, time-consuming tasks, when they could be developing new product features, or fixing bugs?

The biggest three that I've seen are the following:

Bug tracking/code management - I list these two together, since I believe it's ridiculous to separate them. When you go looking at a bug or an issue, or a new feature (it's just a number in the system), you can see the code committed against that bug/issue/feature. If you're not doing this, you're probably doing it wrong.

eServGlobal (a former employer of mine) originally used bugzilla and CVS. They developed a bit of glue, which was written as perl code for hooks into CVS that automatically added links and information into Bugzilla. This was called "cvszilla" and is still open source and works with Subversion/SVN as well. Github (where almost everyone seems to be holding their open source code these days) has something similar where individual projects can have "issues", which can be closed by code commits.

I would be keen to hear other people's experiences with this kind of system, which is, as far as I can tell, essential for both Software Development and Software Maintenance.

Customer Audits/Release Management - auditing customers or their release machines was one of the smartest things my team has ever did. It saves ridiculous amounts of time. All that's required is a script that runs on a target machine that collects data, checksums of binaries, config files, hardware data, software installs etc.. etc... and reports it back to you. Ideally, it's collected automatically and periodically after there have been any changes. Still, it would be ok if you can request these from the customer (the way Microsoft do with Word for example). When we did this at eServGlobal, the changes were checked into the code management system so they could be viewed just like the rest of the code. You could also see changes to customer configuration that had happened. It was very useful. This was key in several other time saving developments later on.

The reasons release management is mentioned here, is that when you release software/scripts/database changes and so on, it makes sense to track details of these and match them up against the audit data. That way, you're a click away from finding the source code for the system you are maintaining or upgrading.  We did this as a web page, and checksums were the heart of it, i.e. a binary checksum is, essentially, unique and must have come from a specific delivery, and we had the code tags for each of these on hand and easily searchable.

Typically, a customer reports a bug, you want to know what you are looking at. Sometimes, customer details/audit is enough, or your release tracking and application deployment is good enough that all you need is the customer name and you're good to go. This wasn't the case in any of my previous environments. You need details from the target machine, since people change things, or deploy binaries or scripts that either haven't been tracked or might be tracked somewhere else in your system, but don't show up in the install logs/details.

You might think, "Our system is simple enough", or "We only have 3 customers" or something, but believe me, putting in tools like this is well worth your time. It's not that much development time from a single, keen developer to put these into place.

Release Tracking - it's worth having a separate tool for tracking individual releases. If you are releasing emergency binaries/jars or scripts, then automate the release so that an entry is put into a tool/system that lets you see the release and its release notes from your release tracking screen. Ideally, if this is released for a specific customer, those details would appear as well.

From the release tracking screen,  you'd like to see all the details from as many different perspectives as possible, how many releases have been installed by a customer (tie this in to the auditing system mentioned above), a summary of all releases at a customer, which emergency interventions have gone to that customer, what bugs they've had reported in their environment and so on.

Ideally, tools give you the details you need when you need them at each step of the maintenance process.