Der Team Foundation Server ist die zentrale Plattform für alle Artefakte von Software-Entwicklungsprojekten. Anforderungen, Code, Testfälle, Entwurfsdokumente – alles lässt sich versioniert und für die Zusammenarbeit in Teams zentral ablegen. Doch wie hängen diese verschiedenen Artefakte zusammen und wie kann das im Team Foundation Server abgebildet werden?

(more…)

In der MSDN sind zwei neue Webcasts des AIT TeamSystemPro Teams verfügbar. Nico Orschel stellt dabei den Team Foundation Server aus der IT-Pro Sichtweise dar.

(more…)

In den Standardprozessvorlagen von Visual Studio Team System sind die Felder “Remaining Work”, “Completed Work” und “Baseline Work” definiert. Diese werden auch in MS Project synchronisiert.:

Die Spalten “Actual Work” und “Remaining Work” in MS Project sind mit “Completed Work” und “Remaining Work” der Work Items im TFS verknüpft. Die Standardeinheit für die Berechnungen ist dabei “Stunde”. D.h., dass auch eine Umstellung der Ansicht in MS Project hin zu “Tagen” sich nicht auf die Synchronisation im Hintergrund auswirkt. Dafür ist etwas mehr nötig.

(more…)

Der TFS bietet ein Berechtigungskonzept, welches auch die Work Items einschließt. Für Work Items gelten zunächst einmal die Grenzen des Teamprojektes, in dem sie enthalten sind. Innerhalb eines Teamprojektes, lassen sich die Berechtigungen zum Anzeigen und Editieren von Work Items auf Area-Level festlegen. Areas bieten dabei folgende Rechtetabelle an:

Die Abbildung zeigt, die Rechte auf dem Area-Knoten „Specification“ eines Beispielprojektes. Diese sind für unseren Beispielnutzer entzogen. Versucht dieser Nutzer, auf diesem Knoten, Berechtigungen einzusehen oder zu editieren, bekommt er eine Fehlermeldung.

Man könnte meinen, dass das Recht “View this node” einschließt, dass der Knoten z.B. in einem Work Item Formular sichtbar bzw. versteckt bleibt. Doch ist dem nicht so. Areas und Iterations sind generell sichtbar, wenn man im TFS nicht die Metadaten nach Berechtigungen filtert (siehe Blog von Martin Woodward).

Die Reports hingegen kümmern sich nicht um Work Item Security. Alle Daten, die ein Report abfragt sind dem Nutzer, der den Report ansehen darf zugänglich (read-only). Das liegt daran, dass die Berichte als User ReportService o.ä. auf das Data-Warehouse zugreifen und das Rechtekonzept dort nicht so feingranular umgesetzt wird. Man muss sich also genau überlegen, wer auf welche Reports zugreifen darf.

Hier ein Beispiel für einen Work-Item-Bericht, der auch Work Items aus der “sicheren” Area (siehe oben) anzeigt.

Und das obwohl der Benutzer keine Berechtigung hat, dieses Work Item direkt mit dem TFS zu öffnen.

Das vorgestellte Konzept sollte in die Überlegungen zum Aufbau einer Teamprojektstruktur einfließen. Je nachdem, welche Sicherheit benötigt wird, muss man in mehrere Teamprojekte aufteilen und von einem einzelnen Teamprojekt absehen bzw. sich dafür entscheiden, mehr Informationen sichtbar zu machen.

Gerade für frühere Visual-SourceSafe-Benutzer ist das Labeling im TFS evtl. missverständlich. War doch ein Label im Visual-SourceSafe ein “benannter Zeitpunkt”, der auch in der Dateihistorie angezeigt wurde. Ganz anders und mächtiger im TFS. Doch mit großer Macht kommt große Verantwortung. Und für alle Verantwortlichen soll dieser Blogeintrag das Labeling im TFS verständlicher machen.

(more…)

In der Versionskontrolle des TFS lassen sich Berechtigungen auf einzelne Verzeichnisse und Dateien setzen. Wie man einen Überblick über die gesetzten Berechtigungen erhält, wurde bereits erläutert. Im folgenden soll es um die Einrichtung der Berechtigungen gehen.

(more…)

Die Versionsverwaltung (auch Quellcodeverwaltung genannt) des TFS bietet die Möglichkeit, Pending-Changes zentral zu verfolgen. Das bedeutet, dass alle Check-Outs oder Locks eines Benutzers zentral verfügbar sind - wohlgemerkt nicht die lokalen Änderungen, die noch nicht eingecheckt worden sind.

Die Möglichkeiten, diese Funktionalität des TFS für die Steuerung eines Projekts zu nutzen, sind dagegen eingeschränkt. Nicht nur der Überblick üder die Pending-Changes, sondern z.B. auch über die gesetzten Berechtigungen der Verzeichnisse und Dateien in der Versionsverwaltung sind nur schwer zu gewinnen.

Dieser Beitrag soll aufzeigen, wie die Versionsverwaltung durch den Einsatz von wenigen einfachen Berichten besser in den Griff zu bekommen ist…

(more…)

Wesentlich für das Projektmanagement ist die Statusverfolgung eines Projekts. Der TFS bietet zu diesem Zweck verschiedene anpassbare Berichte an. Aufgrund der Vielzahl von Filtern (in Form von Berichtsparametern) ist es oft mühselig, einen Bericht regelmäßig zu öffnen und immer wieder gleiche Werte einzugeben. Da kommt der Wunsch nach Standardwerten auf. Die Anpassung des Berichts selbst ist da nicht unbedingt die einfachste und beste Lösung. Das Ändern der Berichtsdefinition ist aufwändig und zudem zentral. Außerdem sind häufig Änderungen nötig, wenn z.B. anstelle von Iteration 1 nun Iteration 2 als Standardwert gelten soll. Doch es gibt eine einfachere Lösung, die im folgenden vorgestellt werden soll…

(more…)

Vor wenigen Tagen wurde die neue Version der Power Tools freigegeben. Daher kann die July 08 Edition auf der Webseite von Microsoft unter folgendem Links heruntergeladen werden: http://www.microsoft.com/downloads/details.aspx?FamilyID=00803636-1d16-4df1-8a3d-ef1ad4f4bbab&displaylang=en. Mit der neuen Version gibt es zwei neue Werkzeuge und ein neues Plugin für das Visual Studio, welche nachfolgend näher vorgestellt werden sollen.

(more…)

Bei der Evaluierung eines neuen Systems ist die Performanz ein wichtiges Kriterium, welches häufig ausschlaggebend für die Einführungsentscheidung ist. Aus welchen Perspektiven die Performanz des Team Foundation Servers ermittelt werden kann, soll in diesem Beitrag kurz zusammengefasst werden.

(more…)