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.

 

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

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:
 
 

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

Pivot Table und/oder Chart wählen:

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

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.

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

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:

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