Team Foundation Server Best Practices (2 of 3)

TFS Best Practices Articles

1. What Should Be Checked In
2. The Right Way To Check In
3. Things To Watch Out For

In part 1, I explained some of the key items that you want to keep in source control. Now that they are under source control, let's discuss the proper ways to check changes in.

The Right Way to Check In

Get Latest Before Checking In

It may seem minor but it is very important to get the latest version before attempting to check code in. If you are working on a team with other developers, you need to assume that someone else has either made changes to the same source files or has made changes that impact your code. You should consider it your responsibility to merge your changes with any that others may have made.

Get Latest Before Checking in Again

This was more of an issue with the previous versions of Visual Studio that has been taken care of with later versions. Getting latest from within Source Explorer will get the latest version of all files that the solution and associated projects know about.

In the last post, I mentioned that *.sln and *.csproj (and other project types) keep a list of what projects and files are within the solution. Getting the latest analyzes your current copy of this solution and project definitions and gets updates of all files based on that list (including the solution and project definitions themselves). The issue arises when you add a new file to a project or a new project to a solution because Visual Studio won’t know about the new files until after the first check when the definitions are updated. After getting the updated definitions, getting the latest again will get the new items this time around.

Even though newer versions of Visual Studio seem to be smart enough to take care of this on their own, I still get latest twice just to be sure because it doesn’t hurt to be sure.

Conflict Resolution

When you get latest to a resource that has been modified and checked in by someone else first, you then need to resolve the differences and merge them into one up to date file. Many times, Visual Studio can take care of this on its own but sometimes the changes are too close to one another. When that happens, you’ll go through each change and ensure that the changes don’t conflict with one another. And even after resolving changes, it’s a good idea to test your code again to ensure that it still works as intended. This is an ideal situation for Unit Tests which leads to my next point.

Run Unit Tests

If you are working with a project with properly designed unit tests, you should always run all unit tests before every check in. This is not always practical, for example, if you have tests that are doing load testing or involve large data sets, it may take several minutes to run so you aren’t going to run those constantly. However most standard unit tests when designed properly test small isolated sets of code and take a few seconds to run hundreds of tests, if you can run through all of your tests in a few seconds do it every time you check in. If your changes break functionality, it is your responsibility to correct the problems or at the very least, get the issue logged for someone else to resolve.

Check In Working Code

It may seem obvious but TFS or any other source control platform is for storing working versions of code. All of the previous steps boil down to the same thing, getting the latest version of all code and testing the changes either automatically via unit tests or manually to make sure what you ultimately check in is as close to working as possible. Bugs always happen but at the very least make sure your code compiles, make sure unit tests all pass, and if for some reason that isn’t possible (most likely because you need help addressing an issue), be sure to log the issue appropriately so it is known. There is nothing more frustrating than stumbling across a bug near the end of a project that someone knew about early on and for whatever reason never communicated it with the rest of the team to get it resolved.