Using TFS 2013, we don't seem to be able to use the History section for Work Items because it just gets clogged full of the following statements:
TFSBuild (2 days ago)
The Fixed In field was updated as part of associating work items with the build.
This is where I assume we're supposed to write history such as "tested the bug, re-opening since the following error is still occurring...". We've been putting all comments like this in the Description field though because they get lost in the history section with all the Fixed In messages.
It seems like every single build produces this Fixed In message, although it might be limited to the product backlog item - it doesn't seem consistent. Some items have about 50 of these entries and some have none.
My expectation was that these messages would only show up on the work items that the programmers referred to when committing the code. Are they possibly doing something strange when committing the code? Or is there some sort of procedure I can do to stop these messages from filling up the history entry? Thanks!
You can set "Associate Changesets and Work Items" option to "False" in your build definition to stop updating the associate work items when a build is completed.
Work items will be updated when the build with associated changeset completes and "Associate Changesets and Work Items" is set to "True". Your problem looks the same as this question:
https://serverfault.com/questions/40028/tfs-stop-team-build-process-has-updated-the-fixed-in-field-messages.
It was caused by the build wasn't completely succeed. You can refer to it to see if it can help you resolve the problem.
For more detailed information about Associate Changesets and Work Items, you can read this blog:
http://www.andygeldman.com/index.php/2011/10/ever-expanding-associated-changesets-and-work-items/comment-page-1/
Related
Is it possible to remove the associated change below (commit fb6916d) from this build?
I have consulted the documentation for the TFS web API, but it only told me how to list associated changes and not how to remove them.
Associated changes: it shows the different commits between current and previous build.
Work items linked to associated changes: it shows the work items related to associated commits.
One addition, if you have non-successful builds, (failed or partially succeeded), the commits will keep showing up. The commits are calculated to compare against the last fully successful build.
It's by designed. Sorry, not be able to remove them if there are different commits compared with previous build.
I noticed that work items can be linked to a build. But I don't see a way to automatically link the work items to the build.
On pull requests, we require pull requests to be associated with a work item. When the pull request is complete, the work item is updated with a link to the commits.
If I look at a branches commit history in TFS, there is a build column. I assume that the build column would contain the build that the commit is in, but it is always blank.
We want to be able to look at a build and see what work items are contained in the build.
Is there a way to do this?
The “Automatic linking of a build with associated work items” feature was released in TFS 2017 Update 2. You could enable this feature by toggling the setting under Options in your build definition:
In this way, each successful build associated with the work item automatically appears in the development section of the work item form.
More information you can refer to the blog below:
https://blogs.msdn.microsoft.com/devops/2017/08/25/automatic-linking-work-items-to-builds/
Our dev. team needs to implement auditing for our work; is there a way to get the number of lines added, edited and deleted per changeset?
The idea is that, per work/task/PBI item that a changeset is associated with we would like to get the number of lines affected.
Is this possible?
If you are using the TFS Build feature you can use a standard report to view the code churn Build Quality Indicators. Otherwise you can check this guide of how to get that information.
Warning - newbie question....
I had a vision that I could select what workitem I was working on, and when I checked in the code, I could associate the changeset with the workitem automatically.
I'm assuming that:
I would select a work item and state that I'm starting to work on it,
make my changes to the code base as I see fit,
each time a file is checked out, it is associated with the current work item, and
when I check in I can state that I've stopped working on that work item.
Then if I review a work item, I can see what changeset is associated with that workitem, getting the full fidelity of what changes were made for that specific work item.
Is this possible? Is it automatic? All that I have found so far is a manual association of a changeset with a work item.
The order is: make changes, choose pending changes to check-in, select work item, do check-in. You can enable a check-in policy that forces the change to associate with a work item.
Update
With TFS2012/TFS2013 Premium and Ultimate there is a much cooler way, using the "My Work" page. Before you start coding you select a work item from "Available Work Items" to "In Progress". From there you can directly jump to the "Pending Changes" page by clicking "Check In". It is also possible to suspend your work where the state of the IDE is saved.
Demo: http://go.microsoft.com/fwlink/?LinkID=251849
What you're asking for is not a good idea. That pretty much only allows you to work on one work item per team project at a time. If you can do that, then you must be living a quiet life.
Instead, TFS allows you to associate a changeset with one or more work items - when you create the changeset. This makes it easy to see exactly which code changes were made in order to address a particular work item.
It also allows automated builds to be associated with work items, and enables Test Impact analysis. I don't think any of these things would make sense if you were simply associating a work item with the code you assumed you were going to have to change to address it.
Actually at the project level you can enable "require work item" with checkin. This means that the work item be defined first so that you have somthing to associate with when a checkin takes place.
We have recently migrated to TFS 2010 using the MSF For Agile process template and we make use of such reports as the Burndown, User Stories progress etc. Up until 13/10/10, our warehousing worked perfectly and all our reports displayed upto date data. However, after this date, the reports started displaying old data and on looking at the status of the warehousing jobs using the GetProcessingStatus() method on the WarehouseControlWebService, we can see that the Work Item Tracking Sync job seems to be stuck in the 'Running' state.
Indeed, when you put a profiler on the database, you can see the same stored procs being called again and again, with the same parameters, as if it is stuck in a loop. While this is happening, the CPU usage is 50% and above. It stayed in this state for over 24 hours before I decided to kill it.
There is nothing particularly crazy about our setup - we did a clean TFS install and imported work items from TFS 2008 using Excel. We also have a custom work item template 'Support Ticket' which our support team use to log calls from customers. All importing was done with the proper TFS command line tools or Excel.
Has anyone experienced anything like this before? I have seen a couple of posts where people have had similar issues but not seen an answer.
I am delighted to inform everyone that we managed to fix it! The issue was a rogue work item (Bug) which had a link to a Task which did not exist. I am not quite sure how this happened but can only assume it happened during our work item import from TFS 2008.
We only noticed this because, as a last resort, we were going to create a brand new Team Project Collection and Team Project, and import all our work items into it and see if the warehousing worked there. However, when we viewed the 'All Work Items' query as a tree view in Team Explorer prior to the import, one of them was highlighted in red with an exclamation next to it saying the referenced item does not exist. We simply deleted them item using 'witadmin destroywi /collection:http://tfs2010:8080/tfs/<> /id:1571' and then magically the warehousing worked again. Marvellous!
If this post helps even one person then I am a happy man as this has caused us much heartache over the past week. Although we have managed to overcome the issue, it can't be denied that Microsoft's error handling in TFS leaves a lot to be desired.
Yours
Dan