Felder, die die Integration in die Test-, Build- und Versionskontrolle unterstützen

Sie können Arbeitsaufgabentypen so anpassen, dass sie Informationen enthalten, die von automatisierten Prozessen generiert werden, indem Sie Felder hinzufügen, die sich in Team Foundation Build, Microsoft Test-Manager und Team Foundation-Versionskontrolle integrieren. 

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

Team Foundation Build ist das automatisierte Buildsystem von Team Foundation Server. Sie können den Buildprozess mithilfe von Team Foundation Build konfigurieren, und Team Foundation Build kann Arbeitsaufgaben generieren, wenn bei einem Build ein Fehler auftritt. Team Foundation Build kann auch Buildinformationen zu Arbeitsaufgaben hinzufügen, die in einem bestimmten Build aufgelöst wurden. Damit dies funktioniert, erfordert Team Foundation Build, dass die beiden folgenden Felder zur Definition des Arbeitsaufgabentyps hinzugefügt werden: Gefunden in und Integrationsbuild.

In den Standardprozessvorlagen, die Team Foundation Server bereitstellt, werden die Felder Gefunden in und In den Build integriert in den Typdefinitionen für Fehler angezeigt. Diese Felder ordnen Fehler den Builds zu, in denen sie gefunden oder korrigiert wurden. Sie können den folgenden Codeausschnitt verwenden, um diese Felder einer Definition des Arbeitsaufgabentyps hinzuzufügen.

<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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Wenn das Feld Gefunden in in der Definition des Arbeitsaufgabentyps vorhanden ist, erstellt Team Foundation Build bei einem Buildfehler eine Arbeitsaufgabe und legt das Feld Gefunden in auf die Buildnummer des Builds fest, bei dem der Fehler soeben aufgetreten ist. Wenn das Feld Gefunden in fehlt, erstellt Team Foundation Build keine Arbeitsaufgabe für den Build, bei dem der Fehler aufgetreten ist, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

Wenn das Feld Integrationsbuild in der Definition des Arbeitsaufgabentyps vorhanden ist, identifiziert Team Foundation Build mit den einzelnen Builds aufgelöste Arbeitsaufgaben und aktualisiert diese Arbeitsaufgaben dann mit der Nummer des Builds, in dem sie aufgelöst wurden, im Feld Integrationsbuild. Wenn das Feld Integrationsbuild fehlt, speichert Team Foundation Build die Buildnummer nicht in den Arbeitsaufgaben, und die übrigen Funktionen werden erwartungsgemäß ausgeführt.

Buildzuordnungen zu Changesets und Arbeitsaufgaben

Ein auf der Standardbuildvorlage basierender Standardbuild ordnet Changesets und Arbeitsaufgaben zu Builds zu. Hierzu wird zunächst die Bezeichnung für den vorherigen erfolgreichen Build für die Builddefinition des angegebenen Builds abgerufen und dann ermittelt, welche Changesets im aktuellen Build enthalten sind, die nicht Teil des vorherigen Builds waren. Einigen oder allen Changesets können Arbeitsaufgaben zugeordnet sein; diese Arbeitsaufgaben werden dem Build zugeordnet. Dies erfolgt im Rahmen der AssociateChangesetsAndWorkItems-Aktivität.

Builds und automatische Auffüllung von globalen Listen

Wenn Sie zum ersten Mal einen Build für ein Teamprojekt mit Team Foundation Build in eine Warteschlange stellen, fügt TFS automatisch eine globale Liste mit der Bezeichnung "Build - <Teamprojektname>" hinzu. Bei jeder Ausführung eines Builds wird dieser globalen Liste ein LISTITEM mit dem Namen des Builds hinzugefügt.

Indem Sie der FIELD-Definition ein GLOBALLIST-Element hinzufügen, können Sie ein Dropdownmenü mit Builds bereitstellen, aus denen die Benutzer wählen können. Beispiel:

<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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

Felder, die mit Microsoft Test Manager integriert werden können

Mit Test Manager können Sie die Erstellung eines Fehlers oder eines anderen Arbeitsaufgabentyps automatisieren, wenn bei einem Test ein Fehler auftritt. Weitere Informationen finden Sie unter Senden von Fehlern in Microsoft Test Manager.

Wenn eine Arbeitsaufgabe auf diese Weise erstellt wurde, werden Informationen zum System und den Schritten zum Reproduzieren des Fehlers in den Feldern Systeminfo und Reproduktionsschritte erfasst.

Sie können diese Felder zu Arbeitsaufgabentypen hinzufügen, die Sie zum Nachverfolgen von Fehlern mit dem folgenden Codeausschnitt erstellen.

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Weitere Informationen zu zusätzlichen Feldern verwendet durch Test Manager, finden Sie unter Feldverweis für Build- und Testintegration.

Felder, die in die 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.

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 Automatisieren von Feldzuweisungen auf Grundlage von Zustand, Übergang oder Grund.

Beispiel für die CheckIn-Aktion

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

Fragen und Antworten

F: Welche anderen Felder sind Builds und Test Manager zugeordnet?

A: Lesen Sie Feldverweis für Build- und Testintegration für zusätzliche Felder,

Siehe auch

Aufgaben

Welche Entwicklung erfolgte ab einem vorherigen Build?

Weitere Ressourcen

Definieren von Arbeitsaufgabenfeldern