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: ....
Related
When using the Request Review feature in VS/TFS a shelveset is created with the proposed changes. This shelveset stays around when the review finishes, both if it is accepted and if it is rejected.
This is all fine but the review shelveset tends to dominate my list of shelvesets making it difficult to find a 'real' shelveset. Deleting the shelveset after the review has finished, seems to be bad as it is linked to the review which is linked to the final changeset.
So my question is whether there are a way of hiding these review shelvesets?
We are using Visual Studio and TFS 2015 Update 3. Here is how it looks:
There is no way of hiding these review shelvesets, unless delete them. However,
if you have deleted the corresponding CodeReview_XXXX shelveset as part of clean up activity at a later date.
Then, users go back to the same code review for some investigation, Code Review details doesn't get displayed.
If you need this feature, suggest you to add a related uservoice or vote up for below idea, this is pretty much the same thing...
TFS: Code Reviews: Shelveset based: Unable to view any details of a code review if one happens to delete corresponding code review
shelveset
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/16853590-tfs-code-reviews-shelveset-based-unable-to-view
Suppose I have a team project with two branches: "main" and "dev" (fictional names).
As things are now, new code is merged into "main" without any code review. Also, anyone can check-in directly to it. We would like to change that.
I would really like to have something like Git's pull request functionality. I know we can use permissions to keep everyone from making check-ins at the main branch. We can also use permissions to make sure that only a reviewer can merge into the main branch.
But how can we review the difference between both branches before doing a merge?
I found out that the Code Review feature of TFS 2013 only works if you have the Premium edition of Visual Studio. Not all of the devs here have it, and we cannot install other editions for them, nor get VS2015 or later versions.
You can add a custom check in policy for code review before checking in. There is an existing Code Review Checkin Policy can be downloaded from website below, this policy allows you to enforce Code Reviews at checkin time.:
https://visualstudiogallery.msdn.microsoft.com/c476b708-77a8-4065-b9d0-919ab688f078
Every time I've coded a new feature (about once a day), I create a shelve set containing my changes and request a code review of my team lead (of the changes in the shelve set). He's pretty busy and it takes him half a day to a day to do the review. Meanwhile, I've continued coding the next feature, on top of the changes that I asked him to review.
My problem is: How do I then check in the changes that he approved, but not the (unreviewed) changes that I made after I created the shelve set?
As MrHinsh says you need to park what your working on and progress the code review check in and then return to what you are doing.
If you are using the the TFS code review then you will be using VS Premium or above, you can therefore use the My work tab to handle this process for you. You can Suspend what you are working on, revert back to your reviewed code, and when that is completed you can then restart the work that you were on.
TFS will shelve your changes and work items for the Suspend, when you then restart the work all of the source and work items will be restored back to the IDE and the IDE will revert back to the state it was in when you paused.
Information on the My Work can be found http://msdn.microsoft.com/en-gb/library/hh543900.aspx
There are really two main options for this:
You can shelve your new changes and revert. Then retrieve the shelve for the review and checkin. Then retrieve the new work.
You can have a seperate workspace that you keep clean of new development for checking in the reviews. Switch to it, get latest, and retrieve the reviewed code. Then check in.
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.
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.