Hinzufügen von Integrationsfeldern in Arbeitsaufgabentypen

Artikel
07/20/2011

Sie können Typen von Arbeitsaufgaben so anpassen, dass sie Informationen enthalten, die von automatisierten Prozessen generiert werden. Fügen Sie dazu Felder hinzu, die in Team Foundation Build, Microsoft Test Manager und Team Foundation-Versionskontrolle integriert sind.

In diesem Thema

Felder, die mit Team Build integriert werden können
Felder, die mit Visual Studio-Testtools integriert werden können
Felder, die mit der Team Foundation-Quellcodeverwaltung integriert werden können

Felder, die mit Team Foundation Build integriert werden können

Team Foundation Build ist das automatisierte Buildsystem von Team Foundation Server. Sie können den Buildprozess mit Team Foundation Build konfigurieren. 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 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.
Typ	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.
Typ	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>

Felder, die mit Visual Studio-Testtools integriert werden können

Einige Editionen von Visual Studio beinhalten Testtools, die in die Entwicklungsumgebung integriert sind. Eines der in den Testtools verfügbaren Funktionen ist die Fähigkeit, 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 SO WIRD'S GEMACHT: Erstellen einer Arbeitsaufgabe aus einem Testergebnis.

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 Manager 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.
Typ	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>

Felder, die mit der Team Foundation-Versionskontrolle integriert werden können

Durch eines der in der Team Foundation-Versionskontrolle verfügbaren Funktionen können Arbeitsaufgaben beim Einchecken von Code zugeordnet oder aufgelöst werden. Wenn bei einer Codeänderung beispielsweise eine bestimmte 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 beim Einchecken des Codes umgewandelt werden.

Tipp

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 Associating a State Transition with an Action und Transition Action Details.

Beispiel für die CheckIn-Aktion

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

Siehe auch

Freigeben über