Apr 282015
 

In den TFS Schulungen kam häufiger die Frage wie man ermitteln kann welche User einen Local oder Server Workspace verwenden. Seit TFS 2012 kann man pro Team Project Collection bestimmen ob die Benutzer standardmäßig einen Server oder Local Workspace anlegen. (Siehe https://msdn.microsoft.com/en-us/library/bb892960.aspx) Dies hindert jedoch niemanden selbst zu entscheiden welchen Workspace Typ man nutzen will. Jeder kann per Option in Visual Studio über „Manage Workspaces“->“Edit“->“Advanced“ selbst entscheiden welche Variante er bevorzugt.

Möchte man herausfinden welche Benutzer welchen Typ verwenden hilft ein wenig .NET Code:

  1. class Program
  2. {
  3.     static void Main(string[] args)
  4.     {
  5.         var teamProjectPicker = new TeamProjectPicker(TeamProjectPickerMode.NoProject, false);
  6.         teamProjectPicker.ShowDialog();
  7.         var teamProjectCollection = teamProjectPicker.SelectedTeamProjectCollection;
  8.         var versionControlService = teamProjectCollection.GetService<VersionControlServer>();
  9.         var workspaces = versionControlService.QueryWorkspaces(null, null, null);
  10.         foreach (var workspace in workspaces)
  11.             Console.WriteLine(„Workspace: {0}nComputer: {1}nOwner: {2}nLocation: {3}nn“,
  12.                 workspace.Name, workspace.Computer, workspace.OwnerDisplayName, workspace.Location);
  13.         Console.ReadKey();
  14.     }
  15. }

Nach der Verbindung zu einer Team Project Collection, werden von dieser alle Workspaces geholt. Danach erfolgt lediglich die Ausgabe von Workspace Name, Computer Name, Benutzer und eben der Location (Server / Local) auf der Console.

Das Beispiel gibt es auch hier zum Download.

Jul 292013
 

In den TFS Trainings kommt häufiger die Frage wie man neue Workitems per API anlegen kann. Zum Beispiel ist das sinnvoll wenn in jedem Sprint gewisse Aufgaben erneut erledigt werden sollen. Eine Variante ist sicher das Kopieren der Workitems per Excel oder in Visual Studio per Kontextmenü. Um mehr Möglichkeiten zu haben soll in dem Beitrag auf die .NET API eingegangen werden. Am Ende soll ein neues Product Backlog Item im TFS angelegt sein, sowie ein neuer verknüpfter Testcase.

Der Beispielcode sollte mit jeden Teamproject ab Scrum Version 2.0 funktionieren. Für andere Process Teamplates müsste dann z.B. “Product Backlog Item” in “User Story” oder “Requirement” geändert werden. Auch die Felder der Workitems können natürlich abweichen, je nachdem was man füllen möchte.

1. Benötigte Referenzen

Microsoft.TeamFoundation.Client, Microsoft.TeamFoundation.WorkItemTracking.Client

2. Connection zum TFS

Ein Weg sich am TFS anzumelden ist der Standarddialog welcher auch in Visual Studio erscheint. Über den TeamProjectPickerMode wird genau ein TeamProject für die Auswahl zugelassen.

var teamProjectPicker 
    = new TeamProjectPicker(TeamProjectPickerMode.SingleProject, false);
teamProjectPicker.ShowDialog();

var teamProjectCollection = teamProjectPicker.SelectedTeamProjectCollection;
var projectInfo = teamProjectPicker.SelectedProjects.FirstOrDefault();

3. WorkItemStore

Über den WorkItemStore haben wir Zugriff auf alle Workitems und können diese auslesen oder neue anlegen.

var workItemStore = teamProjectCollection.GetService<WorkItemStore>();

4. Product Backlog Item anlegen

Jetzt wird ein neues Workitem angelegt. Im Konstruktor muss der Typ angegeben werden. Hier sollte vorher noch geprüft werden ob es diesen Typ in der WorkItemTypes Collection des Team Projektes überhaupt gibt. Danach werden die Felder Title, Description und Assigned to ausgefüllt. Das Assigned to wird dabei auf den angemeldeten User gesetzt. Das einzige Pflichtfeld ist bekanntlich Title. (sofern man keine Anpassungen gemacht hat)

var teamProject = workItemStore.Projects[projectInfo.Name];

var workItemPBI = new WorkItem(teamProject.WorkItemTypes["Product Backlog Item"])
{
    Title = "Product Backlog Item Demo",
    Description = "Description"
};

workItemPBI.Fields["Assigned to"].Value
    = teamProjectCollection.AuthorizedIdentity.DisplayName;

5. Test Case anlegen und speichern

Analog dazu wird ein Testcase erzeugt und anschließend gespeichert. Durch das Speichern wird die Property Id am Workitem Objekt gefüllt.

var workItemTestCase = new WorkItem(teamProject.WorkItemTypes["Test Case"])
{
    Title = "Test Case Demo",
};

workItemTestCase.Fields["Assigned to"].Value
    = teamProjectCollection.AuthorizedIdentity.DisplayName;

workItemTestCase.Save();

6. Product Backlog Item mit Test Case verlinken und speichern

Es wird eine Verlinkung “Tested By / Tests” zwischen Product Backlog Item und Test Case erzeugt. Dazu wird die Id von dem vorher gespeicherten Test Case benötigt. Anschließend wird auch das Product Backlog Item gespeichert.

var linkTypeEnd = workItemStore.WorkItemLinkTypes.LinkTypeEnds["Tested By"];
workItemPBI.WorkItemLinks.Add(new WorkItemLink(linkTypeEnd, workItemTestCase.Id));
workItemPBI.Save();

7. Ergebnis

Mit einer Workitem Query sind die beiden neuen Workitems und deren Verlinkung sichtbar.

tfsworkitemapi

Möchte man mehrere Workitems auf einmal speichern kann man auch den BatchSave verwenden.

workItemStore.BatchSave(new[] { workItemPBI, workItemTestCase });

Download Sample