Extreme Programming has already been proven to be very successful at many companies of all different sizes and industries world wide. But the Challenge that most developers might face in agile process is with CVS!

You and the team keep adding and modifying code every day and its most of the times a night mare to manage especially when there are conflicts! Here are some practices that we followed!

When to Commit Code to CVS?

1. As soon a particular feature implementation is complete by a developer the code has to be in CVS before he starts developing a new feature or a fixing a bug.
2. As soon the code is committed to CVS, a mail has to be dispatched to all the team members mentioning the file names committed.

When to Update the code?

As soon as the code is committed, the local build has to be updated unless theres a pressing reason (like a possibility of a conflict etc). Always work on the updated code.

When to create a tag (often known as Version)?

1. Every time you deliver a project for testing - Create a tag in CVS
2. If the Testing team approves the build - Great!
3. If not, Fix the bugs reported by testing team and create a tag again before you deliver to testing again. This is to make sure your code tested is safe in CVS as tags wont allow you to touch them again ( One cannot modify the code in tag.) If the Testing comes up with simple bugs, you could check out the same tag and add the simple fix and go live from there as the rest of the build is already tested. Make sure you tag the build with those simple fixes again.
4. The Idea of tagging is to make sure the code is safe in the repository! You dont have to burden your local hard disk with 'N' number of projects. CVS is the best place to keep your back ups.
5. Create a doc that mentions what features are included and what bugs are fixed and what bugs are yet to be fixed in the builds tagged.
• The Doc should also contain the tag name created and the current development branch name in it.
• Like it should have the date, month and the year on it. (Release_May_01_2010)
• The branch Name from where the tag is created. (Release_7_0_0_)
• Every time a new version is released, the version number is decided basing on the features released in that version. Every bug fix release adds 0.1 and every new feature adds 1 to the previous version number.

When to create a branch?

On Mile Stone Releases. A Mile Stone release could be at the end of a quarter or a major release with Critical features included. (I would suggest at least one branch a year).