In our organization we use TFS 2018 and Visual Studio 2017 Enterprise.
As far as I got until now, there is a way "client-side", configuring from Visual Studio, selecting Team\Team Project Settings\Source Control\Check-in Policy\Code Analysis and I should the custom ruleset defined.
I need two things:
Set a custom guideline that is mix of both default Microsoft ones and other tools' guidelines, like Roslynator or StyleCop.
Create a custom policy server side in order to prevent check-in from Visual Studio (or whatever client we can think of) if code is not compliant to those guidelines.
For the first point, I'll make a clear simple example.
There are the guidelines embedded in Visual Studio.
But they are not complete and I would like to extend them, taking stuff here and there or defining new ones from scratch.
I want to use e.g.:
CA1500: Variable names should not match field names (from default Visual Studio Managed Binary Analysis)
RCS1145: Remove redundant 'as' operator (from Roslynator)
RCS1204 Use EventArgs.Empty (from Roslynator)
SA1302: InterfaceNamesMustBeginWithI (from StyleCop)
SA1305: FieldNamesMustNotUseHungarianNotation (from StyleCop)
How can I do it? And can i do it without make me define it at project level (like incorporating stylecop file for every .csprj) but more at least at solution or Team Project level?
For the second point, I already defined the compulsory comment and compulsory work item attached.
And I can even define new policies, it's true, but they can all be overridden client side.
Is it possible to prevent that?
The best solution for this is two part:
Educate your users to configure the right policies and editor settings. Creating custom project templates and distributing those can help (or deploying a custom build target onto the machine which enforces good defaults.. Having a good local policy will help people do the right thing and people who are supported to do the right thing will likely not try to get around that.
Setup a CI build for your projects. VSTS and TFS have a nice feature which will run a build whenever code is changed. You can even set it up as a Gated Checkin build which will check the sources before they're checked in. This check happens on the server and is much harder to by-pass. You can also configure the build to always override the code analysis settings, even if they're not configured in the project. My MsBuild Helper tasks will help you setup the right MsBuild properties to do that.
As to your more specific questions:
You cannot setup Code Analysis Rules at the Team Project level without also configuring the ruleset for all Visual Studio Projects. Otherwise the checkin policy will cause the check-in to fail, but the developer will then still have to update all projects in the solution with the right ruleset.
You cannot prevent people from by-passing the local check-in policy. The best you can do is to use Reporting Services and Alerts to detect the breach of policy and take corrective action.
You could add the Rule Set into TFS source control and then select it from Code Analysis Policy Editor. Check the screenshot below:
Check-in policy is already applied to a team project, not a single project.
To edit check-in policy, you must have the Edit project-level information permission. You could deny this permission for the users to prevent them from editing the check-in policy.
Related
We have code that we want to be excluded from our Check-In policy that runs a custom code analysis rule set through our on-prem TFS server. We need to install the TFS Power Tools to implement the Custom Path Policy.
The problem is, we have a large number of non .Net developers using our same area for checking in code (i.e. DB developers, QA Engineers) and would like to exclude their code from our check-in policy (it doesn't apply). The only way we can find to do this is through the custom path settings which means they all have to install the Power Tools on their local machines as well.
Is there any other way other than moving the code to another area or having them install the Power tools to exclude their code?
I don't think there is a better way to achieve that except the two ways you mentioned.
Theoretically speaking, the policy in TFS server side can achieve that. Please refer to below link and check if that helpful.
http://almsports.net/tfs-server-side-check-in-policy-for-git-repositories/1025/
You can also reference the related thread: Restricting TFS check-in policy to specific users
I have been asked to create a second custom checkin policy for a second project on our TFS server. So both projects reside on the same TFS server in the same collection but are different projects under that collection. I created the second check-in policy just like the first. When I run the VSIX installer the new one installs. Once I run VS 2015 I can see both custom check-in policies under the TOOS/Extensions and Updates. However when I go to TEAM/Team Project Settings/Source Control/Check-in Policy the new one does not show when you click "Add". The existing one is there but not the new one.
Is there an issue with having two custom check-in policies?
First please make sure you have selected the right team project. Since the check-in policy is based on team project- level.
Also remember to registering Custom Policy:
You need to add an entry to the Windows registry so that your policy appears in the Add Check-in Policy dialog box.
Here is an example of the .reg file that registers the policy.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Checkin Policies]
"Devart.ReviewAssistant.TeamFoundation"="c:\\Program Files\\Devart\\ReviewAssistant\\Devart.ReviewAssistant.TeamFoundation.dll"
Note: that you must install the policy assembly on every computer that needs to have a reference the assembly.
Make sure that you provide valid installation instructions for your policy as it will help fellow developers to install it. More detailed info please refer this blog: Creating TFS Custom Check-in Policy
I'd like to write a new custom policy for TFS 2010 and see that policy in VS.net 2010. I want the policy to block when a work item is associated with a check in and either:
the code is in a particular folder
the work item is tagged in a particular area
What I want to do is say that some parts of my team project are "high risk" and make people do more stuff (like testing, code review).
However, I want to only apply the policy to some areas or source control folders not the whole team project. Splitting the team project is not an option.
To limit a checkin to only apply to a specific source control folder, you can use the custom path policy: http://blogs.msdn.com/b/bharry/archive/2007/02/23/yet-more-team-foundation-server-power-tools.aspx
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?
I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.
Is it possible to deploy a custom check-in policy that works in such an environment ?
Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.
But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.
So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?
Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?
Or do custom check-in policies only ever exist on the client side ?
The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.
No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."
A walkthru with screenshots is on Brian's blog:
....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!
Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....