Click here to Skip to main content
11,647,828 members (63,958 online)
Click here to Skip to main content

Tagged as

Team Foundation Server Best Practices (3 of 3)

, 8 Nov 2013 CPOL 6K 2
Rate this:
Please Sign up or sign in to vote.
Best practices in Team Foundation Server (Part 3)

Editorial Note

This article appears in the Third Party Product Reviews section. Articles in this section are for the members only and must not be used by tool vendors to promote or advertise products in any way, shape or form. Please report any spam or advertising.

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

JJ Bussert
Architect
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.150804.4 | Last Updated 8 Nov 2013
Article Copyright 2013 by JJ Bussert
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid