Source Control and Team Development Part 4

See previous parts here

The Only Chapter

In the first meeting, you defined a set of features, classes, and functional tests. You got Class A and Class B. You go home. You start writing a set of unit tests for your features. You write a skeleton of your classes. Just empty functions that returns dummy values. You compile, it compiles fine. Now you Check-In your files to the Source Control Server; just a single click. Before the check-in starts, unit tests are run, of course non of them are passed; you only have skeleton classes. Now check-in is complete. You go to sleep.
Next day you wake up, open you PC, in your home. You click "Update" to get the latest version of other people source code. Then you continue developing your classes. You implement seven functions. You compile, test, and find that 30% of tests have been passed. You check-in your code with a message stating a description of the change.

After 3 days, you find that some previously-passed tests have failed. You browse the history of the class that have failed the test, you click a single button and you have a side-by-side view of the current file version and the last-working version. The changed lines are highlighted for you. You compare only 3 lines, and decide to change one of them, and viola: that test have been passed again. You check-in your code with a message stating the correction.

Now you go to the second failed test, you remember that you have made a change that corrected that before and that maybe you have removed that change forgetting what it was for. You perform a search of the check-in messages using the keyword you used for that change, you got the file version that has that bug corrected, the exact lines that you changed to fix that bug is highlighted for you. You fix the current version with that code, and here it is; the test have been passed. You check-in your code with a message saying that you re-fixed that bug again.

Someday you find something inside someone else's code that preventing your code from working. You fix it in his file. You check his file in with a message describing your change. When he checks-in his file with different changes, the server merges both of your files if you haven't modified the same lines. The server lets him know that he doesn't have the latest version and that a merge will happen, he previews the merge and approves it.

The big day has come. You sit together, you don't have anything to do. The project was already integrated each day, and all the tests have been passed, you just go to college and get the maximum grade and go home having 4 feelings:
1- I love programming
2- We CAN make things right
3- I WANT to make a much bigger project next time
4- "Weeee are the champions"

See:

Test-Driven Development
Source Control

Other team management stuff:

Scrum

Other development techniques:

Extreme Programming (XP)

Finally, this is all about Agile Software Development

Big thanks to the MDC 2007 ;)