Automatisieren von Feldzuweisungen auf Grundlage von Zustand, Übergang oder Grund

Arbeitsaufgaben können auf der Grundlage eines Ereignisses, das an einem anderen Ort in Visual Studio Application Lifecycle Management (ALM) auftritt, oder auf der Grundlage eines Ereignisses außerhalb von Visual Studio ALM automatisch in einen anderen Zustand übergehen. So kann beispielsweise der Übergang eines Fehlers in einen anderen Zustand auf der Grundlage der Ereignisse in einem Aufrufnachverfolgungstool automatisiert werden. Das Arbeitsaufgaben-Typmodell und die Arbeitsaufgabenverfolgungs-API wurden erweitert und unterstützen jetzt automatische Übergänge von Arbeitsaufgaben, die durch andere Systeme ausgelöst werden.

Wenn Sie über Code verfügen, durch den der Zustand einer Arbeitsaufgabe geändert wird, können Sie diesen Code generalisieren, indem Sie die Aktion mithilfe des ACTION-Elements dem entsprechenden Zustandsübergang zuordnen. Sie können den Wert der Aktion an die [WorkItem.GetNextState]-Methode übergeben, um den Zustand dieser Arbeitsaufgabe nach Abschluss der Aktion abzurufen. Diese Methode wird im Dialogfeld Einchecken der Versionskontrolle verwendet, um Fehler zu beheben und Aufgaben zu schließen, die dem Einchecken zugeordnet sind.

ACTION ist ein optionales untergeordnetes Element von ACTIONS.

Tipp

Die Arbeitsaufgabenverfolgungs-API ist Teil des Visual Studio ALM-SDKs, wie auf der folgenden Seite auf der Microsoft-Website beschrieben: Erweitern von Team Foundation.

Beispielsweise verfügt ein Tool über eine Einstellung, durch die der Zustand einer Arbeitsaufgabe automatisch in "Aufgelöst" geändert wird, nachdem der Benutzer eine Änderung eingecheckt hat. Sie wissen als Integrationsanbieter jedoch nicht, welcher Zustand vom Autor des Arbeitsaufgabentyps als "Gelöst" deklariert wurde. Der Autor meint möglicherweise Gelöst, Geschlossen, Abgeschlossen, Testbereit, In Build einschließen usw. Sie können beispielsweise verlangen, dass alle Autoren von Arbeitsaufgabentypen einen Zustand mit der expliziten Bezeichnung "Gelöst" verwenden.

Diese Lösung ist jedoch zu restriktiv. Sie ist auch aus Gründen der Internationalisierung ungeeignet, da hierdurch die Lokalisierung von Zustandsbezeichnungen verhindert würde. Systemintegratoren können stattdessen eine Aktion wie "Einchecken" oder "Vollständig" deklarieren, durch die automatische Übergänge für Arbeitsaufgaben ausgelöst werden. Der Autor des Arbeitsaufgabentyps deklariert diese Aktion dann beim entsprechenden Übergang.

In diesem Thema

• Syntax für das ACTION-Element

• Erforderliche Schritte zur Unterstützung der Automatisierung

• Zuordnen einer Aktion zu einem Zustandsübergang

• Einzelheiten zu Übergangsaktionen

• Überprüfung von Fehlern bei automatischen Übergängen

Syntax für das ACTION-Element

Für das ACTION-Element wird die folgende Syntax verwendet. Das Wertattribut dient zum Angeben des Namens der Aktion und ist erforderlich. Halten Sie sich bei Aktionen möglichst an die gleichen Namenskonventionen wie bei Feldverweisnamen. So wird der geeignete Übergang für Arbeitsaufgaben, die dem Einchecken zugeordnet sind, von Team Foundation-Versionskontrolle beispielsweise mithilfe von "Microsoft.VSTS.Actions.CheckIn" angegeben. Weitere Informationen finden Sie unter Benennungskonventionen für Arbeitsaufgabenverfolgungs-Objekte.

<ACTION value="NameOfAction" />

minOccurs="0"

maxOccurs="unbounded"

Erforderliche Schritte zur Unterstützung der Automatisierung

Um ein Tool in die Arbeitsaufgabenverfolgung zu integrieren, muss das Tool die folgenden Schritte ausführen:

1. Ermitteln, in welchen Zustand die Arbeitsaufgabe übergehen soll, wenn die Aktion ausgeführt wird

2. Festlegen der Arbeitsaufgabe auf den Zielzustand

   Die Arbeitsaufgabenverfolgungs-API stellt Methoden zum Ausführen dieser Schritte bereit. Die Arbeitsaufgabennachverfolgungs-API ist Bestandteil des Visual Studio ALM-SDKs. Weitere Informationen finden Sie auf der folgenden Seite der Microsoft-Website: Team Foundation Server SDK.

   Tipp

   Die Transaktionsaktion, durch die ein bestimmter Zustandsübergang ausgelöst wurde, wird nicht aufgezeichnet. Wenn Sie nachverfolgen möchten, durch welche Aktion ein Übergang verursacht wurde, können Sie ein zusätzliches Arbeitsaufgabenfeld zur Nachverfolgung angeben oder einen Wert für den Grund definieren.

Zurück nach oben

Zuordnen einer Aktion zu einem Zustandsübergang

Mithilfe von Aktionen für den Zustandsübergang können Sie den Übergang von Arbeitsaufgaben an verschiedenen Punkten im Workflow automatisieren. Beispielsweise muss ein Versionskontrollsystem von Team Foundation Server den automatischen Übergang von Arbeitsaufgaben beim Einchecken unterstützen. Zu diesem Zweck wurde die Aktion "microsoft.vsts.actions.checkin" definiert.

Der Autor eines Arbeitsaufgabentyps kann einen "defekten" Arbeitsaufgabentyp mit dem Zustand "Working" definieren und diese Arbeitsaufgabe verwenden, während ein Entwickler Änderungen vornimmt. Der Autor des Arbeitsaufgabentyps kann einen weiteren Zustand mit der Bezeichnung "Ready To Build" definieren. Dieser Zustand weist darauf hin, dass der vom Defekt betroffene Code vom Entwickler für den nächtlichen Buildvorgang freigegeben wurde.

Der Autor kann den Zustand der Arbeitsaufgabe während eines Eincheckvorgangs automatisch von "Working" in "Ready To Build" ändern. Siehe dazu folgende Deklaration:

<TRANSITION from="Working" to="Ready To Build">
   <ACTIONS>
      <ACTION value="microsoft.vsts.actions.checkin"/>
   </ACTIONS>
</TRANSITION>

Zurück nach oben

Einzelheiten zu Übergangsaktionen

Mithilfe von Aktionen für den Zustandsübergang können Sie den Übergang von Arbeitsaufgaben an verschiedenen Punkten im Workflow automatisieren. Die folgenden Verwendungsdetails zu Übergangsaktionen sind für Sie möglicherweise relevant:

• Übergangsaktionen sind optional. Wenn der aktuelle Zustand der Arbeitsaufgabeninstanz über einen Aktionseintrag für die angegebene Aktion verfügt, wird der "Ziel"-Zustand zurückgegeben. Andernfalls ist der Rückgabewert NULL. NULL-Rückgabewerte sollten von Integrationen ordnungsgemäß behandelt werden. Dies bedeutet:

  • Sie verursachen keinen Fehler.

  • Es werden eine Ablaufverfolgung oder ein Protokoll angegeben, denen zu entnehmen ist, dass bei der Integration kein automatischer Übergang stattgefunden hat, da eine erforderliche Aktion nicht gefunden wurde.

• Für jeden Arbeitsaufgabentyp müssen Aktionen für Quellzustands-/Aktionspaare eindeutig sein. Dies bedeutet, dass Autoren von Arbeitsaufgabentypen nicht mehrere Zielzustände für die gleiche Aktion festlegen können.

• Es werden jedoch mehrere Aktionen im gleichen Übergang unterstützt, um mehrere Integrationen von automatischen Übergängen zu ermöglichen (siehe folgendes Beispiel):

  <TRANSITION from="Working" to="Ready To Build">
     <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
        <ACTION value="ADatum.Actions.Complete"/>
     </ACTIONS>
  </TRANSITION>
  

• Aktionsnamen sind programmgesteuerte Namen, für die nur lateinische Buchstaben verwendet werden können.

• Bei Aktionsnamen sollte dieselbe Konvention für den Verweisnamespace wie bei Feldverweisnamen verwendet werden, um Namenskonflikte zwischen Anbietern und Kunden zu vermeiden. Diese Konvention wird jedoch nicht vom Tool durchgesetzt. Visual Studio ALM verwendet Microsoft.VSTS.Actions.<your action>.

Zurück nach oben

Überprüfung von Fehlern bei automatischen Übergängen

Für Integratoren stehen zwei Arten von automatischen Übergängen zur Verfügung. Die erste Art entspricht einem automatischen Übergang, der aufgrund einer Benutzeraktion auftritt. Die zweite Art entspricht einem automatischen Übergang, der durch eine unbeaufsichtigte Automatisierung auftritt, z. B. einen nächtlichen Buildvorgang.

• Automatische Übergänge durch Benutzeraktionen   Bei dieser Art von automatischem Übergang ist ein Benutzer involviert, der auf auftretende regelbezogene Probleme reagiert. Treffen Sie auch Vorkehrungen für den Fall, dass der Autor eines Arbeitsaufgabentyps ein Pflichtfeld hinzufügt, das von der Integration nicht erkannt wird. Zu diesem Zweck führen Sie den automatischen Übergang aus und überprüfen dann den Arbeitsaufgabentyp auf Regelverletzungen. Wenn Sie eine Regelverletzung finden, sollte der Benutzer anhand eines Formulars aufgefordert werden, die Verletzung(en) aufzulösen.

• Automatische Übergänge durch unbeaufsichtigte Automatisierung   Es muss davon ausgegangen werden, dass kein Benutzer zum Beheben dieser Probleme verfügbar ist. In diesem Fall sollte die Integration ordnungsgemäß abgebrochen werden. Im Fehlerprotokoll sollte angegeben werden, dass der automatische Übergang versucht wurde, und es sollte ein Grund für den Fehler angeführt werden.

Wenn Sie eine Art des automatischen Übergangs definieren, sollten Sie beachten, dass jede Arbeitsaufgabe am Ende des Übergangs einen gültigen Zustand erreicht, ohne dass dazu ein Benutzereingriff erforderlich wäre. Wenn für alle Felder Standardwerte oder kopierte Werte angegeben werden, sind sämtliche Regeln erfüllt, die für den Zustand definiert werden, für den der Übergang ausgeführt wird. Wenn ein Feld nach dem Übergang ungültig wird, ist der Zustandsübergang nicht erfolgreich.

Um zu verhindern, dass Felder ungültig werden, gehen Sie wie folgt vor:

• Definieren Sie einen DEFAULTREASON-Wert für den Zustandsübergang.

• Geben Sie für Felder, die nach dem Zustandsübergang zu Pflichtfeldern werden, mithilfe des Regelelements DEFAULT oder COPY einen Wert für das Feld an.

Beispiel: Sie haben die Übergangsaktion "Einchecken" erstellt, durch die der Zustand einer Arbeitsaufgabe von "In Bearbeitung" in "Bereit für Build" übergeht. Die Regeln der Arbeitsaufgabe für "Bereit für Build" erfordern, dass ein Wert für das Feld "Gelöst von" festgelegt wird. Also definieren Sie im Abschnitt TRANSITION ein DEFAULT- oder COPY-Regelelement für "ResolvedBy". Darüber hinaus definieren Sie einen DEFAULTREASON-Wert, um sicherzustellen, dass das Pflichtfeld ohne Benutzereingriff festgelegt werden kann.

Zurück nach oben

Siehe auch

Konzepte

Zeitpunkt und Ort für die Anwendung einer Feldregel

Associating a State Transition with an Action

Änderungsprotokoll

Datum	Versionsgeschichte	Grund
Januar 2011	Umgeschrieben, um Themen rund um die Verwendung des ACTION-Elements zur Automatisierung einer Feldzuweisung zusammenzufassen.	Informationsergänzung.