Rules to Better Version Control With TFS ( AKA Source Control )

Microsoft Gold Partner Logo
Search Go Search
SSW Rules/Team Foundation Server (TFS)/Rules to Better Version Control With TFS ( AKA Source Control )

 Rules to Better Version Control With TFS ( AKA Source Control )

Hold on a second! How would you like to view this content?
Just the title! | A brief blurb! | Gimme everything!
  1. Are you very clear your Source Control is not a backup repository?

    This field should not be null (Remove me when you edit this field).
    Note: If you are not finished working:
    • TFS put changes into shelveset
    • SVN put changes into sandbox / branches
    Note: Another way to do this is to enable gated check-in and prevent check-ins that do not have build and tests passed.
  2. Do you know the benefits of using source control?

    Source control is your backup of your code, as well as your change history to track changes.
    With the source control (we use TFS), we can share project code and cooperate with other team members. Using it allows us to track changes, compare code and even roll-back if required. Moreover, it keeps our code safe that is the most important.
     Figure: View the changes in source control on each individual file Figure: We can select different changesets and compare the changes Figure: We can select different changesets and compare the changes. Blue = modified, Green = addition, Red = deletion
    Figure: Right click file and select Annotate to view the history on a segment basis Figure: Use annotate to understand (or find the guy) to understand his thoughts before deleting/changing someone elses code Figure: Annotation is great, but it gets even better when one click gives you the 'check in comment' and the 'work item'

    Don't just fix the problem, see who caused the problem and correct them.
    - Adam Cogan

  3. 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
    Reasons companies choose Visual SourceSafe (VSS)
    - No server required
    - No VPN required
    - They are ignorant about the potential corruption problems
    Figure: Bad Example, Visual SourceSafe (VSS) is a bad choice

    Reasons companies choose Subversion (SVN)
    -It's free
    -It's easy to use
    -No Build integration
    -No Work Item integration

    Figure: Better example, Subversion (SVN) is an OK choice
    Reasons companies choose Team Foundation Server (TFS)
     -It's free (With MSDN)
     -It's easy to use
    -It's easy to install
    -High fidelity SQL data store
    -No VPN required
    -Does not require a server (basic configuration)
    -Has Build integration
    -Has Work Item integration
    -Has Test suite integration
    -Has reporting out of the box
    Figure: Better example, Subversion (SVN) is an OK choice

  4. (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 push-ups and fixing broken links for an hour!
      Bad Process  
    1. Check out  
    2. Compile  
    3. Develop  
    4. Compile  
    5. Check In
    A Bad Developer Figure: Before you start cooking prepare all your ingredients (aka before you start coding, "Get Latest" the right way)
      Good Process
    1. Get latest
    2. Compile
    3. Run Unit Tests
    4. If Tests pass then start developing
    5. Check out
    6. Develop
    7. Compile
    8. Run Unit Tests
    9. Get Latest (Always do a Get Latest before checking in as code you didn't change could break your code)
    10. Compile
    11. Run Unit Tests
    12. Check In if all tests passed
    13. Wait for gated check-in (GC) to complete
    14. Reconcile your workspace if it was successful
    15. Check that Continuous Integration (CI) build was successful(If GC was skipped)
    A Good DeveloperNote: You should have both a Gated-Check-in (GC) and a Continuous Integration (CI) build on every branch.
  5. (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 put your code in a shelveset
     Figure: Put your dishes straight in the dishwasher otherwise you leave a mess for others (aka "Check in" the right way otherwise you give other developers problems) Other recommendations have included using //TODO or commenting the code out. However we recommend avoiding this practice as it increases the risk that the code is forgotten about.
    Note: Having gated check-ins will help prevent this from happening.
    Note: A useful tool is TFS Auto Shelve - Protect your code by guaranteeing your pending changes are always backed up to the TFS server.
  6. (Check-in before lunch and dinner) Do you work in small chunks & check in after completing each one?

    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?
     Figure: Eating one big meal every three days gives you a bellyache... (aka check in small portions regularly, one large check-in after a few days will give you a headache)

    That's why source code should 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 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.
  7. Comments - 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.
     Figure: Bad Example: No Comments against the check-ins we don’t know what changes were made in each revision Figure: Good Example: Now we can pin point which revision a particular change has been made

    More Information
    To enforce this behaviour, you will need to:

    1. Install Team Foundation Server Power Tools
    2. Right click the Team Project in Team Explorer > Team Project Settings > Source Control
    3. Select the Check-in Policy tab
    4. Click Add
    5. Select the Changeset Comments Policy
    Now the next time someone checks-in some code, they are forced to enter a comment.
  8. 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
  9. Do you enforce work item association with check-in?

    One of the big advantage of using TFS is end to end traceability, however this requires the developer to do one extra step to link their code (changeset) with requirements (work items). Code is the body of software, while user requirement is the spirit. Work Item association feature helps us to link the spirit and body of software together. This is especially useful when you trying to identify the impact of a bug in term of user requirements.

    No work item associated
    Figure: Bad Example: No work item is associated with changeset
    work item associated
    Figure: Good Example: No work item is associated with changeset

    More Information
    In order to achieve this, developers need to choose the Work Item tab when check-in and "associate" code with a related work item.

    Work item association
    Figure: Associate Work Item with Changeset

    As the project administrator, you can take one step further to enable "Work Item Check-in Policy" to enforce this rule in your team.

    Work Item Check-in Policy
    Figure: Always enable the “Work Items check-in policy”
  10. Do you know which check-in policies to enable?

    Check-in policies are a great tool to enforce quality code before it hits your source control repository. SSW recommends that the following check-in policies be enabled by default on your project:

    1. Changeset Comments Policy - To enforce that all check-in contain comments
    2. SSW Code Auditor - To enforce coding standards and best practices before check-in
    3. Testing Policy - To enforce that unit tests should all pass before code can be checked-in
    4. SSW Code Auditor - To enforce coding standards and best practices before check-in
    5. Code Analysis Policy – To enforce that code analysis rules are not broken
    6. Testing Policy - To enforce that unit tests should all pass before code can be checked-in
    7. Builds Policy – To enforce that the developer has built the project end to end before they check-in

    More Information

    To enable these policies:

    1. Right click the Team Project in Team Explorer > Team Project Settings > Source Control
    2. Select the check-in policies above
    3. Click OK
    Chose check in policy
    Figure: Chose check-in policies in TFS
  11. Do you know to always create a test if you are fixing a bug?

    This field should not be null (Remove me when you edit this field).
    Test case
    Figure: You can easily fix this by associating tests with a Test Case which in turn "Tests" a bug
  12. Do you know the best Project/Version conventions?

    Having a good folder structure in version control allows everyone to know where everything is without even having to look.

    /northwind
     /trunk
     /branches (or shelvesets)
      /experiemental-feature1
     /releases (or tags)
      /1.0.0.356
    Figure: Bad example, SVN conventions are a dated and ignore releases, hotfixes and Service Packs

    Trunk is the old way, Main is the new way as per the branching guidance, and it is the way that Microsoft does things.

    Main branch guidance
    Figure: Good example, this makes a lot more sense
    More Information:
    Good format for the information
    Figure: A good format for all your Products/Projects makes it easy to know where things are and what they are for

    Read the TFS 2010 Branching Guidance - http://tfsbranchingguideiii.codeplex.com

  13. Do you include original artworks in Source Control?

    This field should not be null (Remove me when you edit this field).
    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.

  14. Do you know to get Visual Studio to remind you to check in?

    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.
      VS.NET 2008 Source Settings
      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.
      Source Safe VB6
      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.
      Source Safe Access
      Figure: You can also check-in automatically in Access
      Source Safe Access Menu
      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.
  15. Do you need to migrate the history from VSS to TFS?

    This field should not be null (Remove me when you edit this field).
    • Normally, you don't need to check the history very often. If you do need sometimes, then get it from VSS.
    • Save much space for TFS. For example, we have a about 7G VSS history database, and we may only need a small bit of them every 3 months, so what's the point of coping about 7G file when we only need one line of code?

    But there are also some considerations that you may want to migrate the history:

    • If the history of source changes will be checked very often, so you can check the old history with the recent together via TFS.
    • You are going to decommission the old VSS completely. Say you don't want to keep the old VSS database, and then it will be necessary to keep the information somewhere.
    • If the project is very active, then it will be worthy to migrate the history because your developers may need them every day.

    If you are going to move the history, the links may help:

  16. 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.)

    Check-out settings for files
    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.

    check-out settings for team project
    Figure: Correct check-out settings at the team project level - enable multiple check-out's.
  17. Do you know how to lay out your solution?

    This field should not be null (Remove me when you edit this field).

    Whenever we setup a new Team Project we implement a basic version control structure. We put "readme.txt" files in the folder structure explaining the different levels, and a solution file called [Client].[Product].sln?located at ?/[Client]/[Product]/DEV/Main?within version control.

    Messy solution
    Figure: Bad Example, how would anyone know how to sort this mess out?
    Ideal solution
    Figure: Good Example, The ideal solution.

    For more implementation details see:
    http://blog.hinshelwood.com/archive/2010/05/17/guidance-how-to-layout-you-files-for-an-ideal-solution.aspx

  18. 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)
      Things you don't store are:
    • Video files eg. avi
    • Installers eg. .msi
  19. Do you only check out the files that you need?

    This field should not be null (Remove me when you edit this field).
  20. Do you know to make using Check-in Policies easier (by adding a 'Recent' Query)?

    This field should not be null (Remove me when you edit this field).
    Select A Recent Work Item
    Figure: When you use Check-in policies you often will need to select a work item that you selected recently
      Make this easy on yourself by adding a query 'Recent'
    1. Create a work item query that returns you the last changed work item
      Add a query
      Figure: Add a query just for your associated check ins
    2. Just copy the 'Tasks - My' query
    3. Add the sort date of 'Changed Date' sorted by descending
      Sorted the query by 'Changed Date'
      Figure: The query should be sorted by 'Changed Date'
    4. Use that query on your check ins and you find the relevant work item easily
  21. Do you configure your Team System Web Access to be accessible from outside the network?

    If you have Team System Web Access installed and you need to access it from wherever you are, you can configure a port to be forwarded to the server where Team System Web Access is installed, eg: tfs.your-domain.com:8090.

    Visual Studio Team System Web Access Power Tool
    Figure: Visual Studio Team System Web Access Power Tool
  22. Do you know how to rollback changes in TFS?

    This field should not be null (Remove me when you edit this field).
      There are two ways to do this:
    1. 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
        Undo Pending changes
    2. 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
        Revision List
        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
        Rollback Changeset
      • 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

  23. Do you use SSW Agile Template for SSW project?

    This field should not be null (Remove me when you edit this field).
  24. TFS Master - 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

    Source Safe VS.NET
    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)
  25. Do you know to delete workspaces older than 6 months and warn on 3?

    The more workspaces you have the more load the TFS server is under when users check in and out. TFS has to check all of the workspaces for other checkouts of the same files which can be intensive if you have a lot of workspaces.

    If a developer had code checked out to a workspace that they have not even looked at in months, what is the likelihood that they even remember what changes they were making?

      Why do workspaces build up?
    • Developers use multiple computers
    • Developers use volatile virtual computers
    • Developers reinstall their workstation
    • Developers get new workstations
    • Developers leave
      Developer checklist:
    • Check workspaces often to see what you don't need
    • Delete any workspaces you no longer need
      TFS Master Checklist:
    • Delete all workspaces that have not been edited in 6 months
    • Warn developers for workspaces that have not been accessed in 3 months
    Longtime Workspaces
    Figure: Bad example - Rebecca has a workspace that has not been accessed in a while
    Current Workspaces
    Figure: Good example - All of Julian's workspaces are current
    1. Open VS 2010, File | Source Control | WorkSpaces, click the "Show remote workspaces":
      Manage Workspaces
      Figure: Manage Workspaces
    2. Keep press "Ctrl", select the workspaces which haven't been used for a long time.
    3. Click "Remove" button.
  26. Do you know how to refresh the Cube?

    The cube is by default refreshed every two hours, but what is you are about to go into a status meeting and you want up to date reports?

    You can refresh the cube manually using the web services, but only from the TFS server:

    Warehouse WebControl Service

    Read Refresh the TFS Warehouse manually for more detail.

......