is there a way to automaticaly close a User-Story in TFS2010 when I checkin my code
with the last open task ?
I do not want to add the User-Story to the checkin with the code.
TFS can't do this automatically, however tools like http://tfsaggregator.codeplex.com/ can.
As previously suggested, TFS Aggregator can indeed easily do this. Just be sure that you actually want to do this, because you might want a human eye to verify that the story is indeed done.
What I suggest is to use the aggregator not for closing the story, but for moving it to a code complete state (or "ready for UAT", or "deployable", or what-have-you), if your tasks do not, in fact, cover everything needed for "DONE" done.
Related
TFS 2017 u2. The task gallery for build/release definitions is crowded by tasks that are utterly irrelevant to our software shop. They're built-in, so removing the extension is not an option.
Any way to hide them?
CAVEAT I discourage you: if you need to reinstall a Task, the process is non-trivial.
This has already been answered at Remove custom installed build task on tfs
The idea is to use tfx build tasks delete. You need the GUID of the task: a quick way to get it is to look at the task.json file in the https://github.com/Microsoft/vsts-tasks repository.
Unfortunately, there is no way to hide the tasks. You could search the tasks you want to use, and I've submitted a UserVoice at website below, you can vote it:
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/33373423-hide-build-tasks
We're using TFS for our day-to-day work management, but are currently unable to use it for source control - we're using SVN instead.
I would like to nonetheless ensure that all our work items have been code reviewed before being closed, and that any code review actions have been followed up on. Any recommendations on how we can keep track of this using TFS with minimal manual steps?
I am also concerned with ensuring that the code review step has not been skipped, and auditability of whether it has happened and whether all resulting actions were closed off. If I look at a closed task, how can I easily tell that a code review occurred on it?
(Optional) Require that every SVN change refer to a work item number in TFS with the check-in comments.
The work item in TFS has a "LINKS" tab on it. As soon as the code is checked in, another work item of type "Task" (or whatever you want to use for code reviews) should be created and linked to the primary work item on this LINKS tab to request the code review for that work item. It should refer to the SVN revision number(s) that need(s) review.
I'm not very familiar with SVN, but I assume there is a way to have branches that could be used as follows. Maintain a separate branch for reviewed code. Only code reviewers can merge into that branch. The only way code can get in there is if the proper work item in TFS exists, and a code reviewer approves and merges the code for it. I'm used to Mercurial and TFS where merging code is really easy. If merging is not easy in SVN, a different solution may be required.
If the linked task exists on a work item, then you know that the code has been checked in and code review is in process. If the link exists, and the linked work item is resolved, then you know the code review is complete. If the link does not exist, then you know that code has not been checked in for this work item (or at least it's not in the reviewed code branch, and has no intent to be there).
We have decided to edit the TFS workflow to include an extra 'In Review' state after 'Resolved'. This allows us to use the existing task board without any overhead of creating separate review tasks, or having to edit the task title to be 'in review: ....
Right now my stories in TFS are being completed, but each time I drag to "Done" the task -- and even stories -- are losing my name on them.
This really gets complicated during scrum, when we're tracking yesterday's activity...
If you have so many items that you can't remember which ones for the story that you were working on were yours then you are doing it wrong.
You can change the work item type to stop this happening. Use witadmin to export the work item and then in the Workflow section remove the call to empty the Assigned To field. Then import it.
I would recommend that you test this on another non-production TFS server incase you ness it up.
If I unshelve a shelveset, the "Pending Changes" toolwindow in Visual Studio will restore the files, the commit comment, and the associated work items I had set up when I shelved.
If I change my mind and decide I'm not ready to work on this shelveset right now -- for example, if I have to drop everything and fix a bug -- is there any way I can clear all of this state at once?
It's easy for me to highlight all the files, right-click, and "Undo". But that only reverts the files; I still have to go in and erase the comment, then switch to the Work Items page, possibly select a different query to make sure I see the work item that I was associated with, and uncheck the box.
Is there a button, menu item, or VS extension that will let me revert the file changes and the commit comment and the list of work items, all at once, and leave me with a totally clean slate to work on something else?
I am not at the office to check this out, but it's worth a shot: Shelve your changes into a new shelveset, keeping in mind to uncheck the "Preserve pending changes locally".
In the next version of Visual Studio it will be a much nicer experience. Check out the session by Jamie Cool on this topic
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.