My team is using TFS 2010 Agile template, and I wanted to enforce developers to fill out Completed & Remaining hours upon check-in.
Any way to make the two fields required upon check-in or somehow work this into TFS Check-In Policy?
You can write your own check-in policy:
http://blogs.msdn.com/b/jimlamb/archive/2010/03/31/how-to-implement-package-and-deploy-custom-check-in-policy-for-tfs-2010.aspx
or you can modify the state transitions in the work item template when the state changes.
http://msdn.microsoft.com/en-us/library/ms194981.aspx
If I had a way to go it would be the second way (and in fact I have done similar already at my work).
Related
I want to be able to review every check-in before the code is applied to the branch, is it possible in TFS?
I know we can add check-in policy to force code-review but this is applied before the check-in and not after.
I'm looking for a way that would not block the existing flow.
Thanks
TFS supports two source control systems that each have their own workflow based on established practices:
TFVC - This is a server based source control system that supports Code Reviews using Shelved changes prior to check-in. As #daniel Mann stated it works exactly as you described.
Git - This is a distributed source control system and uses Pull Requests to facilite reviews of Merges. Since all work is done on a separate branch, you review the proposed pulls of code from one branch to another.
It sounds like you are using TFVC so the existing Code Review model would fit your purpose.
I need to set a default value for the Retrospective tab in TFS 2015.
Factory value is the following (TEXT 1):
What worked?
What didn't work?
What will we do differently?
Using the Powertools, I add a DEFAULT rule. In the rule i specify the following default value for the Retrospective (TEXT 2):
What worked?
Please check out what you wanted to do differently in the last two sprints.
What didn't work?
What will we do differently?
So really it's just adding Please check out what you wanted to do differently in the last two sprints.
Now here comes the problem. I save my work, and if I create a sprint in Visual Studio, TEXT 2 is displayed.
If I create a Sprint in Online TFS (accessed from browser), it will show TEXT 1.
Did anyone have a similar problem in the past?
Thank You in advance!
The Sprint work item, used in TFS 2010 with the MS Scrum 1.0 process template, was removed from the Scrum process template 2.0 of TFS 2012.
However since TFS 2012, you configure the sprint schedule as part of the new Agile Planning feature, making the Sprint work item redundant.
So your options for storing the goals\retrospective:
Use a Task work item (Title, Description fields)
Add custom field in the Product Backlog Item
Use SharePoint integration - store as a document
Spent a while trying to figure this one out as our old Scrum for Team systems template did this in previous version of TFS, however I can't find a way to make a PBI automatically change its state to Done when all the associated tasks are done in TFS 2012.
Thanks
I haven't seen an out-of-the-box solution, but TFS Aggregator is a plugin that is designed to handle this scenario.
I added a "Code Reviewer" as required checkin notes field. But it is in the form free text field. Instead of free text i want a user drop down. and select should be able to select from that list.
TFS 2010 supports only text checkin notes. In TFS 2012 there will be native support for code reviews, however I don't believe it's done through checkin notes. You can try useing checkin policies to validate checkin note value (not very user friendly though).
If you're only reviewing whole workitems (just before they go from Active to Resolved for example), not just checkins, then you can add a new work item field and that will show a user dropdown. You can make this field required to transition from Active to Resolved (mind the reason here!), and thus have a proper validation. Your user will have to update the workitem and you will have to associate the workitem to the checkin for this trick to work though.
And as MichalMa said, this will all change in Dev11.
I'm trying to set up our TFS 2008 instance to require that projects build before they can be checked in.
I have created a check-in policy using the out of the box "Builds" policy, but I'm still able to check broken projects in after mangling the code and attempting to build the project.
We're a small shop, and TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem? Do check-in policies apply to TFS admins?
Any other suggestions?
Check-in policies are a client-side check only. If the client does not have the check-in policy available, the check will not run. Instead, they will get a generic policy failure saying that not all policies were run. Additionally, any user (there's no special permission for it) can override a check-in policy failure with a comment.
The "Builds" check-in policy does the following:
Request from the server a list of build definitions affected by this check in
For each build definition returned where the last build was not "good," create a checkin policy error message containing the build definition's name and the user that triggered the build.
If the policy detects a broken CI build, show an error when you attempt to check in. "The last build failed.."
It sounds like you're trying to make sure that people don't break the build with their check-ins. TFS2010 includes a new feature called Gated Check-In that validates changes before they are committed to source control.
If you are using TFS2008 and can't upgrade, you'll need to look at something like OpenGauntlet - however the user experience is much improved with TFS2010.
TFS was originally set up with our
team's Active Directory group listed
as TFS admins. Is this the problem?
This is probably not the best idea. Team Foundation Server Administrators can do destructive things like destroy files+history and delete projects. If there's any chance that somebody might become disgruntled, you might want to reduce the number of admins or ensure that you have good backups.
As a middle-ground, you could have 1 or 2 people as TFS Admins, and everybody else as a Team Project Administrator. Most people only need Contributor access though.
In TFS2010, there is a new concept called "Project Collections". Typically, organizations have 1 or 2 people as "Project Collection Administrators" so they can add new projects and build controllers.
Check-in policies apply to everyone. Did you verify that your deployment of the policy is active on all machines?