Keeping Track

During all phases of the project you need to keep track of what you did to, in the future, be able to re-create the environment at that given point to understand better how problems were solved.

During the planning phase you need to keep track of your documents and design plans (diagrams, presentations, discussions, etc) and the best place to save that is a Wiki. Wikis are not only easy webpages, they allow revision control of the documents (including attachments), normally they integrate with bug tracking systems natively and can be configured in many ways for each user.

The other benefit of Wikis is that it's web based, so whenever you are, whatever your platform or browser of choice you'll be able to update the documentations, upload and manage attachments and even discuss pages as most of Wiki software available allow forums and bulletin boards within the pages.

Some good open Wikis are MeidaWiki (the one that powers Wikipedia), TikiWiki (a complete Wiki solution), DokuWiki (super simple wiki that powers this website) among others.

During the development phase, the code needs to be well maintained too. Controlling the version of each file separately is not enough, you need to know which versions were current at some day or after some major tests or even during pre-releases Beta1, Beta2 etc. Also, you need to keep track of changes when you're testing some new technology without affecting the current development.

Creating tags let you know the version of all the files for a specific snapshot of the code base. For instance, if you're building the beta version 2 you can tag the codebase as Beta_2 and every time in the future that you need to recreate the beta 2 environment (if someone find a bug on it that reappeared in later versions) you can just checkout the Beta_2 snapshot and you'll have the correct version of every file.

# during beta 2 release
$ cd my_cvs_root
$ cvs rtag -r Beta_2

# Later on... getting the files back
$ cvs checkout -r Beta_2

To split the development you can create branches. A branch is an exact copy of your codebase that won't be changed anymore when you commit directly to the CVS, but will if you specify the branch. To create a branch, first create the split point in the main repository (Branch_1_root) and than the branch itself (Branch_1).

# creating the branch
$ cvs rtag -r Branch_1_root
$ cvs rtag -b -r Branch_1

# on another directory
$ cvs checkout -r Branch_1

Later on, if the technology was successfully tested and will be merged to the main codebase you can merge the changes back to the main repository:

# in the main repository, save state
$ cvs rtag -r Branch_1_beforemerge

# merge
$ cvs update -r Branch_1_beforemerge -r Branch_1

# There will be problems during the merge, fix them manually

# Commit and tag after the merge
$ cvs commit
$ cvs rtag -r Branch_1_aftermerge

Branching in CVS is not easy. It can, in fact, be worse than its benefits and other revision control software such as SVN adn Git solved most of problems of branching and merging. But for one thing the CVS branch is easy, during evolutions of your software. When you're releasing the version 1.0 and the 2.0 needs to be coded before the maintenance period of 1.0 finishes (almost all cases) and you still need to do maintenance in 1.0 but will never merge it back to 2.0, you can safely use branches in CVS.

Just create a branch in CVS called Version_1 and keep the main repository as the 2.0 release. You won't change much the branch code, only fixing eventual bugs and the main development will still be in the main repository, as usual. No big changes, you're still safe with 1.0 and you won't have to face the nightmare to merge lots of sources.

Writing tests help you assure that the same bugs won't show up again but they don't tell you (nor should) why did they happened, how did you fixed and when. That's the role of a bug tracking system. There are plenty of good open bug tracking systems like Bugzilla (from the mozilla foundation), RequestTracker (feature rich and very powerful) among others.

If you build a good structure, set the default assignee for each type of bug and keep the discussions updated, it'll be much easier to report new bugs, get feedback and later on, when something similar happens again you can go back and read the thread again remembering all decisions taken.

Bug tracking tools can also be used for new developments. Although they're not necessarily project management platforms and some other software may be required if you have tighter specifications, they most of the time cover all the basics of the development cycle with projects, milestones, dependency mapping and excellent reports. After the deployment they can also measure how many bugs you had for each new release, how much you spent on them and plan for the future.

The basic features of a bug tracking software are:

• Organize in projects and sub-projects
• Status control: opened, fixing, closed and why.
• History with all comments, preferably maintained via email with CC
• Custom fields that can be searched, sorted and filtered later
• Track estimated and real time per task, milestones, sub-project and project