Team Foundation Server Best Practices (3 of 3)

In the first two parts of this series, I went over what belongs in TFS and how to get it there. In this final part, I’m going to explain some common mistakes to watch out for. Visual Studio 2012 and up seems to do a good job at giving you plenty of tools to help ensure you do not get into trouble but it’s still up to you the developer to use these tools.

Things To Watch Out For

Ignoring Solution and Project Files

I’ve mentioned this in both previous parts but it’s important enough to mention it one last time, make sure you check in the solution (*.sln) and project (*.csproj for C# Projects) definition files. This is mostly an issue with developers that are not as experienced with TFS because they are making changes to code and when they go to check in, these strange files that they never touched have pending changes so they don’t check them in.

Not Checking in NuGet Packages

A lot of developers I have worked with that just start out with NuGet don’t understand why they should be checked in. This is understandable because typically you do not check in DLLs and other binary files because normally you want other developers to build the code themselves. NuGet packages are different because these for one don’t include source so if you do not check in the source the only way to get the binaries is to download them, also checking in a NuGet package is a way of identifying the versions of third party libraries that your code depends on.

Checking in Config files with Local Settings

In particular, when doing any sort of development against a database, you will often have a local copy of a database running so you can run and test code offline and without bumping into test data from other developers. Settings like the connection strings in this case should be stored in the app.config and web.config XML files, however you should not be checking in code with your local database name in it. Typically, I see the name of a staging or shared development server being what is checked in so when you need to get updated config files. It is easy to do a find and replace for all occurrences of a server name and replace it with your local name. This is most important when you have multiple projects with some sort of configuration in each one that needs to be updated with some appropriate local value.

Not Providing Comments with your Check-Ins

Very few senior developers I have met say it is ok to check in code without comments. It seems stupid but this is an incredibly invaluable aid when trying to track back what was going on with code several months back. Even something as simple as “Fixed Bugs” may seem like it’s not worth the effort but it can help separate bug fixes from enhancements that went wrong.

Not Asking for Help

The number one easiest way to get in trouble in any situation is to not ask for help when you are unsure about something. Asking a project lead “What is this .sln file that I have changes in but didn’t change myself?” gets a very quick and easy answer as opposed to being unsure so just skipping files that end up being key to the changes you were working on. I have yet to work with a lead or manager that had an issue answering questions, no matter how simple or stupid they may seem. As long as it helps lead to a successful project in the end, they will gladly take the few minutes to help you understand something you are not familiar with.

Conclusion

I hope you got some benefit from this series. This is far from an exhaustive list of best practices but instead a few key points that I deal with on a regular basis and thought was worth sharing.