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?
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.
I'm working with TFS 2015 using the ALM Rangers Development & Release Isolation Branching Strategy and Team Foundation Version Control. I would like to keep developers from checking code into the Main branch and letting them only work in Dev and Release branches. I want to allow the Project Administrators and above to perform the merges and check ins to Main.
With Team Web Access:
I selected the drop-down next to my Main branch and selected
"Security".
Set Inheritance to "Off".
For Contributors, Set Check in and a few other permissions to "Deny".
Saved Changes.
For Project Administrators, set the same permissions to "Allow"
Saved Changes.
TFS changed the values of each of the Project Administrators permissions to "Inherited deny*"
I have heard that setting "deny" can cause problems. Now I understand why I was told that. Is there a way to achieve my stated goal above, through standard TFS permission settings?
Cann’t reproduce your problem with the same settings in my TFS2015.
According to TFS permission setting, most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.
To achieve what you want, you can create a new group such as DenyMainGroup. Adding the developers to this group. Make sure your project administrator members don’t belong to it. For this group, set Check in and a few other permissions to “Deny”. For Contributors and Project Administrators, set the same permissions to”Allow”. Saved Changes.
I manage a large TFS 2013 team project, whose code we're now splitting into multiple independent parts, each part becoming a tenant in the team project. Each such part would have its own build definition(s). I want people in each part to be able to create/edit/manage their build definitions, but not others.
Currently, I create the build definitions myself upon request, and then set permissions on the new definitions, and tell people to edit them. I have permissions to that since I'm in the Builders VSO group, and therefore have Edit build definition and Administrator build permissions on the Team project.
However, I'd like to grant everyone the permission to create new build definitions and administer them, but not have permissions to change other permissions. Is this possible in TFS?
Its not currently possible to do that out of the box. However, you could setup a webpage that automated the task that you currently perform and add a new build definition and give permission to the correct team... Then they can manage it from then.
I would recommend using PowerShell for the action and the webpage mearly calls that.
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