Hinzufügen von Integrationsfeldern in Arbeitsaufgabentypen

Aktualisiert: November 2007

Das Arbeitsaufgabenverfolgung in Team Foundation-System ist in anderen Komponenten von Team Foundation Server und Visual Studio Team System integriert. Um optimalen Nutzen aus der Integration von Komponenten zu ziehen, verwenden Sie bestimmte Felder und Aktionen in Arbeitsaufgabentypen. Unter diesem Thema wird beschrieben, wie Sie diese Pflichtfelder und Aktionen in den folgenden Abschnitten verwenden:

  • Integration mit Team Build

  • Integration mit Visual Studio-Testtools

  • Integration mit der Team Foundation-Quellcodeverwaltung

Integration mit Team Foundation Build

Team Foundation Build ist das automatisierte Buildsystem von Team Foundation Server. Der Buildprozess kann mithilfe von Team Foundation Build konfiguriert werden. Team Foundation Build ist in der Lage, Arbeitsaufgaben zu generieren, wenn ein Build fehlschlägt, und Arbeitsaufgaben, die in einem bestimmten Build aufgelöst wurden, Buildinformationen hinzuzufügen. Dazu sind in Team Foundation Build die folgenden beiden Felder erforderlich: Found In und Integration Build

Hinzufügen des Felds Found in

Wenn ein Build fehlschlägt, erstellt Team Foundation Build eine neue Arbeitsaufgabe und legt das Feld Found In auf die Buildnummer des Builds fest, durch das der aktuelle Fehler verursacht wurde. Das Feld Found In muss in dem Arbeitsaufgabentyp vorhanden sein, der beim Fehlschlagen eines Builds von Team Foundation Build erstellt werden soll. Wenn das Feld Found In fehlt, wird von Team Foundation Build keine Arbeitsaufgabe für das fehlgeschlagene Build erstellt, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

In der folgenden Tabelle sind die Namen und die Werte der Attribute des Felds Found In zusammengefasst.

Attributname

Attributwert

RefName

Microsoft.VSTS.Build.FoundIn

Name

Kann auf einen beliebigen Wert festgelegt werden, da die Integration nicht auf Grundlage von Feldnamen, sondern von Feldverweisnamen funktioniert.

Type

Zeichenfolge

Beispiel für das Feld Found in

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
</FIELD>

Hinzufügen des Felds Integration Build

Team Foundation Build identifiziert mit den einzelnen Builds aufgelöste Arbeitsaufgaben und aktualisiert diese Arbeitsaufgaben dann mit der Nummer des Builds, in dem sie aufgelöst wurden. Die Buildnummer wird im Feld Integration Build festgelegt. Wenn das Feld Integration Build fehlt, wird von Team Foundation Build keine Buildnummer in den Arbeitsaufgaben gespeichert, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

In der folgenden Tabelle sind die Namen und die Werte der Attribute des Felds Integration Build zusammengefasst.

Attributname

Attributwert

RefName

Microsoft.VSTS.Build.IntegrationBuild

Name

Kann auf einen beliebigen Wert festgelegt werden, da die Integration nicht auf Grundlage von Feldnamen, sondern von Feldverweisnamen funktioniert.

Type

Zeichenfolge

Beispiel für das Feld Integration Build

<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
</FIELD>

Integration mit Visual Studio-Testtools

Einige Editionen von Visual Studio umfassen Testtools, die in die Entwicklungsumgebung integriert sind. Eines der in den Testtools verfügbaren Features ist die Fähigkeit, neue Arbeitsaufgaben zu erstellen, wenn ein Test fehlschlägt. Dazu klicken Sie im Fenster Testergebnisse mit der rechten Maustaste auf das Testergebnis, für das ein Fehler generiert werden soll, zeigen auf Arbeitsaufgabe erstellen und klicken dann auf den Typ der zu erstellenden Arbeitsaufgabe, z. B. Fehler. Weitere Informationen finden Sie unter Gewusst wie: Erstellen einer Arbeitsaufgabe auf der Grundlage eines Testergebnisses.

Wenn eine Arbeitsaufgabe auf diese Weise erstellt wurde, können drei Felder automatisch ausgefüllt werden, um Informationen zum fehlgeschlagenen Test zu liefern. Die drei Felder sind TestName, TestId und TestPath. Mit Test Edition werden für diese drei Felder spezifische Informationen zum fehlgeschlagenen Test angegeben. Wenn die Felder TestName, TestId und TestPath nicht in der Arbeitsaufgabe enthalten sind, werden die drei Felder nicht ausgefüllt und die übrigen Funktionen erwartungsgemäß ausgeführt.

In der folgenden Tabelle sind die Namen und Werte der Attribute dieser drei Felder zusammengefasst.

Attributname

Attributwert

RefName

Microsoft.VSTS.Test.TestName, Microsoft.VSTS.Test.TestId, Microsoft.VSTS.Test.TestPath

Name

Kann auf einen beliebigen Wert festgelegt werden, da die Integration nicht auf Grundlage von Feldnamen, sondern von Feldverweisnamen funktioniert.

Type

Zeichenfolge

Beispiel für die Felder TestName, TestId und TestPath

<FIELD name="Test Name" refname="Microsoft.VSTS.Test.TestName" type="String" reportable="detail">
    <HELPTEXT>The name of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Id" refname="Microsoft.VSTS.Test.TestId" type="String" reportable="detail">
    <HELPTEXT>The Id of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Path" refname="Microsoft.VSTS.Test.TestPath" type="String" reportable="detail">
    <HELPTEXT>The full pathname of the test that found this bug</HELPTEXT>

Integration mit der Team Foundation-Quellcodeverwaltung

Durch eines der in der Team Foundation-Versionskontrolle enthaltenen Features können Arbeitsaufgaben bei der Überprüfung im Code zugeordnet oder aufgelöst werden. Wenn bei einer bestimmten Codeänderung beispielsweise eine spezifische Arbeitsaufgabe bearbeitet wurde, können Sie diese Zuordnung innerhalb des Eincheckfensters der Quellcodeverwaltung festlegen, nachdem die Codebearbeitung abgeschlossen wurde.

Damit Arbeitsaufgaben von der Team Foundation-Versionskontrolle aufgelöst werden können, müssen die Arbeitsaufgaben eine besondere Aktion enthalten. Anschließend wird die Arbeitsaufgabenverfolgung vom Quellcodeverwaltungssystem abgefragt, um festzustellen, ob diese Aktion von der Arbeitsaufgabe unterstützt wird. Falls die Aktion unterstützt wird, werden zusätzlich der Quell- und Zielzustand des Übergangs abgefragt. Wenn die Aktion gefunden wird, kann die Arbeitsaufgabe entsprechend dem festgelegten Übergang vom Quellcodeverwaltungssystem bei der Überprüfung im Code umgewandelt werden.

Hinweis:

Bei Verwendung der Checkin-Aktion müssen die geeigneten Quell- und Zielzustände festgelegt werden, um die gewünschten Übergänge des Zustands widerzuspiegeln.

Weitere Informationen zu Aktionen finden Sie unter Zuordnen einer Aktion zu einem Zustandsübergang und Einzelheiten zu Übergangsaktionen.

Beispiel für die CheckIn-Aktion

<TRANSITION from="Active" to="Resolved">
....
    <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
    </ACTIONS>
....  
</TRANSITION>

Siehe auch

Aufgaben

Gewusst wie: Erstellen einer Arbeitsaufgabe auf der Grundlage eines Testergebnisses

Konzepte

Zuordnen einer Aktion zu einem Zustandsübergang

Einzelheiten zu Übergangsaktionen

Weitere Ressourcen

Anpassen von Arbeitsaufgabentypen

Definieren des Workflows für Arbeitsaufgaben