-
Do you know the benefits of using source control?
Using Source Control software (we use TFS) allows you to share project code between
team members. But the best things is it ensures that you can track changes (and
roll-back if required) and isolate and rectify problem code (or coders :-)).
-

-
Figure: Use annotate to understand (or find the guy) to understand his thoughts
before deleting/changing someone elses code.
-
Do you know the right source control to use?

SSW uses and recommends Microsoft Team Foundation Server (TFS) as a source code
solution.
-

-
Figure: Microsoft Visual Studio Team System
Here are some of the reasons why:
- Checkin policies
- Integrated Work Items and Source control
- Visual Studio IDE integration
- Code Metrics
- HTTP access via webservices
- Integrated Build Server
We also use Subversion (SVN) and Visual Source Safe (VSS) as needed
-
Are you very clear your Source Control is not a backup repository?
Only check-in code that is compiling and unit tests are working.
Note: If you are not finished working:
- TFS put changes into shelfset
- SVN put changes into branches
-
(Before starting) Do you follow a Test Driven Process?

Never allow a situation where a developer can check out code and the code does not
compile – or the unit tests are not all green. This is called “breaking
the build” and the punishment in our office is 20 pushups and fixing broken
links for an hour!
- Bad Process
- Check out
- Compile
- Develop
- Check In
- Compile
-
Figure: A Bad Developer
- Good Process
- Get latest
- Compile
- Run Unit Tests
-

-
Never check out until the unit tests run
- If OK then start developing
- Check out
- Develop
- Compile
- Run Unit Tests
- Check In
- Get Latest
- Run Unit Tests to confirm everything is working
-
Figure: A Good Developer
-
(After work) Do you only check-in code when it has compiled
and passed the unit tests?

Too many people treat Source Control as a networked drive. Don't just check-in when
the clock ticks past 5 or 6 o'clock. If code doesn't pass its unit tests or won't
even compile, you will either put it in a
shelveset if possible or comment out the code and check the file in.
If you're using c#, you can use the #warning directive to create a build warning
to remind yourself to fix up the code:
-
#warning Fix up this code
//Broken code
-
Figure: Using the warning directive will allow you to find broken code easily later
on
-
(Check-in regularly) Do you keep chunks of work small, check in after completing
each chunk of work (which should be before lunch and dinner)?

Frequently developers work on long or difficult features/bugs and leave code checked
out for days or worse still weeks.
- What happens if your laptop hard drive dies?
- What happens if you call in sick?
- How can you pair program if not sharing your changesets?
That's why source code will be checked in regularly. We recommend a check-in:
If the changes would break the build or are in a state that cannot be put into the
main trunk, then this code will be put into a
shelveset (sometimes referred to as 'sandbox') in source control.
Another good reason to check-in regularly is that it makes it easier to merge your
changes with other developers. If all developers check-in lots of changes in one
go, you will spend a lot of your time resolving conflicts instead of doing work.
TIP: How can you enforce regular check-ins? Monitor them using a
report to see who has not checked in.
-
Do you enforce comments with check-ins?
Team System is great, but there are some standard features in other source control
systems that aren’t available. One of the glaring omissions is enforcing comments
when checking in code. Without comments, some of the other built in features like
History become redundant without comments.
-
-
BAD: No Comments against the check-ins we don’t know what changes were made
in each revision
-
-
GOOD: Now we can pin point which revision a particular change has been made
To enforce this behaviour, you will need to:
- Install Team Foundation
Server Power Tools v1.2
- Right click the Team Project in Team Explorer > Team Project Settings > Source
Control
-
- Select the Check-in Policy tab
- Click Add
- Select the Changeset Comments Policy
-
Now the next time someone checks-in some code, they are forced to enter a comment.
-
Do you know the comment convention you should use?
New, Bug or Refactor should be the prefix.
Here are some examples:
- New P112: Added a new control for DateOfBirth
- Bug P113: Fixed validation to now allow US dates
- Refactor: Moved the email regex from inline to a resource file
-
Do you know the best Project/Version conventions?
/northwind
/trunk
/branches (or shelvesets)
/experiemental-feature1
/releases (or tags)
/1.0.0.356
-
Figure: TFS or SVN conventions
-
Do you label your versions and releases in Source Control?
TFS takes labeling to a new level unlike VSS which was a point in time label. TFS
labels each file based on their changeset version. You can then get code as it was
when you labeled the source.
Labeling a release is a good way to go back to a version and generate a compiled
version. If you wanted to develop an older version then you would create a branch
instead (of course you can create a branch off a label)
-

-
Figure: Get a specific version in TFS based on a label
-
Do you know how to structure your version numbers?
- Major - rarely change - only with major upgrades, new platform - (e.g. office 2007)
- Minor - new features / release (customer facing) - 3 months
- Revision - starts at 0, in ideal world, we have 0. Emergency maintenance or security
patches to the customer
- Build - internal build number for QA to differentiate (auto updating)
See SSW Rules - Rules To Better
Code
-
Do you check-in all files?

When working on a task spanning multiple files, do not check-in only one or two
of the files, this leads to the problem of partial check-ins where references to
new classes or methods are unavailable because they are in the files that haven't
been checked in. So either, check-in all the files you are working on or none at
all if you aren't finished working on the task.
- Make Visual Studio remind you to check code in
In Microsoft Visual Studio. NET sharing project code can be configured by ticking
the two checkboxes on top, in Options (from the Tools menu) as shows below.
-

-
Figure: Check-in files automatically the 2nd checkbox is very important so you get
reminded to check-in your project when closing VS.NET. You know how frustrating
it is when you want to fix an application and all the files are checked out by some
one else!
What about VB6 applications ?
In Visual Basic 6 this is done by going through Tools -> Source Safe -> Options
and setting it as shown in the diagram below.
-

-
Figure: You can also check-in automatically in VB6
What about Access applications ?
We also use VSS for Access projects. Access 2000 had problems with MDBs (not ADPs)
but Access 2003 works fine with both. The only thing you have to be careful of is
that if a form is not checked out, it still lets you modify the form, but when you
close the form, it rolls back to the VSS version and you lose all of your changes.
-

-
Figure: You can also check-in automatically in Access
-

-
Figure: All the basic functions are easily accessible.
Note: Using VSS in Microsoft Access has a few limitations, most significant of which
is the inability to reattach to VSS projects. Once you have detached from
a VSS project, you will need to create a new VSS project in order to place the Access
application back into VSS.
What about SQL Server Databases?
We save the scripts of every SQL Server schema change in Source Control.
-
Do you use shared check-outs?

In conjunction with regular check-ins, files in
source control will never be locked unless absolutely necessary. Use either 'Unchanged
- Keep any existing lock' - or 'None - Allow shared checkout'.
Only use 'Check Out - Prevent other users from checking out and checking in' when
checking out binary files e.g. Word documents or third party compiled dll’s.
(This will be the default this will be the selected option due to the inability
for binary files to be merged on check in.)
-

-
Figure: Correct checkout settings at the file level - don't lock files
Do not enforce single check-out at the project level - make sure the 'Enable multiple
check-out' option is ticked under Team Project Settings, Source Control.
-

-
Figure: Correct check-out settings at the team project level - enable multiple check-out's.
-
Do you have a report to see who has not checked in?
Managers will regularly check to see if developers are committing their changes
into source control. In TFS you can only get a status by manually looking at each
project or running "tfs status" command. A great tool is
Attrice Team Foundation SideKicks which can display the status of all users
and projects
-

-
Figure: Use TFS Sidekicks and search for files older than 48 hours to find the naughty
boys.
-
Suggestion for TFS Sidekicks: Add a button to “Email all people their shame
list”…. showing their files that are still checked out (until then I
do it manually)
-
Do you only check out the files that you need?
Checking out files that you do not plan to modify could confuse other developers
on what is currently being worked on , as well as making it difficult at check-in
time to see what files you actually have modified.
-
Do you avoid limiting source control to
just code?
You can spend valuable developer time on every part of a project. The bulk of time
is normally spent on coding up .cs, .vb, .resx and .aspx files. However, you could
potentially have the following happen if you do not include other files in source
control:
- lose work
- lose old versions of work
- have work overwritten
In particular, you will make it as easy as possible to see who changed what and
who deleted what and allow a simple rollback to previous versions of non-code files.
Files you will put in source control include:
- XSL files
- Word documents
- Excel Spreadsheets
- Visio Diagrams
- HTML files
- Image files, Flash animations and psd
files (yes this takes room in your source control database - but we still
want to be able to revert to an old version easily)
Things you don't store are:
- Video files eg. avi
- Installers eg. .msi
-
Do you include original artworks in Source Control?
Your original digital artworks are part of your asset and they also need to be managed
accordingly. However many organizations fail to realize this and issues starts to
arise when you need to roll back your images only to discover that the designer
has overwritten the old images or worse, the image was designed spontaneously and
the original design was exported to a .jpg or .gif without the original design being
saved! Including your original artworks in SourceSafe can be handy in case of hard
drive failures or accidental deletions.
-

-
Figure: Include your original artworks in Source (eg .PSDs in Source Control)
We chose to exempt uncompressed video files as they tend to have large footprints
and potentially cause delays in productivity. It is highly recommended that you
have a separate backup procedure for these files.
-
Do you know how to rollback changes in TFS?
Whilst working on a new feature all morning I’ve realised that this isn’t
going to work out. I need to revert back to what the code was this morning before
I touched it. But how?
There are two ways to do this:
- If you haven’t checked in any files since you started modifying them then
the process is simple:
- Right click your solution and Undo Pending Changes
-
- If you aren’t so lucky and have made some commits along the way then the only
option is to use the Rollback command.
- To use this you will need to install Team Foundation Server Power Tools v1.2
- Find the revision before you started checking code in using the History command
-
-
Figure: The last revision before Tristan made changes was 5367
- Open the Command Prompt in your current working directory and type “c:\Program
Files\Microsoft Team Foundation Server Power Tools\tfpt.exe” rollback /changeset:5367
-
- Click Yes and the rollback will proceed
It would be nice if there was a GUI for this tool so that I can just right click
and select rollback. See
Better Software Suggestion – TFS
-
Do you configure your TSWA to be accessible from outside the network?
The content is quite the same like the TfsExternal, except that it’s not TFS,
but TSWA. So mention:
- Download and install TSWA from http://www.microsoft.com/downloads/details.aspx?FamilyID=c568fba9-3a62-4781-83c6-fdfe79750207&displaylang=en
- Port forwarding
-
-
Figure: Visual Studio Team System Web Access Power Tool
-
Do you configure your TFS to be accessible from outside the network?
It is important to have source control available to you wherever you are, so that
means than VPN access is not enough. This is because sometimes when you are working
on-site, the client may have strict network policies that block VPN or even port
8080 is blocked.
Tip: You can slove this with TFS Extranet Support:
- TFS SP1
This feature called "Extranet Support" was added way back in TFS 2005 SP1 as per
Stuff in the pipe
for Team Foundation Server
- A domain name or IP address forwarded to TFS (eg: tfs.your-domain.com)
- Port 8080 (this is port that TFS uses for source control)
- (ideally) a firewall/router rule
Yes Port 8080 will work in most cases but not on the strickest networks, where only
Port 80 is allowed.
Then you have to use port forwarding via a firewall/router rule (recommended) to
forward port 80 to the TFS port, while in this way, you would lose the TFS SharePoint
Portal and Reporting Services.