If you use filter actions from the pending changes window in TFS you must be very careful when checkin files in because there maybe files that you cannot see in the pending changes list which will also be checked in without you knowing. These files can even be different branches as we found during one of our projects.

It appears to be a limit of around 190 files that it can show you in the "Included Files" tree (even though the filter is set to Show All). For your convenience (!!) if it is showing a limited set of files, then you get an extra link "Go to All Changes" which shows a flat list of all the files you have checked out.

To resolve this issue, it would be good if TFS;

1) Shows a warning if a single check in crosses multiple TFS branches
2) Shows a warning – or highlight the treeview area in a better way to indicate that it is not showing all the files that will be checked in.

TFS 2012 currently lacks the ability to truly manage deployments of a particular build. There are many different ways to deploy which complicates the issue. However, for companies that follow standard deployment promotion, Development, QA, UAT, Staging, Production, for example, it would be very helpful to have a way to manage deployments to know what has been deployed where and when and see a history of deployments for a particular build.

Most people tend to confuse builds with deployments. These must be completely separate from each other. This is the only way to properly deploy the exact same build to each target environment only by changing configuration files. A great help with this was the Parameters.xml file that is very much unknown to most of the world.

If you take base from people who have worked very hard to implement some sort of deployment management system via tfs (http://tfsdeployer.codeplex.com), this could be something that would not be hard to implement or extend. This particular implementation uses the Build Quality change event to trigger a Powershell script which executes a deployment to a target environment. This is a very helpful tool but could be vastly improved if fully integrated with TFS. I have extended TFS Deployer to piece together configuration files, manage passwords for the target environments, and execute deployments from the build server. I think by implementing a Deployment controller and deploy agents using the same methodology as the build, this could be potentially help everyone regardless of what is being and deployed and where the target is. Via ssh/scp/etc pretty much any target environment can be accessed using Powershell, and with Microsoft products, the Web Deploy tools work great especially with the use of delegates.

It's unclear why deployments are not considered part of the SDLC and given as much importance as builds or anything else for that matter. It's an area that could really make TFS even more awesome than it already is.

Thanks guys. Keep up the good work!

Ensure the integrity of the TFS checkin policy from being tampered with. Because the TFS checkin policy is executed on the client side, it can easily be tampered with, i.e. the user can easily replace the policy DLL with their own to bypass your policy. Even using strong name assemblies will not work as it can easily be disabled. Maybe Visual Studio could verify that a policy is digitally signed before loading it? Or server side policy would make the policy secure and benefits in terms of deployment. The checkin policy is very useful for industries that are highly regulated; but if it's integrity is suspect, we have to constantly audit our code manually to insure policies are followed.

It would be great to see a timeline of TFS work items, e.g. when was a requirement created, assigned to developer, implementation finished, tested, and closed. This would work for bug items too. It would also be interesting to retrieve statistics of the above, e.g. on average how long does it take for the team to implement a requirement/user story.

A timeline would help project management answer the following:
- how log does it take for the team to finish a requirement/bug/review
- what are the statistics we can conclude, e.g. how long on average does it take us to fix a bug or requirement
- what are our projectbottlenecks, why is a requirement pending for something in a specific state?

It would also give a great overview of the project progress, visually.

The ability to create work item fields which are based on a calculation of the value of fields in linked work items.

For example, if a Product Backlog work item has two children Task work items which each have remaining work, it would be incredibly beneficial to have a field on the Product Backlog work item that was able to roll-up the values of these fields. That is to say that if the remaining work on the two Tasks for that Product Backlog item were 5 and 10 respectively, the Product Backlog work item could show that the sum of the remaining work was 15.

Calculated fields should be able to be based on the link type and the work item type.

Your consideration for this functionality is appreciated.