Der Team Foundation Server bietet via CheckIn Policies die Möglichkeit beim CheckIn von Source bestimmte Regeln zu verifizieren, bevor der CheckIn durchgeführt werden kann. Zum Beispiel muss vor dem Checkin ein Unit Test oder Build durchgeführt werden.

image 

Allerdings kann ein Developer ein Policy Override durchführen,
daher die konfigurierten Policies umgehen. Hierzu muss er aber ein
Override Reason angeben:

image

Damit haben wir die Policy umgangen.

Und wie es im Leben so ist, hat gerade dieser Checkin ein Build Fehler
des Teambuilds verursacht.....

Frag man sich warum das Design den Override erlaubt?
Ganz einfach, im Alltag gibt Situationen, in denen der Override
der richtige Weg ist. Wir gehen davon aus, das diese Möglichkeit
nur in entsprechenden Situationen verwendet wird.

Wie erkenne ich also, dass diese Hintertür nicht verwendet wird um
den Prozess zu umgehen?
Klar, an häufigen Build Fehlern, sind diese aber darauf zurückzuführen,
dass Prozesse nicht gelebt werden?

Ganz einfach mit Excel 2007 Reporting. Via Analysis Services:
 
image 

Als erstes eine Verbindung mit dem DataWarehouse herstellen (TeamSystem Cube):

image

Pivot Table und/oder Chart wählen:

image

in der Pivot Table Field List das Code Churn Subset wählen und folgende Felder
hinzufügen:

image

Für das Policy Override Comment Field ein "Label Filter" auf "Unknown" setzen.
Dies führt dazu, dass nur Changesets angezeigt werden, die ein Override Comment haben,
der bei einem Override gesetzt werden muss.

image

Das wars! Man bekommt den Changeset, die Person und den Override Comment:

image

Wer noch mehr Infos braucht, z.B. wie viel Code Zeilen geändert wurden und in welchem Source File, erweitert den Report noch ein wenig:

image

Ziel der Policies ist eine möglichst hohe Code Qualität zu erzeugen, aber dennoch
die nötige Flexibilität dem Team zu geben. Mit Reporting hat man die Möglichkeit
zu verifizieren, dass der Entwicklungsprozess wirklich gelebt wird.

Viel Spass

Chris