Archiv

Posts Tagged ‘TFS’

Einfaches KPI-Reporting im Dashboard des Team Foundation Server

Zu jedem Projekt im Team Foundation Server (wie auch im TFS Service in der Cloud) existiert ein webbasiertes Dashboard. Dieses ist erreichbar aus dem Team Explorer im Visual Studio .NET Client aber natürlich auch über eine URL im Browser.

Die URL ist aufgebaut nach dem Schema:  http://tfs-server.de/Collection-Name/Projekt-Bezeichnung

Auf der Startseite – dem Dashboard werden per Default einige Kacheln (Tiles) angezeigt. Diese kann man per Drag & Drop anordnen. Es werden immer vier Kacheln auf einer Zeile angezeigt. Leider gibt es keine Trennzeilen oder Trenn-Kacheln. Man kann andere Kacheln, die Ergebnisse von Build-Definitionen (und deren Builds) anzeigen, als optische Trenner verwenden.

tfs_dashboard_tiles

Die Kacheln sind Ergebnisse von Shared Queries (also zur Verfügung gestellte TFS-Abfragen auf Work-Items für das gesamte Projektteam) und zeigen als großen Zahl die immer aktuelle Anzahl der von der jeweiligen Abfrage zurückgegebenen/angezeigten Work-Items. Damit eignen sich die Kacheln für schnelles Reporting von KPIs im Bugfixing, wie:

  • offene Bugs insgesamt
  • Bugs verteilt nach Fehlerklassen (z.B. hoch/mittel/leicht)
  • gerade aktive Bugs in Bearbeitung
  • heute bereits gefixte Bugs

Um Kacheln hinzuzufügen, muss man also im Reiter „Arbeit“ unter „Abfragen“ einfach die vorhandene TFS-Abfrage per Drag & Drop in „Teamfavoriten“ fallen lassen. Danach taucht die Kachel für die Abfrage automatisch auf der Startseite auf.

teamfavoriten

Kategorien:Team Foundation Server Schlagwörter:

Import von Vorgängen aus Microsoft Project in den TFS

Die Zielstellung nochmal kurz zusammengefasst. Man hat zum Start eines Projekts ein Projektplan in Microsoft Project (hier Version 2013) erstellt und will nun Vorgänge aus dem Projektplan in ein Projekt im Team Foundation Server (oder Team Foundation Service) hochladen.

Systemvoraussetzung ist lokal der Visual Studio Team Explorer in der identischen Version, wie auch der TFS. Wenn die Installation erfolgreich war, gibt es in den Office-Produkten ein weiteren Bereich „Team“ in der Ribbonleiste (Symbolleiste). Dort muss man sich mit dem gewünschten TFS und Teamprojekt verbinden.

Nachdem man im Microsoft Project sich mit dem TFS Projekt erfolgreich verbunden hat, kommen automatisch einige entsprechende Vorgangsspalten hinzu:

Zusätzliche Vorgangsspalten aus dem TFS

Zusätzliche Vorgangsspalten aus dem TFS

Und nun geht die Krux auch los – man muss in diesen Vorgangsspalten selbst für die einzelnen Vorgänge die Werte festlegen. Insbesondere ist der Typ des zu erzeugenden Work Items wichtig. Da gibts ja ganz nach Projektvorlage so einige Arten von Work Items im TFS.

Leider zeigt sich Project in Verbindung mit dem TFS ein wenig uneinsichtig und unflexibel. Denn meist befinden sich in einem Projektplan auch Vorgänge (z.B. Meilensteine), die man nicht als Work Items im TFS Projekt haben will.

Hinweismeldung von Project

Hinweismeldung von Project

Workaround ist hier wohl, alle Vorgänge eines Projektplans zu importieren und anschließend die „unbrauchbaren“ Work Items auf eine „Müll-Iteration“ zu legen.

Unterstützung von SCRUM im Team Foundation Service

6. Februar 2013 Hinterlasse einen Kommentar

Der Team Foundation Service ist ein neuer Dienst für Entwicklungsteams zur Source-Code Verwaltung, welcher auf der Konferenz Build 2012 von Microsoft vorgestellt wurde. Der Dienst bietet neben der reinen Source-Codeverwaltung in der Cloud out-of-the-box auch eine aus meiner Sicht gute Tool-Unterstützung für die Durchführung der SCRUM Methode in Entwicklungsteams.

Dashboard, genannt „Team Portal“:
Das Dashboard bietet auf enen Blick den Burndown-Chart, die abgearbeiteten Stunden, und eine Statistik mit den aktuellen Zahlen zu Product Backlog Items, Feedback-Items und Bugs.

Dashboard-Ansicht im Projekt (Quelle: Microsoft)

Dashboard-Ansicht im Projekt (Quelle: Microsoft)

Product Backlog:

Der Product-Backlog unterstützt die Sammlung von Product Features in Form von Work-Items, die geschachtelt werden können, um so Features noch weiter zu unterteilen.

Product-Backlog

Product-Backlog (Quelle: Microsoft)

Sprint-Backlog:

Anschließend beim Sprint-Planning werden die Features aus dem Product-Backlog in für jeden Sprint extra Sprint-Backlogs verschoben.

Sprint-Backlog

Sprint-Backlog (Quelle: Microsoft)

Die automatische Anzeige der Entwicklerauslastung auf Stundenbasis erleichtert die Sprintplanung im Entwickler-Team.

Anzeige der Auslastung auf Stundenbasis

Anzeige der Auslastung auf Stundenbasis (Quelle: Microsoft)

Task-Board/Planning Board:
Diese elektronische Repräsentation eines analogen Task-Boards bietet sich perfekt an für Stand-Ups an einem Beamer oder großen Screen. In dem Task-Board ist Drag & Drop möglich, so dass die Task direkt verschoben werden können.

Task-Board

Task-Board (Quelle: Microsoft)

Volltextsuche in Work Items im Team Foundation Server

3. August 2012 1 Kommentar

Leider gibt es im Visual Studio 2010 von Haus aus keine Möglichkeit, eine Volltextsuche in allen Work Items durchzuführen. Der Workaround ist die Team Web Access (Webfrontend) des TFS. Dort ist es einfach möglich, in dem man links in der Navigation das Suche-Feld benutzt. Funktioniert auch sehr schnell, da die Work Items im SQL Server indiziert sind.

Kategorien:Team Foundation Server, Visual Studio Schlagwörter:

Mit Excel im TFS eine Vielzahl von Work Items anlegen

16. August 2010 Hinterlasse einen Kommentar

Dank Excel kann man eine Vielzahl von Work-Items im TFS anlegen, ohne dies zeitaufreibend im Team Explorer von Visual Studio durchzuführen. Als Systemvoraussetzung dafür ist ein installierter Team Explorer und Visual Studio notwendig.

Im Menü „Team“ in Excel den Punkt „neue Liste“ anklicken und folgender Dialog erscheint:

Anschließend wählt man das gewünschte Projekt im TFS aus. Die entsprechende Work-Itemliste wählt man aus, in dem in der Spalte „Work Item Type“ in jeweiligen Zeile der passende Typ für das anzulegende Work Item ausgewählt wird.

Beim Auswählen von zusätzlichen Spalten (Button „Spalten wählen“) zum Work-Item werden magischerweise noch weitere Felder hinzugefügt. Diese sind die Pflichtfelder, welche zum Work-Item ausgefüllt werden müssen. Wenn nicht alle Pflichtfelder als Spalten in Excel vorhanden sind und mit Inhalten befüllt werden, kann das Work-Item im TFS nicht angelegt werden!

Die Work-Items werden in den einzelnen Zeilen eingegeben. Eine Zeile in Excel ist ein Work-Item.

Abschließend „Veröffentlichen“ in der Symbolleiste klicken. Nun springt ein Dialogfeld auf, in dem angezeigt wird, wenn Work-Items nicht angelegt werden konnten. Bei Doppelklick auf eine Work-Item sieht man auch die genaue Fehlermeldung.

Erst wenn in der Statuszeile von Excel steht, dass der Vorgang erfolgreich abgeschlossen wurde, dann sind die Work-Items auch angelegt. Dann tauchen in der Spalte „ID“ auch die generierten IDs zu den angelegten Work-Items aus dem TFS auf.

Kategorien:Microsoft Office, Team Foundation Server Schlagwörter: ,

Ausführung von Unit Tests im Team Build ganz einfach

Voraussetzungen:

  1. VSTS und TFS 2008
  2. Eine Build-Definition wurde bereits erstellt
  3. Es gibt eine Assembly, welche die Unit Tests enthält

Folgende Änderungen müssen in dem bestehenden Projekt-File (TFSBuild.proj) zur Builddefinition im Team Build durchgeführt werden:

  1. Hinzufügen der DLL, welche die Unit-Tests enthält in die ItemGroup:
    <TestContainer Include="$(OutDir)\meineUnitTests.dll" />
  2. Auflisten der auszuführenden Tests (Name der Testklasse):
    <TestNames>UserRepositoryTests</TestNames>
  3. Anschalten des Durchlaufens von Unit Tests nach dem Kompilieren:
    <RunTest>true</RunTest>

Es wird automatisch ein entsprechender Build Step angezeigt in der Übersicht zum gelaufenen Build. Testergebnisse finden sich im konfigurierten Build-Drop Ordner im Unterverzeichnis „TestResults“. Dort werden Dateien vom Typ „Visual Studio Test Result“ mit der Endung „trx“ abgelegt.

Achtung Stolperstein:

Der standardmäßige „Copy Task“ wird bei einem erfolgreichen Build als Build Step mit der Bezeichnung „Copying binaries to droplocation“ angezeigt. Wenn jedoch das Kompilieren erfolgreich ist, und das Testen der Unit Tests fehlschlägt wird dieser Copy Task nicht ausgeführt. Leider wird dann auch der o.g. Build Step nicht angezeigt und man sieht also nicht, dass dieser Task fehlgeschlagen ist.

Kategorien:Team Foundation Server Schlagwörter:

SolutionRoot Variable im TFS Teambuild

Man nimmt an, dass im TFS Teambuild die Property $SolutionRoot das Verzeichnis der Visual Studio Solution ist. Ist es aber nicht, wie ich heute schmerzhaft feststellen musste. 😦 Es zeigt lediglich auf $(BuildDirectoryPath)\$(TeamProject)\BuildType\Sources. Als Beispiel: d:\build\TeamProject1\Nightly Build\Sources.

Bislang habe ich kein Property gefunden, die direkt in das Verzeichnis der Visual Studio Solution zeigt. Man muss sich also mit harten Pfaden begnügen.

Kategorien:Team Foundation Server Schlagwörter:
%d Bloggern gefällt das: