Steps: Check-in/Check-Out Mechanism for TFS - To Avoid Build Errors and Improve Productivity

Introduction

You all may already be aware of TFS and its usage to effectively work as a Team on a Team Project but I thought to reassemble some of the important points/steps to ensure good Productivity (by avoiding Build errors as much as possible). So please read the below points and also add your feedback by adding your comments to make this more informative. (This would really help especially if 'Multiple Checkout' option is Enabled).

Steps

1. Always make it a practice to Get the latest version of the Project daily morning before you start your work.
2. Build/Rebuild your solution to ensure that there are no build errors.
   -->If you get any build errors, check what those are. Suppose they are simple to resolve like 'Broken Reference' errors or any other simple errors; please take initiative and resolve them. If you notice that they belong to some other Team member's task, please intimate him/her so that they could fix it.
3. Check out the file(s) which are relevant to your task and start working. Once you are done with your work, verify it by building the project. And if you don't find any build errors; run the project and test your page whether it is working fine. If it's fine, check in your files. If you find any build errors or runtime issues, then resolve them and then check in.
   --> It's always a good practice to divide a big Task in smaller tasks and on each sub task's success, you can check in your work. For example: UI design, populating dropdowns, placing validations, saving form data, displaying grid data, etc. can all be treated as individual sub tasks for a particular page functionality. This will ensure that you will not have any pending check ins at the end of the day and also it keeps things easy. If a sub task is taking a longer time and if you want to continue it the next day, you can comment your partial written code and check in the file. The next time you start work you can checkout, uncomment your code and start working. This practice will minimize the usual conflicts we get when we are working under 'Multiple checkout' option enabled and also it will not have any impact if TFS connectivity issue occurs.
4. Sometimes when we take the latest version from TFS, we get some conflicts in some files, check these conflicts carefully; and if the files don't belong to you, you can straightaway choose the option 'Resolve Conflicts'. Then VS/TFS takes care to automatically resolve conflicts for you. And if a file belongs to you on which you recently worked on; then most of the times you have to choose 'Auto Merge' option so that your changes and the last guy who has checked in recently, his changes, would be automatically merged and saved to TFS. And still if you feel you have to cross verify the changes, you can trace them in 'Merge Tool' option and then merge it.
5. Till now, the check in and check out process that we discuss is for the existing files in our project but there is a slight difference in case of adding a new file, renaming a file, or deleting a file. As TFS and your project already have metadata reference/info of your existing files, hence it only checks out the file when you start making any changes or if you explicitly check it out, but it will not check out your project.

But in case of adding a new file, renaming a file, or deleting a file, the TFS and project will not have this reference in .csproj file and source control .vss file or it might need to update the metadata info of that file; hence it checks out the project as well whenever this kind of operation happens on a particular file. If you are familiar with File system and file handlers, it would be much easier to understand this TFS behavior. Now you need to perform build and run your project; verify and then check in the pending items (file plus project).

This practice minimizes the possibility of getting conflicts and therefore makes things much simpler and in our control.

Finally, our objective should be to simplify our work and avoid confusion and also make sure to avoid error-prone check ins. (Note that a small mistake from an incorrect check in could create build errors for other team members hence affecting their productivity).

Your inputs, clarifications, and feedback in this regard would be highly appreciated.