Project Description
A suite of TFS Plugins that enforces process guidance on the server-side across all teams and is easily customizable to meet the needs of different orgs.

TFS Plugin Suite Intro Video (10 minutes)

Why use a TFS Plugin over a Checkin Policy?

  • Ensure compliance: TFS Plugins can ensure the enforcement of policies are not overridden. Checkin policies can be overridden by the user and only a notification of noncompliance is stored. (Think of TFS Plugins as guard rails and check-in policies like rumble strips.)
  • Ease of configuration: TFS Plugins can have their configuration maintained in a centralized location that spans all team projects. Checkin policies are configured for each team project which results in a higher maintenance cost.
  • Ease of deployment: TFS Plugins are easy to deploy as the bits live on the TFS Server. Checkin policies are difficult to distribute to all TFS clients.

Plugins

Branch Merge Check-In Policy
Provides allowable source and target branch location. For example, branches from a "main" branch can be configured to only be created in a "development" folder.  In our example configuration, we follow the code promotion branch model as shown below.  This allows for branching between an "integration" and branches within a "development" folder.  Then branches within "development" may be branched to a "CodeReview" folder, which then allows branching to a "Staging" folder and likewise "Staging" to "Production". 

$/TeamProject
    ☐ CodeReview
         Ξ Release 1.0
    ☐ Development
         Ξ Release 1.0
    Ξ Integration
    ☐ Staging
         Ξ Release 1.0
    ☐ Production
         Ξ Release 1.0

Change Type Policy
Prevents users from checking in to certain areas if the changetypes associated with each item checked in are not configured.  In our example configuration, if a change type is of type branch, merge, rollback, delete, or undelete in the "Integration" branch or "CodeReview", "Staging", or "Production" folders, then it is blocked.

Inherit Only for new Branch Security
This simple policy removes explicit permissions to the newly created branch that would have otherwise been cloned from the source branch. 

Forbidden Patterns Policy
Prevents users from checking in files with forbidden filename patterns. For example, stop your users from checking in compilation output (dlls), adding personal user settings to source control or even using programming languages that you don't support. (This is basically what's found in the Power Tools version of the client-side check-in policy except that it also allows for friendly error messages.)

Work Item Association Policy
Ensures that the associated work items to a checkin comply with standards that you set. The following standards can be enforced:

  • Specify work item queries whose results will be the only legal work items for a check-in to be associated with. (e.g. Require an active task that is assigned to the submitter.)
  • Stop check-ins if the associated work items match the results from a work item query. (e.g. Deny direct assignment to work items categorized as requirements.)
  • Limit the work in progress so that each commit of code reflects one task. (e.g. Enforce that only a single task is used for each check-in.)
  • Ensure associated work is set to a current iteration. Iterations classified a past or future (determined by the iteration's start and end dates) will not be allowed.

Pattern Bypass Override
Allow for certain version control paths defined by Regex get a free pass on server-side check-in policies.

Account Override
Allow for configured groups (i.e. service accounts) to bypass server-side check-in policies.

Last edited Nov 17 at 3:35 PM by thisisntjared, version 43