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
Related
I have a requirement from our company auditors to be able to prove who can alter code in our source repository. Is there a method of producing a report detailing permissions?
Ideally the report would show all permissions but at least it needs to show check-in permissions. Ideally the report would be standard functionality as this tends to lead to less questioning from the auditors, but if not possible then custom reports/queries would be manageable.
We're using TFS 2018 on premise.
You could check extension TFS Permission Visualizer, which displays TFS security groups and permissions in a form of a graph.
Also, you could refer to the solution Extracting effective permissions from TFS on GitHub. This practical guidance and sample code is based on extensive research to address two of the commonly heard requests on Team Foundation Server security:
Report on the effective permissions of a TFS user/group.
Report on security auditing for TFS.
Clone and build TFS Team Project Manager.
Here's what it looks like:
See also: https://github.com/ALM-Rangers/Extracting-effective-permissions-from-TFS/blob/master/Doc/Extracting%20effective%20permissions%20whitepaper.md
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.
I currently use SourceGear Vault for version control but I'm looking at switching over to TFS. Vault has a nice feature called "Share", which effectively lets you put the same file in different points in the tree - check it out in one place and it is locked in the other, check it back in and both copies change. I've had a brief look at TFVC and I can't see anything like this - am I missing it?
There is no support for "Share" in TFS. You may be able to leverage two different TFS workspaces to accommodate your requirements, or you may be required to do some restructuring of your code.
(Historical note: "Sharing" actually came from Visual SourceSafe and SourceGear Vault added it because we wanted feature parity with Visual SourceSafe. Our goal at that time was to build "a compelling replacement to Visual SourceSafe", which meant we had to implement share and - much worse - pin.)
Currently our build solution is set up using TFS + MS Build scripts.
TFS is also being used as a CI server.
I've seen several posts on this site telling people about other CI solutions.
Are there any compelling options to move to another Solution for our build system?
Or in other words what are we missing out on by using TFS?
EDIT
We are using TFS for source control / issue tracking and I think this is a good solution, im just wondering about the other options for build server / CI server integrating with TFS.
The main problem with TFS is that if you have a server crash, restoring your source code is non-trivial. This is unbelievably bad since the most important aspect of any source control system must be to be fail-resistent, at least if you perform all backups as you should.
IMHO the greatest benefit of TFS is that everything is integrated in the IDE: work items, bug tracking, CI, Code analysis, ...
I have used TFS in the past but my current company use SubVersion/Team City/FogBugz to implement the same functionality provided in the TFS solution.
I would say that from a technical implementation perspective, you can gain additional features from a non-TFS system that TFS would be a nightmare to configure.
However, that said, one of the biggest reasons for not going for TFS is the cost of running such a system. The big advantage of TFS is the integration of everything which makes people use it more as the more you put in, the more you get out. The worst case scenario is a system that people can’t be bothered using which adds no value to the company’s development.
In my opinion, if you are already on TFS and can afford to stick with do, do just that!
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....