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
Related
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.
We used TFS Aggregator to automatic update the User Story's state according to its sons state changes and also to automatic Update User Story's state of other project (if they are related).
Also important to mention that we hire an external freelance to help us doing it. When we tested it on his environment - it worked well. But when deploy it in
our environment - there's no change, the new functionality doesn't work.
what you recommend us to check ?
what can be the reasons for this integration problem?
What actions should we take?
Your advises are more than welcome!
First, try to follow the steps of installation on this website to install the plugin: https://github.com/tfsaggregator/tfsaggregator/wiki/Install
If it still doesn't work. Here is the troubleshooting page you can refer to: TFS Aggregator Troubleshooting:
You are using the right version of this server side plugin for the
right server. You can get multiple releases of this plugin at website
https://github.com/tfsaggregator/tfsaggregator
You have updated a work item that triggers a rule. (The TFS
Aggregation only works once a work item that has aggregation rules on
it is updated. This may change in a future version.)
If the rule navigates between work items, work items have a proper
Link (e.g. Parent-Child).
You copied the DLLs and the Policies file to the plugins location on
all TFS Application Tier Servers (Usually at: :\Program
Files\Microsoft Team Foundation Server {version}\Application Tier\Web
Services\bin\Plugins)
You have valid names for source and destination fields in
TFSAggregator2.ServerPlugin.policies.
When you saved the file you saved it as UTF-8 encoding (in Notepad++
it is called “utf-8 without BOM”).
You have given permission to the user running the plugin, e.g. add
the "TFS Service Account" to the Project Collection Administrators
TFS Group.
You may have to do this from the commandline using tfssecurity
/collection:http://server:8080/tfs/DefaultCollection /g+ "Project
Collection administrators" "LOCAL SERVICE" if your service account is
either LocalService, NetworkService or any other Windows Well-known
identity, since they are no longer shown in the permission UI.
When using the Impersonation option, make sure the user executing the
plugin (generally the TFS Service account) has the "Make requests on
behalf of others" permission at the server level
If you upgraded your TFS from 2013.x to 2015.* and from 2015rtm to
2015.1 and did not uninstall the TFS Aggregator before doing this TFS upgrade the aggregator does not work. Remove the TFS Aggregator from
the TFS 2013 Program Files folder or run the uninstall of the TFS
Aggegrator (backup your policies!). Then re-install the TFS
Aggegrator setup or install manually for TFS 2015 as described here.
Every TFS version has its "own" assembly for the aggregator so it is
important to use the right version against the right TFS.
Our environment is a TFS 2013 server (12.0.21005.1 Tfs2013.RTM) which was upgraded from a fresh installation of TFS 2008, with a number of team projects and developers.
One thing that our developers regularly need to do is create and edit build definitions. According to both Visual Studio and all documentation I've been able to find, there should be a "Edit build definition" privilege (perhaps along with a few others) which controls access to this. But as you can see in the screenshot, it doesn't exist in our installation:
The only workaround I've found is to grant the people in question membership of the Project Administrators group, which is clearly not desirable. There is no group like build administrators or anything of the sort which might help, either; this is the list of groups available to choose from:
As a consequence, whenever a developer wants to edit a build definition (which is perfectly appropriate in our case) they keep running into:
What, short of making everyone a project administrator in every team project they might possibly work in, can I do to resolve this?
Here's where to find the security settings for build definitions.
TFS 2015 UI: Go to the Build Explorer, click on the drop down arrow to the left of All build definitions or All XAML definitions.
VS Team Services and TFS "15" RC2 and newer: Go to Build and click on the Security button in the upper right side.
You will then get a dialog like the following with the build permissions.
The permissions that you show above are for Team Projects and not builds.
If you select a build and right-click on it you should get a permissions option. Here you will find build specific permission that you are looking for.
You can also set permissions through the API with PowerShell...
We have a TFS server setup with three projects. Recently we wanted to change TFS so that code checkins had to have a Work Item Number associated with it. I was able to accomplish this by:
In Visual Studio
Team -> Team Project Settings -> Source Control
Then select checkin policy tab and add "Require associated work items."
Source
The problem is that it only seemed to work for one of the three (the first one) projects. I've tried Team -> Team Project Collection Settings but there is no option for the checkin policy.
I've also tried highlighting the individual project I wanted to change the check in policy but they all seem to show that the checkin policy has been setup correctly for requiring a work item with code checkin.
How can I change the settings that all the projects on the TFS server have the same checkin policy?
Check-in policies are set per team project. There is no global meaning collection or server level way of setting and enforcing check-in policies on all of existing and future team projects. You will need to add appropriate check-in policies for each and every team project you need using the project level source control setting in Team Explorer. You can also use TFS client SDK to automate that process to iterate all or some of the existing team projects and add check-in policies. Another option is to take advantage of TFS server side events to get notified when a new team project is created and add check-in policies in response in case of automating the configuration of check-in policies for newly created team projects.
Team Foundation Server Event Service
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?