Wie erstelle ich ein TFS Report, der mir zeigt, welche Checkins mit einem Policy Override durchgeführt wurden?


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

Comments (0)