I'd like to find a tool acting like a global annotated mode for tfs.
I want to visually identify which parts of my projects are basically never touched, i.e. which parts are the oldest, which parts are particularly unstable.
Ideally, I'd like to have a kind of visual history to see which parts were mostly modified in the last month or so.
Hope this is clear...
thanks.
Team Foundation Server has an extensive data warehouse built-in. Some of the metrics that are available are:
Total Churn
Lines Modified
Lines Deleted
Lines Added
One of the things that you can do is open these metrics in a PivotTable in Excel, then use Conditional Formatting to highlight code-churn within your project over time.
If you follow the instructions on this TFS 2010 Code Churn Report blog post, then configure your PivotTable like follows:
Columns: Days, Weeks or Months
Rows: TFS folders
Data: Total Churn
That should get you close to what you are after.
For more information on the cube structure, see Analyzing Code Churn and Code Coverage Using the Code Churn and Run Coverage Perspectives on MSDN.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I am working on scrum with VSTS(Visual Studio Team Services)
I am able to add estimated effort to backlog items as well as estimated hours to different tasks.
I was wondering if there is a way that allows me to add the actual time taken to finish a specific task. So that I can later have a report or so to see the difference between estimation and actual in order to enhance the team estimation.
Not in the SCRUM Template. That template is all about remaining time. I believe the AGILE Template will let you enter original estimate, remaining time and time spent. So perhaps look into that.
Failing that, you could use an add-on. Have a browse of the Visual Studio Marketplace
This one looks like it might work for you: TFS Time Tracker
Completed Work field is only available for the Agile Template. I believe you can still create a custom template to be able to configure fields in the default template (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-field).
However, VSTS is probably not intended for time tracking. You can try and use time sheet extensions to VSTS.
For example, TFS timesheet (https://www.teamexpand.com/product/tfs-timesheet) allows inputting hours directly from a Work Item tab and generate detailed reports that show how many hours were spent to complete a task with a day-by-day breakdown. It also allows to keep track of actual time vs. estimated time.
We have Team Foundation Server 2008 deployed as our source control management system. A team that is responsible for multiple products is asking for all their products to be put under a single TFS project. Their reason is because the products are all in a similar domain.
Here are my reasons against:
The workspace mappings will get weird, since projects will be mapped to subfolders
Continuous Integration may be a problem, since a single project can't be referenced
Tracking history of source control activity could be problematic
This just feels like an overall bad idea, but I would like some concrete reasons against it. If I'm completely off-base and this is a good approach to take, I'd like to hear that as well.
What are the pros/cons?
I have experience storing multiple Visual Studio Solutions (seperate products) under one TFS Team Project in both TFS2008 and TFS2010. Here is my take.
In both versions we create a folder for the Product, then a folder for the branches (Main, etc.) This makes it easy to see what product we are working on, and we can see the history of the product seperate from other products. Continuous integration works just fine with multiple build definitions, one for each product. We only create one workspace mapping for the entire TFS Team Project.
The shortfall in TFS2008 is that it can be difficult to manage work items for each Product. In TFS2008 the work items apply to the entire Team Project and it is not as easy as it should be to figure out which work item belongs to which product.
In TFS2010 the work items have an Areas and Iterations section. We use the Area to define the Product. So each Work Item gets an Area that matches the Product name. This has worked very well for us.
If you are not using work items heavily in TFS2008 than I don't think you should avoid putting multiple Products in one TFS Team Project, certinally not for the reasons you listed above.
Using one Team Project does haves some advantages:
1. There is ony one Team Project to manage and there is only one Share Point site.
2. You can see history across the entire Team Project easily.
My thoughts:
If there are assemblies shared amongst the projects, it makes sense to lump them together, otherwise you will run into the same problems that many people have discussed here, on how to handle shared assemblies.
You shouldn't encounter any problems with workspace mappings. Within our organization, we simply map $/ to a folder and go from there. Otherwise you could very easily map individual source control folders to different areas on disk. The only recommendation I would have is to put that mapping in a batch file, so that new members can run the batch and be consistent.
The only thing that you might lose out on a bit by lumping these all together is quick and easy reporting. If everything is in its own Team Project, the built-in reporting works "out of the box." If you put things together, you'll need to set up additional areas and iterations in order to do the reporting and tracking.
In our organization we have upward of 15 separate team projects, but every single one of them has more than one "product" underneath. We've been running this way for two years and really haven't had any problem with it, with the exception of the reporting.
Using a single Team Project for more than one software is a perfectly acceptable solution if you don't use separate templates for them. Martin Hinshelwood has a detailed blog post on the subject.
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
We're currently using Visual Source Safe and BugNet and looking to migrate up and away from VSS. I've been pushing for either SVN ( a) we're an ASP.NET shop, b) DCVS is not an option - no matter how much I like Hg ;-) or TFS. Well we finally got a new dev server, so I talked the boss into installing TFS on it (30 day trial). In the meantime, we had started experimenting with FogBugz. We really like FogBugz for about 80% of what we want to do, and the other 20% is probably stuff that we don't know what we want.
I'm pushing for TFS because it allows for IDE integrated (mostly) everything.
He's pushing for FogBugz because he can group tasks by customer and then project and manage everything from one dashboard. (which means I lose most of my IDE integration - no huge loss I agree)
Does TFS support a single dashboard that would span all our solutions (in this case each solution is a full app that we sell to a vertical market client) and let us assign workitems to each solution-spanning-group?
So for instance I think we envision something like this:
PROJECT1 - Bugtracker and workitems
PROJECT2 - Bugtracker and workitems
PROJECT3 - Bugtracker and workitems
CUSTOMER1 - Deployment schedules, required features, specific notes (Uses PROJECT1, PROJECT2)
CUSTOMER2 - Deployment schedules, required features, specific notes (Uses PROJECT2, PROJECT3)
CUSTOMER3 - Deployment schedules, required features, specific notes (Uses PROJECT1, PROJECT3)
Hopefully that makes sense. naturally it's more complicated than this but I think I've given the details enough to paint a picture.
I offered the option of creating dummy projects per customer but he doesn't like that and it doesn't really give us the single dashboard view that we're hoping to end up with (and that FogBugz as we've sorta implmented things does do now).
Has anyone got a good suggestion on a management app that would accomplish what both of us want?
EDIT: since I got some good responses (albeit not what I wanted) I'm going to close this for now. However, I think this is something that would be a good thirdparty market and/or a feature in an upcoming TF release. Feel free to post with more ideas if you come across this later.
TFS allows you to have multiple Team Projects. Each is effectively a root folder for source control. However, you can move files/folders between projects in source control, and the Work Items are global (shared across all Team Projects). For Work Items all the projects do is provide a level at which you can filter out work items (so you look at bugs only for this project, etc).
So Team Projects allow you to nicely compartmentalise your projects, but they are only virtual compartments, with few limitations on moving items between those compartments.
The only problem I've found with multiple Team Projects is that you have to branch a folder (and cannot branch a Team Project) so if you wish to make a branch that spans several projects you have to have several branches, which means severwal workspace mappings and several merges for each operation.
For customers we simply added a custom "customer" field to our work items that allowed us to relate a work item to a spacific customer.
When you look at work items you can then apply SQL-like filtering (e.g. TeamProject=#Project AND Customer="BiggsAndCo" AND WorkItemType="Bug" would find all the bugs reported by BiggsAndCo in the current TeamProject)
There are a lot of third party add-ins for VSTS to enhance the TFS experience (thankfully, as raw TFS provides very basic and clumsy UI), and you can use the API to write your own tools to query the TFS database too, so you shouldn't have too much of a problem getting a dashboard thta you find useful. You'll need to do some searches to see if the solutions out there match your requirements though.
One way to do this is would be to have a single team project that covers all of your solutions and use subfolders in source control and items paths on your work items to separate feature requirements, bugs, and so forth by project.
It's the customer specific information across a subset of projects that you'll probably need to do some customisation in order to report on since you have a many-to-many relationship that TFS work items don't support out of the box.
Hope that helps
In Team Foundation Server, I know that you can use the Annotate feature to see who last edited each line in a particular file (equivalent to "Blame" in CVS). What I'd like to do is akin to running Annotate on every file in a project, and get a summary report of all the developers who have edited a file in the project, and how many lines of code they currently "own" in that project.
Aside from systematically running Annotate of each file, I can't see a way to do this. Any ideas that would make this process faster?
PS - I'm doing to this to see how much of a consultant's code still remains in a particular (rather large) project, not to keep tabs on my developers, in case you're worried about my motivation :)
It's easy enough to use the "tf.exe history" command recursively across a directory of files in TFS. This will tell you who changed what files.
However what you're after is a little bit more than this - you want to know if the latest versions of any files have lines written by a particular user.
The Team Foundation Power Tools ship with a command-line version of annotate called "tfpt.exe annotate". This has a /noprompt option to direct the output to the console, but it only outputs the changeset id - not the user name.
You could also use the TFS VersionControl object model to write a tool that does exactly what you need.
If you install the TFS Power tools (at least for VS2005); it's called annotate.
It might be part of VS2008...
You can use TFS Analysis Cube to see generate a code churn report, which I believe is something you would like.
Annotate is now part of Visual Studio (I think it was introduced in VS 2010).
Docs
I'm writing an answer to an 8 year old question :). Its not really a full answer, but a suggestion to look into excel reports for TFS.
TFS2013 / 2015 on prem has something has an excel report that can be used to visualize Code Churn.
In VS open team explorer then select "Documents" then explode "Excel Reports". I believe Code Churn report has something like discussed. The report is made by some default project template so I think tfs2013 on prem just creates it.
Code Churn Excel Report VS2015
https://msdn.microsoft.com/en-us/library/dd695782.aspx
I had very similar requirement to get details of particular attribute in a file e.g. who added, when, related work items etc.; Following GitHub project is having implementation to get required details and required minimal changes to work with multiple files or project -
SonarQube SCM TFVC plugin
It requires analysis to be executed from Windows machines with the Team Foundation Server Object Model installed (download for TFS 2013).
This blog post is also having good explaination and sample application -
TFS SDK: Connecting to TFS 2010 & TFS 2012 Programmatically