Some Best Practices for TFS Daily Development:
- What Should Be Checked In
- The Right Way To Check In
- Things To Watch Out For
1.What should be checked in?
This may seem obvious but there are some things that you may not think of checking in that you should:
File on those you work
Checked in all files on those you worked or you want to commit your changes on TFS server.
Solution/Project Files
your *.sln and *.csproj (and others) contain the list of every file that is in your solution/project. If you just check in a folder of files on your screen it may look fine but when someone else goes to get your code they won’t see these files.
Nuget Packages
If you are not familiar with NuGet packages yet it’s well worth your time to look it up. This was more of an issue with previous versions of Visual Studio but since they are not visible in the solution explorer and contain binary files (*.dlls) inexperienced developers may ignore them not realizing that these should be checked in.
2.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.
I already 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.
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.
3.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 Providing Comments with your Check-Ins
Always proper comment while checked in because It is 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.
Hope this is helpful for you. Please give suggestion and feedback both are welcome.
Regards
No comments:
Post a Comment