Experience using TFS 2010: (Control System. Rights and Policies)

Last time, I wrote about creating branches, Experience using TFS 2010: (Control System . Branches. Creating ) and one of the options for their hierarchy. In this part, I will try to disclose the work with the control system in more detail and dwell on the means of controlling access to the code in the branches and CheckIn policies.

Setting permissions on actions in branches

And so, the next step is to configure access rights to the branches and prohibit certain actions so that the code is always of high quality. There is a slight digression, there is no such possibility in ClearCase UCM, there are only some rights settings, for example, settings such as not to do Deliver (Merge to the site branch or integration branch) if the file is in check-out, or to prohibit Merge from the branch developer to another developer’s thread. But all these settings apply to all users. Of course, the system administrator can create several groups with different rights, but such a setting is available only on the server side, and as I said, no system administrator can do this.
In TFS2010, it is possible to configure access rights to branches individually, for example, you can allow the integrator to do Merge in the integration branch and site branch, but the developer should be prohibited.
And the project administrator can do this (for example, the project leader, or the project manager). I will not describe all the possible options for setting rights. I will only show one of the possibilities, for example, to prohibit developers from making changes in the site branch and in another branch, and to work only in my own.
So that all changes are merged into the site branch through a single access point - the Integrator, which is responsible for the quality of the code with your head. To do this, I created an Integrators user group and allowed them to do some things on the integration branch and site branch, forbid everyone else to do these things, see Figure 1 and Figure 2.

Figure 1 - Integrator rights over the site and integration branch


Figure 2 - Developer rights of on-site and branch integration

also need to prohibit developers and integrators to climb into other people's branches and make changes to them, for example, I have forbidden integrator make changes to the branch developer Trollik, see. Figure 3 and left him only the right smo ret code.
Figure 3 - Integrator rights in the developer branch

Naturally, the lamerok and Trollik developers themselves need to put full access rights to their branch. I got what I wanted, now we have a system that obeys the rules:

1. You cannot change the code in other people's branches
2. Only the integrator has the right to change the code in the site and integration branch
3. Everyone can read the code from any branch

Check-in Policy

And so, I forbade developers to merge their changes into the site branch themselves, as well as change the code not in their branches. Now you need to prevent them from doing check-in of poor-quality code.
ClearCase does not have such an opportunity, since this operation already refers to the workflow management section and does not have to be related to the control system itself, however TFS is an integrated system, this can and should be done here.
I always have to be sure that even in my own branches, developers have code that complies with the quality standard. But before making the settings, I will add an empty project so that there is something to work on.
After that, you can configure the Check-In policy. To do this, in Team Explorer, by clicking on the project, right-clicking the mouse, select Team Project Settings and Source Control, see Figure 4.
Figure 4 - Selecting CheckIn policy settings

We are given the opportunity to choose from 4 options:

• Builds policy - prohibits check-in of code if there are errors during assembly (compilation)
• Code Analysis policy - prohibits code check-in if there are Code Analysis errors (also detected at the compilation stage by Code Analysis)
  
• Testing Policy - prohibits code check-in if at least one of the tests from the list fails. In most cases, we mean unit tests, but nothing prevents you from adding system tests, for example, user interface tests, to this list.
  
• WorkItem - prohibits doing check-in of the code if the developer did not associate the changes with the task or bug, or any other type of work item that is assigned to it.

Of course, I want to select everything, because I am very worried about the quality of the code, see Figure 5
Figure 5 - CheckIn policy I will

add Build and CodeAnalysis policies one by one. For Code Analysis, I’ll choose the minimum recommended by Microsoft, I’m not a beast, and the developers should have at least some space for creativity, see Figure 6.
Figure 6 - CheckIn Policy Analysis Code

Next step - I need to add the Testing Policy, here the situation is a little more complicated. We do not have a list of tests right now. We need to create it. First, add to the file MyClass.cs. which we have in the project, a simple method that returns true if the number is greater than 0 and false otherwise, see Figure 7.

Figure 7 - Method class MyClass

After that, we can create a test for the MyMethod method and add this test to the list of tests. To do this, we need to add a test project to the solution, just do this by standing on the solution and right-clicking on the menu Add-> New Project-> Test Project. After this operation, the test file appeared, and the settings for the tests in the Solution Items list, but the file does not contain a single test or test list, because we have not yet created the tests, and now that the test project is created, we can easily do this using the right mouse, standing on the method, see Figure 8.

Figure 8 - Creating a unit test

The unit test was done automatically, and by default, it fails. In addition, now this unit test is in the test file TestSolution.vsmdi-> All Loaded Tests. However, we need to create a list of tests that will run before each checkin operation. Create such a list by clicking on the file TestSolution.vsmdi, in solution. Let's call it TestForCheckInPolitics and then move our unit test to this list, see Figure 9.
Figure 9 - Creating a list of tests for CheckIn policy

Now that we have a list of tests, we need to add it to control. To do this, check the test file (TestSolution.vsmdi). After that we can add it to the policy. To do this, select the Testing Policy in the window shown in Figure 5, specify the test file and the list of tests for the CheckIn policy, see Figure 10
Figure 10 - Selecting a list of tests for the CheckIn policy.

In addition, in order to be sure that the developer changes the code only on assignment, we will also establish the last policy - link CheckIn with the work item.
After the CheckIn policy is configured, we will try to check our code. As can be seen from Figure 11, we suffered a complete fiasco.
Figure 11 - CheckIn policy

worked. All policies worked right away, let's try to fix the situation consistently.
First, turn on CodeAnalysis for the solution projects and set the rules for them, the same as we set for the CheckIn policy (minimum recommended by Microsoft), then make a build, run unit tests and try to check the files again, as can be seen from Figure 12, we are still we can’t do this, because our test fails and we did not indicate a connection with the work item.
Figure 12 - CheckIn Policy Violation

Change the unit test so that it passes and associate our work with the work item, see Figure 13.

Figure 13 - Link to the work item

Now the system has allowed us to zakeciniruet files and the whole team is sure that in the developer's branch always there is a code that is built without problems, and does not affect the work of the rest of the system, since it passed all unit tests.
It should be noted that you can bypass the policy by checking the Override Policy check box, but in this case you will have to write the reason, and your project manager or leader will receive a spiteful letter describing the violation.
Such a process has repeatedly helped the team from unauthorized changes. In the beginning, the team was a bit slow, because before that everything was done in haste, but over time the team got used to it and there were much fewer errors in the developed software. In general, team development, and the exchange of changes in the TFS version control system, is a separate topic for a separate post ...
Useful links:
Team development using Visual Studio Team Foundation Server: Reference