Tell me what you don’t like about TFS 2010
I know that a lot of people have had bad experiences with TFS over the years, and so does the TFS development team. The team at Microsoft is very intent on learning what it is that people find irritating, problematic, or difficult, and correcting it. Some major headway was made with the 2010 release of Team Foundation Server to make it easier to setup and administer, and also to improve the usability of several of its key features.
That said, there is still room for improvement and both the team and I understand there are still opportunities to improve. In all seriousness, the team at Microsoft wants to make TFS an approachable, no-brainer install decision for .NET teams, even small ones. This means they want to be able to compete for your attention with the likes of SVN, Git, Jira, Perforce, and anyone else making collaboration tools for developers.
The point of this post is for you to help me know what feedback I can give the TFS product development team as they look ahead to the next release of TFS. I am looking for legitimate feedback I can give the team on how to improve the TFS product.
Please bear in mind that I am interested in your feedback on TFS 2010, as TFS 2008 was improved upon 10 fold in the latest release. Also, I am not necessarily looking for feedback on Visual Studio, just the TFS side of the house. Please realize that the team who makes this product at Microsoft is just as committed and passionate about making great software as you are. They just really need your feedback to make the thing you want. In fact, they want to make a tool that every developer loves to use. Really. So what needs to change to make that the case?
Recall that TFS functionality is broken into the following major areas and I am looking for feedback on the 2010 version.
- Version Control
- Work Item management
- Team Foundation Build
- SharePoint integration (optional)
- Reporting and SSRS Integration (optional)
Thanks for anything you have. Thank you also for being respectful and not making this a bash-fest.
Microsoft Developer User Research would love to hear your insight and feedback on our tools and initiatives.
Fill out our survey and sign up to participate in User Research studies.
Questions? Email devur@microsoft.com for more info.
SURVEY LINK: http://bit.ly/9eIf7H
Build Automation is my biggest pain point. I’m currently using CruiseControl.net, but I’m trying to move to TFS, and it just isn’t working. I cannot find any easy way to publish a clickonce application to a UNC path on our network. Visual Studio 2010 will let me publish easily, but I can’t seem to translate that into an automated build process with the current templates in TFS 2010. This should be a no-brainer for Microsoft – why is it so hard?
To get TFS 2010 to publish upon build, add the following to the build definition. Go to the “Process” section. Open the “Advanced” section. In the “MSBuild Arguments” field add
/t:Publish /p:PublishDir=\\YourServer\FolderToPublishTo
That should perform the publish required for a ClickOnce App. Now that being said, I have found that TFS does not increment the publish version. So, every version published from TFS will have the same version number unless manually changed in the project properties beforehand. And because the version number never changes, it doesn’t know to re-download the version. To force that you have to clear the application cache on the user’s machine.
1) Build. I hate it in 2010. I absolutely hate it.
2) Lack of migration information for converting 2008 scripts to 2010
First of all, I’m a CM person and not necessarily a developer. I learned XML for MSBuild/TFS 2008 and that worked fine. In 2010, not only do I need to learn Windows Workflow, but also an additional language if I want to customize any build script.
There are tons of tutorials on how to “create” a build script and how to use Windows Workflow, but these are not at all practical from my point of view. I have not yet found any decent help on:
1) Which language should I learn to customize MSBuild? VB.NET or C#? Most of the tutorial on the web are in C#, but when customizing a build definition TFS is reads, “Enter a VB expression”. So which is it? No one has addressed the pros and cons of which language to learn if one knows neither. If one is not a developer, how would one know which direction to go?
2) How the heck do you translate things like $(WorkspaceName), $(BuildDefinitionName), etc., to TFS 2010? This syntax will not work when creating a build definition. How the heck do you get this information? I have not seen any decent information on this, thus I’m pulling my hair out trying to get what I believe is very basic information.
3) Common code – how is this done in TFS 2010? No one is talking about this. We have two target files – DEVCommon.targets and Common.targets, where the majority of our common code lives. This allows for each build script to be very streamlined. How is this handled in 2010 using the workflow? Where can this information be found?
4) I realize that Visual Studio / .NET started out as strictly a development tool. However, as TFS has progressed it’s become an ALM tool. Yet with each new release of TFS the entire suite is becoming more developer centric, meaning one must have a sound coding skills to be able to tweak it. As mentioned, I’m a CM / Release Management person and lack solid skills in theses areas. The TFS suite is getting more difficult to use because of this. And as most non-developers will probably attest, the last group / person you want doing CM / RM related tasks is a developer.
5) No CM / RM Training. The TFS Admin class is rather useless unless you are completely new to TFS. There are NO training classes specifically related to MSBuild, or how to effectively do CM / RM with the TFS suite of products. Again – developer centric. There’s a lot of people who want to take advantage of the rest of the suite but you’re making it near impossible due to lack of non-developer training for TFS.
I am frustrated beyond description. I’m not above learning languages or anything else to do my work. But Microsoft is excluding too many other folks to accommodate developers, and I feel this is a shame. And there’s almost no decent, usable training if one is not a developer.