We have a Code Review policy in our development team that restrict developers from submitting new code unless you have a Code Review with 5 "Looks Good". The option Send & Finish of the Code Review has 3 options:
Looks Good
With Comments
Needs Work
If we mistakenly select "With Comments" instead of "Looks Good" TFS finish and send your review as finished With Comments without actually having any comments.
My question is, can I prevent TFS from finishing and sending "With Comments" if there are not comments on the review.
It is not possible to do this with the current implementation of Code Review in Visual Studio for TFVC.
Related
In TFS 2013 Web Access when I go to Sprint Board I see only 2 States Active and Closed.
I wanted to add few more statuses like In Progress and Blocked. I downloaded the process Template using the Process editor that is part of TFS Power Tools.
When I looked at the Process Template workflow there is already To do, In Progress, Done and Removed as shown in the figure attached..
But these are not showing up in the Task Work Item. All I see in state dropdown is Active and Closed.
How do I change it so that I see Active, In-Progress, Completed and Blocked States.
Please help.
By default, States on the Sprint board are To Do, In Progress, and Done (assume you're working with scrum project template).
In order to add another state on the Sprint board, you need to:
Run the WITAdmin.exe exportcommonprocessconfig command to export the
common process config from your TFS project.
Customize the file to be similar to the followings:
<TaskWorkItems category=”Microsoft.TaskCategory”>
<States>
<!-->States you want to have<-->
</States>
</TaskWorkItems>
Run the WITAdmin.exe importcommonprocessconfig command to import the customized Common Process Config file back to TFS project.
Please check this blog for the detailed information on how to get it work: http://blogs.msdn.com/b/visualstudiouk/archive/2013/01/19/adding-additional-states-onto-the-agile-task-board-in-tfs2012.aspx
Be note that: states on the Sprint board should be the same as the States defined in the WIT.
When you in visual studio 2013/tfs2012 check in your work associated with A task you can either 'associate' or 'resolve' the task. Setting it to 'resolve' Will automatically move the task on the sprint backlog and the kanban board to 'Done'. This is Nice because AS A developer you only need to check in using the correct status and status everywhere is okay :-).
This does not Seem to be the case with work items of type 'Bug' - here I Can only choose 'associate' inside vs2013 and then I also need to manually Enter web access and set the bug to 'done'. So I'm kind of doing the same work twice.
Can I without customizing TFS work item types or the proces template get this bug status set to 'resolved' as it works with 'tasks' today - and how?
It's definitely possible - We use "resolve" with every bug (under the Agile template) because it saves such a lot of time. In pending changes, just associate the bug (type in its work item id, or drag and drop the bug into that area of the pending changes) and then you can either "associate" or "resolve" it. (After which the originator can verify the fix and close it)
I presume you're using a template that doesn't offer this facility - so perhaps diff your template against the standard Agile template and you may find the tweak you need to allow this behaviour. Does the template you are using support the "resolved" state on bugs? Perhaps it is missing?
If it is just that your bug template skips the "resolved" state, then it would be trivial to either rename the equivalent state (perhaps it's just not being picked up by the UI because it's not named correctly or not in the correct group?) or insert a new state using the WIT editor.
It's really not a good idea to set a bug as done on checkin. Has the coder verified that the completed output meets the definition of done? How can they hope to do that before they check in?
A bug, just like a PBI, greys set to done when a Development Team decides as a group that out is complete and that they have met ask quality bars.
In the Scrum template Bugs are product level items that confirm to the DoD. However you would break that bug down into a number of tasks at your sprint planning meeting and they can be resolved. The workflow for a bug is:
1) Bug created by tester as the result of a failing test.
2) Bug accepted into the sprint by the Development Team.
3) Bug broken down into tasks for at least coding and testing work.
4) Coder fixes the bug and resolves their Task. The checkin marks this task as Done.
5) Tester validates the Test Case that proves the bugs existence now passes. They mark their Task as Done.
6) The Development Team meets and assesses the doneness of the Bug against the DoD. If done they mark it as Done.
A bugs flow is different from a task.
A bug is raised (tester / user / Developer)
A Bug is fixed (Developer)
A Bug is Tested (built, Integrated to main build, deployed, Tested by Testers)
A bug is done (signed off by the originator)
is the general flow of a bug, TFS ALM assumes that the fixing and the testing would be done by 2 different roles.
if you want to change this to mirror the task work flow, you would have to alter the template
We also use the Microsoft.VSTS.Actions.Checkin action to transition a bug between Development and QA states. Developers can Associate or Resolve, and Resolve triggers the state change attempt. HOWEVER, if any fields are required in the transition, such as Root Cause, the transition will fail without any error message. This is unfortunate. It would be great if the bug popped open and said "Please enter this field." If required fields are filled in before the checkin, then the state transition happens as expected.
We are building a Saas application and would like to have a section of our app that shows release notes, upcoming releases, recent changes. For the last part, it would be great to simply be able to read the comments from our check-in history from VS Team Services and display them within a web page in our app. I know that means we have to write these comments with a customer-facing perspective...we'll deal with that. But just want to reduce having to manually put these updates on our web-page every time we do a change.
Is there any API to this database that you can read from externally?
You can use the Team Explorer API to query changesets and read the comments.
If a user checks out a file and fails to check it back in after a certain number of days, I'd like TFS 2010 to generate an e-mail. (For example, the user would be notified after the item has been checked out for 1 day, and the entire team notified after 2 days.)
I found the article about writing TFS server plugins
but I was wondering if there is a simpler way.
The problem is, that notifications/alerts are event triggered in TFS. So if nothing changes there will be no trigger.
A little bit easier than writing your own plugin, which also requires a trigger, but can check for more than the changed item, a small application would be easier. A small command line tool is enough and you could run it by using scheduled tasks once a day. The tool would check for all pending changes and how long they are pending and if they are to old, it will send a mail to the user.
I think the title explains what i need. We have a very big development department. Everyone checkins and checkouts codes on TFS. But before the checkin operation, an administrator or project manager (or some desired people) must control the code and then confirm or cancel the checkin operation. Because some codes may be incorrect or dangerous. Do you know a tool like that for TFS?
Thanks!
You probably can do it customizing your process on TFS/VS but what we use where I work is:
1) developer does changes and instead of check in, creates a shelveset.
2) manager check shevesets and checkin or send it back to the developer for some rework.
It works fine as long everybody respects the process.
You can have a look on shelvesets here: http://msdn.microsoft.com/en-us/library/ms181403(v=vs.110).aspx
Hope it helps.