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.
Related
Using the API, I can get a work item, and add a comment (System.History item).
To get all history items I cannot quite see how to do it, except to use the obsolete GetHistoryAsync()
But the main problem I'm having is how to replace/update a WorkItemHistory for a given WorkItem. I can see there are different revisions, but how do I specify in UpdateWorkItemAsync() that I want to update a specific revision?
Thanks.
There isn’t the way to change work item history in VSTS. (Regarding TFS, you can modify data in database directly, but it isn’t recommended)
Also, it doesn’t make sense to modify work item history, the history is used to track the changes of work item.
In TFS 2013, how do I mark a work item as blocked - at least at the task level, but more preferably any work item. In other sprint tracking systems it's as easy as right clicking on a work item and selecting "Blocked" and giving a reason. In TFS this doesn't appear to be so straightforward...
We use internally a tag called Blocked, and then use the Styling of the board to color the tag Red. That coloring only works on the board, and doesn't show up in queries or on the backlog, but since we use the boards during standup it works wonderfully well.
We have a story on our backlog to create a real Blocked scenario, and is also tracked on User Voice: http://visualstudio.uservoice.com/forums/330519-team-services/suggestions/2717759-visualize-blocked-task-in-task-board.
TFS relies on a flexible process model that can be customized. Out-of-the-box, there is no status Blocked in the available process models. You can customize your work item templates (tasks or others) and introduce the new status and the required transitions. After that you can set the state of your work items to the new state Blocked and set up the required queries.
See this link for a description on the available customizations.
I'd propose to apply the changes to a test environment first. Please note that changes to the work item templates might result in problems when updating your installation. See this link for details.
Interestingly, this is available in the Task work item in the CMMI template. Just copy and paste the xml from the that work item into your Scrum Process Template. Its reference name is Microsoft.VSTS.CMMI.Blocked.
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: ....
Our development process works like this: Every 2 weeks the team lead (me) goes in and reviews everyone's changesets to make sure they are up to the coding standards. I would like to use TFS 2012 to help automate this process.
There are 2 problems with this:
There is no way to submit an unsolicited code review. I can live without this if necessary, I guess
There is no way to associate a code review with more than one changeset. This is a deal-breaker
I read one article which said it's possible to link changesets to a work item after the fact and when I open the work item for the request review I do see the Links tab. However, when I click "New" or "Link to...", there is no option to link to a changeset. There is only an option to link to each work item type in the process.
Does anybody know how to do this? Are there any plans to add these features to TFS?
Here's a screenshot:
Unsolicited, no.
You can rightclick a changset in the history screen to request a review post checkin.
And there is a nasty workaround to get what you want to achieve. Check out all files you want to review and request a review. You can then undo your checkout, the shelveset and the review request will remain.
Alternatively you can just go to the source control tab and do a checkout-all on the rootfolder of your solution, request the review, undo your checkout and do the review.
As for linking changesets to a Work Item, this can be done post checkin. Open the work item, go to the links tab and click "Link to..." The dropdown there will have a "Changeset" option. But I don't think this link type is enabled for Code Review Requests, since these use a Shelveset and not a set of changesets as the source for the code to review.
I expect you could use the TFS API to generate a shelveset with all the changes from a specific developer in a given timerange, put these on a shelveset and request a review on that. But no existing feature to do that exists.
Or you might be able to edit the shelveset of associated to the review by creating a new one with the same name.
An alternative approach:
1) at the beginning of the two week cycle, initiate the code review process and note the work item number that is created. Simply request a review from yourself with no code changes at first.
2) Have all your developers associate their check ins for the next 2 weeks with that work item #
3) When you are ready to perform the review, simply open the work item and go through the changesets.
That should accomplish what you want.
Option #3
[I'm assuming here that the changesets that your are trying to associate to a single code review are consecutive, for example 20001:20010]
I "roll[ed] back to a specific changeset" (in my example above
20001). I check it in the changes. The code is now in its original
state.
Then, I "roll[ed] back to a specific changeset" (in my example above
20010) and check it in again. The code is now in its final state.
Finally, I request a review on the latest revision. This review
compares the latest two commits - the ones I created from the
rollback.
As a bonus you can compare specific changesets in the history page. You can use this compare to make sure that the commits above did in fact revert the code to revision 20001 and 20010.
On item #2, I have a standard work around that you might like to combine all changes from many changesets into one shelveset for review. I tried the checkout method mentioned above and ran into issues, partly because my review had 25 files or so and after checking them out, if I refreshed, TFS removed them from pending changes because it TFS's opinion there were no changes.
First, (assuming that your changes are already checked in, and in multiple changesets), have a workspace with the latest files on a disk path such as D:\Latest...
Create a new "local" workspace (called "Review"), map the same project to the slightly different path (say, D:\Review...") get all the files. Go to the history of that project and just before your earliest changeset, right-click and select "Get this version".
At this point, go to the history and rollback any changesets that someone else may have changed in the meantime, if any, that you don't want to be part of the review, unless someone changed a common file. Leave those.
Using beyond compare, compare "D:\Latest..." to "D:\Review...", copy your changes from Latest to Review. Go into the common files and copy only the lines that you want reviewed. When Beyond Compare writes out the changes, TFS will detect the change and put the file you save in your pending changes list for the "Review" workspace. (That's a feature of local workspaces.)
At this point, you just shelve your pending changes from the "Review" workspace, and request a review on that shelveset.
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