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
Related
So I have a TFVC setup that has no Git branches however when I go to link a work item, it only comes up with Git, how do I link work items to TFVC branches? The only documentation I find all uses Git, for everything.
I am trying to have my tasks set up so that when a new task is created, I would create a branch off of Development for that task. However I can't seem to do this as everything is defaulting to Git and it seems like my workspace has no knowledge of the TFVC branches!
Link work item to Branch only support for GIT, it's not supported for TFVC. See Link types showing in the Development section for details.
For Team Foundation version control (TFVC), it lets you link work items to version control changesets or versioned source code files by using the Changeset and Versioned Item link types. When you check in pending changes or use My Work to check in changes, work items are automatically linked to your changes.
So, you can link work item with the link type Changeset or Versioned Item, or create another Git repository, you can use both TFVC and Git in the same project.
UPDATE:
That's a good idea to support TFVC, I have help you submitted the user voice here, you can go and vote it up to achieve it in future.
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 work in a SQL Development Environment.
We have three branches namely DEV, TEST and LIVE.
Whenever a developer did something and wants to deploy on Test System i need a mechanism within TFS that enforces him to do a code review.
I know this can be done by enforcing a code review check-in policy.
But I don't want to trigger a code review with every check-in but more whenever somebody merges to TEST branch.
Think of it more as an approval enforcement. I want that TFS is requesting a code reviewe whenever somebody branches into a different branch. The best scenario is that i can specify the branches that trigger this behaviour.
Code Review Check-in policy can specify a path to apply this policy to, so you can only apply this policy to your TEST branch:
By the way, if you use Git team project in TFS 2017 or VSTS, you can enable branch policies to require code reviews for a branch. More information, check: https://www.visualstudio.com/en-us/docs/git/branch-policies
I am looking for an alternative to branching in TFS with the goal of allowing multiple developers to continually integrate into a single changeset that is not in branch (aka a shelveset).
I know that a single user can update their own shelveset, and other users can pull that shelveset - but is it possible to allow several users to modify the same shelveset?
I understand that branching is preferred but I would still like to know if it is possible, maybe by using some sort of TFS powertool or modification.
No this is not possible. A shelveset is owned by a single user. it's also not recommended, as the shelveset is only a single snapshot of the change.
If you'd like something like this, you could consider git tf to create a local git repository which can be synced between two developers. Once they're finished one of the developers can push the change(s) back into TFS.
Moving from TFVC to Git has become easier with the release of TFS 2015u1:
Team Services | TFS 2015
In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project created with Team Foundation Version Control (TFVC). You can also add a TFVC repo to a team project created with Git. This allows you to adopt a new version control system while preserving all the data in your team project.
As to ways to persuade people to move, that's a hard question. You'd first need to understand what is holding them back, explain the, what advantages Git brings, what disadvantages you see in the current setup. You will probably need to hand-hold or train them so they get comfortable with Git. Using git-tf for a while may give them more confidence to make the move.
I have a team project that contains n number of branches, and each branch contains a Database folder in the root. The database folder is where developers check in views, stored procedures, etc. We have had some issues with developers checking in SQL Code that was poorly written, introduced performance bottlenecks, and so on. The DBA has asked me to prevent developers from checking in changes to the Database folder until he has had a chance to review them.
I know that I can add a 'Database Reviewer' as part of a required check-in note, but I don't need a database review every time a developer checks in; I only need the database review to be required if the changeset contains changes to the Database folder. I haven't been able to come up with anything worthwhile on Google, so I don't think that this is functionality that is built in to TFS. Could someone point in the direction of how to resolve this, or explain how they resolved a similar problem in the past?
Thanks!
There is no clear cut solution for this, but you have a few options.
Remove the check-in permissions to the Database folder for normal developers and have them send their changes as a Shelveset to the Database guy.
Ask the developers to become more professional and have them walk by the SQL guy to review their code with them, so that they will be more proficient in SQL later (would be my preferred choice is the SQL Guy isn't part of the team)
Ask the SQL guy to join the team and have him pair with the developers when writing complex SQL scripts (that's even better).
There is no option to make the check-in note optional for specific branches, folders or files right built into the product, but by developing a custom checkin policy you could require data to be entered in the Database Reviewed field. Combine this with the Custom path policy to limit this check-in policy to specific paths in source control.
That custom policy would look something like this:
public override PolicyFailure[] Evaluate()
{
if (
PendingCheckin.CheckinNotes.CheckinNotes.Values.Any(
note => note.Name == "Database Reviewed By" && string.IsNullOrWhiteSpace(note.Value)))
{
return new PolicyFailure[]{new PolicyFailure("Database Review Required", this) };
}
else
{
return new PolicyFailure[0];
}
}
Check out this small sample project to see how you can create a custom checkin policy. And the requirements if your Check-in policy needs to support multiple Visual Studio versions.
TFS 2012 adds a Code Review feature which can be made required using a 3rd party check-in policy (again, combine with the custom path Policy to make it required only for certain paths). There are a few projects on codeplex that provide similar features for older versions of TFS. These include Team Review and TFS Review Workflow.
There isn't anything built in to handle this. I think the best way to handle it would be to lock down those folders so developers can't check in there. Create a branch/folder where you can allow the developers to check in there. This would give the DBAs the ability to review the changes before they merge/migrate them.
TFS 2012 includes a code review workflow that could also be used if you could upgrade TFS. There is also a custom add-on called Team Review that works with TFS 2008. It provides a nice workflow but it would still be voluntary.
https://teamreview.codeplex.com/releases/view/40528
Thanks,
Mike