SSW Rules to Better Source Control

Do you know the right source control to use?

SSW uses and recommends Microsoft Team Foundation Server (TFS) as a source code solution. Here are some of the reasons why:

• 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

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

1. Check out
2. Compile
3. Develop
4. Check In
5. Compile

Figure: A Bad Developer

Good Process

1. Check out
2. Compile
3. Run Unit Tests
4. If OK then start developing
5. Develop
6. Compile
7. Run Unit Tests
8. Check In
9. Get Latest
10. Run Unit Tests to confirm everything is working

Figure: A Good Developer

Do you check-in regularly - after completing each piece of work and before lunch/dinner?

Frequently developers work on long or difficult features/bugs and leave code checked out for days or worse still weeks.

1. What happens if your laptop hard drive dies?
2. What happens if you call in sick?
3. How can you pair program if not sharing your changesets?

That's why source code should be checked in regularly. We recommend a check-in:

• Immediately after completing a piece of functionality, where the code compiles and passes the unit tests
• Before lunch or dinner
• Before leaving your workstation for an extended period of time

If the changes would break the build or are in a state that cannot be put into the main trunk, then this code should 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 comment all your check-ins?

When a developer checks in changes a comment should always be put against the check-in. This allows other developers to quickly see changes that have happened without viewing the files changed or the source code to understand what changed.

TIP: You can enforce this as a check-in policy by using the Team Foundation Server Power Tools.

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 should 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

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.

1. 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 schemachange in Source Control.

Do you use shared check-outs?

In conjunction with regular check-ins, files in source control should 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 should 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 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 should 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 should 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)

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. It ensures that you can track changes (and roll-back if required) and isolate and rectify problem coders.

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 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 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

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 configure your TFS to be accessible from outside the network?

It is important to have source control available to you wherever you are, but sometimes when you are working on-site, the client may have strict network policy that VPN is prohibited, or even port 8080 is blocked.

To enable this, you need:

• TFS SP1
• A domain name or IP address forwarded to TFS (eg: tfs.your-domain.com)
• Port 8080
• Port 80 (Optional) – SharePoint portal and Reporting Services

Port 8080 is a common HTTP alternative port, if you have another service using this port, you can consider changing the TFS default port (not recommended), or port forwarding (recommended).