Anpassen eines gehosteten XML-Prozesses

Azure DevOps Services

Azure DevOps Services unterstützt das Hinzufügen und Aktualisieren von Prozessen über einen webbasierten Importprozess als Verwaltungsumgebung. Nachdem Sie einen Prozess hinzugefügt haben, können Sie ein oder mehrere Projekte daraus erstellen. Sie können den Prozess jederzeit aktualisieren, indem Sie ihn erneut importieren. Die an der Prozessvorlage vorgenommenen Änderungen werden auf alle Projekte angewendet, die den Prozess verwenden.

Wichtig

Mit dem gehosteten XML-Prozessmodell passen Sie die Arbeitsnachverfolgung an, indem Sie ausgewählte XML-Definitionsdateien einer Prozessvorlage aktualisieren. Dieses Feature ist nur verfügbar, wenn Daten mithilfe des Team Foundation Server-Datenbankimportdiensts zu Azure DevOps Services migriert werden.

Weitere Informationen zu Anpassungen und Prozessmodellen finden Sie unter Anpassen der Arbeitsnachverfolgung.

Ein Prozess ist eine ZIP-Datei, die einen Satz von voneinander abhängigen Dateien enthält. Diese Dateien definieren die Bausteine des Arbeitselementnachverfolgungssystems und anderer Subsysteme in Azure DevOps Services. Einige Bausteine aktualisieren vorhandene Projekte, während andere nur für neue Projekte gelten. Die vollständige Liste der Bausteine finden Sie in der folgenden Tabelle.

Wird beim Importieren/Aktualisieren eines Prozesses verwendet

Wird beim Erstellen eines neuen Projekts verwendet

Ersetzt durch Systemstandardeinstellungen

Wird ignoriert.

Arbeitselementnachverfolgung

Verstand

Kategorien

Prozesskonfiguration

Bereiche und Iterationen

Testverwaltung

Arbeitselemente

Arbeitsaufgabenabfragen

Entwickeln

Lab Management

Quellcodeverwaltung

Microsoft Project-Zuordnungen

Berichte

Portal (SharePoint-Produkte)

Unterstützte Prozess-Plug-Ins und -Objekte für den Prozessimport

Es gibt Unterschiede zwischen der Unterstützung Azure DevOps Services und der lokalen Team Foundation Server-Unterstützung. Eine Zusammenfassung dieser Unterschiede finden Sie unter Unterschiede bei der Anpassung von Prozessvorlagen.

Anpassen eines Prozesses

Wenn Sie einen Prozess anpassen, ist es einfacher, mit einem klar definierten Prozess zu beginnen, als einen neuen Prozess zu erstellen.

Wenn Sie einen vorhandenen Prozess aktualisieren, den Sie mit dem lokalen Team Foundation Server verwendet haben, stellen Sie sicher, dass er den Einschränkungen entspricht, die für Vorlagen für den Import gelten.

Prozess "Einstellungen öffnen">

Sie erstellen, verwalten und anpassen Prozesse über Den Prozess in den Organisationseinstellungen>.

  1. Wählen Sie das  Azure DevOps-Logo aus, um Projekte zu öffnen. Wählen Sie dann Organisationseinstellungen aus.

    Öffnen der Organisationseinstellungen

  2. Wählen Sie dann Prozess aus.

    Organisationseinstellungen, Seite

    Wichtig

    Wenn Prozess nicht angezeigt wird, arbeiten Sie mit TFS-2018 oder einer niedrigeren Version. Die Seite Prozess wird nicht unterstützt. Sie müssen die für das lokale XML-Prozessmodell unterstützten Features verwenden.

Exportieren und Importieren eines Prozesses

  1. Wählen Sie auf der Registerkarte Prozesse die Auslassungspunkte (...) aus, um das Kontextmenü für den gehosteten XML-Prozess zu öffnen, den Sie exportieren möchten. Sie können nur gehostete XML-Prozesse exportieren.

    Menüoption

    Speichern Sie die ZIP-Datei, und extrahieren Sie alle Dateien daraus.

  2. Benennen Sie den Prozess in der ProcessTemplate.xml Datei im Stammverzeichnis um.

    Benennen Sie den Prozess, um ihn von vorhandenen zu unterscheiden.

    <name>MyCompany Agile Process </name>

    Ändern Sie den Versionstyp, und ändern Sie die Haupt- und Nebenzahlen. Stellen Sie wie in diesem Beispiel eine eindeutige GUID für den Typ bereit:

    <version type="F50EFC58-C2FC-4C66-9814-E395D90778A3" major="1" minor="1"/>

  3. Wenden Sie unterstützte Anpassungen an.

  4. Erstellen Sie eine ZIP-Datei mit allen Dateien und Ordnern im Stammverzeichnis.

  5. Importieren Sie die ZIP-Datei Ihres benutzerdefinierten Prozesses.

Unterstützte Anpassungen

Sie können die folgenden Anpassungen auf Ihren Prozess anwenden:

Im folgenden Abschnitt werden die Vom System auferlegten Einschränkungen aufgeführt.

Beschränkungen

Sie können bis zu 32 Prozesse in Azure DevOps Services importieren. Ihre benutzerdefinierten Prozesse müssen allen folgenden zusammengefassten Regeln entsprechen. Andernfalls werden beim Import möglicherweise Validierungsfehler angezeigt.

Prozessvorlage

Ihre ProcessTemplate.xml-Datei muss der Syntax und den Regeln entsprechen, die unter ProcessTemplate XML-Elementreferenz beschrieben sind. Außerdem muss es die folgenden Bedingungen erfüllen:

  • Begrenzt die Anzahl der definierten WITs auf 64
  • Enthält nur eine Categories.xml Definitionsdatei
  • Enthält nur eine ProcessConfiguration.xml Definitionsdatei
  • Verwendet eindeutige Anzeigenamen für alle Felder und WIT-Definitionen

Außerdem muss Ihr Prozess die folgenden Überprüfungen bestehen:

  • Prozessnamen sind eindeutig und enthalten höchstens 155 Unicode-Zeichen.
    • Eine Vorlage mit demselben Namen und derselben Versions-GUID wie ein vorhandener Prozess überschreibt diesen Prozess.
    • Eine Vorlage mit demselben Namen, aber einer anderen Versions-GUID generiert einen Fehler.
    • Prozessnamen dürfen die folgenden Sonderzeichen nicht enthalten: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Weitere Einschränkungen finden Sie unter Benennungseinschränkungen .
  • Prozessordner enthalten keine .exe Dateien. Auch wenn Sie einen Prozess importieren können, der eine .exe Datei enthält, schlägt die Projekterstellung fehl.
  • Die Gesamtgröße des Prozesses beträgt höchstens 2 GB. Andernfalls schlägt die Projekterstellung fehl.

Prozesskonfiguration

Die ProcessConfiguration.xml-Definitionsdatei muss der Syntax und den Regeln entsprechen, die unter Xml-Elementreferenz für ProcessConfiguration beschrieben werden. Außerdem muss er die folgenden Bedingungen erfüllen:

  • Gibt alle TypeFields-Elemente an.
  • Ist auf fünf Portfoliobacklogs beschränkt
  • Enthält nur ein unparentes Portfoliobacklog.
  • Gibt nur einen übergeordneten Portfoliobacklog für jeden untergeordneten Portfoliobacklog an.
  • Enthält erforderliche Workflowstatus-zu-Metastate-Zuordnungen und verweist nicht auf nicht unterstützte Metastates.

Kategorien

Die Categories.xml-Definitionsdatei muss der Syntax und den Regeln entsprechen, die unter Xml-Elementreferenz für Kategorien beschrieben werden. Außerdem muss er die folgenden Bedingungen erfüllen:

  • Ist auf 32 Kategorien beschränkt.
  • Definiert alle Kategorien, auf die in der ProcessConfiguration.xml-Datei verwiesen wird.

Arbeitsaufgabentypen

Ein WITD-Element und seine untergeordneten Elemente müssen der syntax und den Regeln entsprechen, die unter WITD XML-Elementreferenz beschrieben werden. Außerdem muss er die folgenden Bedingungen erfüllen:

  • Es gibt höchstens 512 Felder innerhalb eines einzelnen WIT und 512 Felder in allen WITs.
  • Der Anzeigename und das erforderliche Refname-Attribut , das einem WIT zugewiesen sind, sind innerhalb der WIT-Definitionsdateien eindeutig.
  • Der erforderliche Attributwert für refname enthält keine unzulässigen Zeichen oder verwendet die nicht zulässigen Namespaces System. Name und Microsoft. Name.
  • Verweisnamen enthalten mindestens einen Punkt (.), und alle anderen Zeichen sind Buchstaben ohne Leerzeichen.
  • Das WITD-Element enthält ein FORM-Element , das ein WebLayout-Element definiert, das der in WebLayout und Control angegebenen Syntax entspricht.

Arbeitsaufgabenfelder

Ein FIELDS-Element und seine untergeordneten Elemente müssen der syntax und den Regeln entsprechen, die unter FIELD XML-Elementreferenz beschrieben werden. Außerdem muss er die folgenden Bedingungen erfüllen:

  • Der Anzeigename und das erforderliche Refname-Attribut , das einem WIT zugewiesen sind, sind innerhalb der WIT-Definitionsdateien eindeutig.
  • Der erforderliche Attributwert für refname enthält keine unzulässigen Zeichen oder verwendet die nicht zulässigen Namespaces System. Name und Microsoft. Name.
  • Verweisnamen enthalten mindestens einen Punkt (.), und alle anderen Zeichen sind Buchstaben ohne Leerzeichen.

Ein FIELD-Element und seine untergeordneten Elemente können ein GLOBALLIST-Element enthalten.

Einschränken von Einschränkungen

  • Ein FIELDS-Element ist auf 512 Felder beschränkt.
  • Ein Arbeitselementtyp ist auf 64 Personennamenfelder beschränkt. Ein Personenname-Feld ist ein Feld mit dem Attribut und dem Wert syncnamechanges=true.
  • Ein ALLOWEDVALUES- oder SUGGESTEDVALUES-Element ist auf 512 LISTITEM-Elemente beschränkt.
  • Ein Feld ist auf 1.024 Regeln beschränkt.

Pflichtfelder

Die folgenden Felder werden in der ProcessConfiguration.xml-Datei angegeben:

  • Geben Sie für alle WITs in einer Kategorie, die einen Prozesskonfigurationsbacklog definiert, die Felder an, die für die Attribute und Werte type=Team verwendet werden, und type=Order.
  • Geben Sie für alle WITs in einer Kategorie, die einen regulären Backlog oder Portfoliobacklog definiert, das feld an, das für type=Effortverwendet wird.
  • Geben Sie für alle WITs in der Kategorie, die das TaskBacklog-Element definiert, Folgendes an:
    • Das feld, das für type=RemainingWorkverwendet wird.
    • Das feld, das für type=Activityverwendet wird.
    • Die ALLOWEDVALUES-Regel für das Feld, das für type=Activityverwendet wird.

Regeleinschränkungen

Zusätzlich zu den standardmäßigen Feldregeleinschränkungen werden die folgenden Einschränkungen erzwungen:

  • Feldregelelemente können die Attribute für und nicht angeben.
  • FIELD-Elemente dürfen nicht die Elemente "CANNOTLOSEVALUE", "NOTSAMEAS", "MATCH" und "PROHIBITEDVALUES" enthalten.
  • Mit Ausnahme der folgenden Felder, FIELD-Definitionen für System. Namensfelder dürfen keine Feldregeln enthalten.
    • System.Title kann die Regeln REQUIRED und DEFAULT enthalten.
    • System.Description kann die Regeln REQUIRED und DEFAULT enthalten.
    • System.AssignedTo kann die Regeln REQUIRED, DEFAULT, ALLOWEXISTINGVALUE und VALIDUSER enthalten.
    • System.ChangedBy kann die Regeln REQUIRED, DEFAULT, ALLOWEXISTINGVALUE und VALIDUSER enthalten.

Konsistente Namen und Attribute

Innerhalb eines Prozesses oder einer Projektauflistung müssen Name, Typ und andere Attribute, die von einem FIELD-Element definiert werden, in allen WIT-Definitionen identisch sein.

Identitätsfelder

Identitätsfelder entsprechen Feldern, die verwendet werden, um Konto-, Benutzer- oder Gruppennamen zu enthalten. Die folgenden Kernsystemfelder sind hartcodiert als Identitätsfelder:

  • Zugewiesen an (System.AssignedTo)
  • Autorisiert als (System.AuthorizedAs)
  • Geändert von (System.ChangedBy)
  • Erstellt von (System.CreatedBy)
  • Aktiviert von (Microsoft.VSTS.Common.ActivatedBy)
  • Geschlossen von (Microsoft.VSTS.Common.ClosedBy)
  • Aufgelöst von (Microsoft.VSTS.Common.ResolvedBy)
Hinzufügen eines benutzerdefinierten Identitätsfelds

Ein Zeichenfolgenfeld wird als Identitätsfeld erkannt, wenn Sie das Attribut syncnamechanges als True angeben.

Regeleinschränkungen für Identitätsfelder

Geben Sie für die aktuelle Version des Prozessimports keine der folgenden Regeln in einer FIELD-Definition an.

  • SUGGESTEDVALUES
  • Regeln, die Nichtidentitätswerte enthalten.
Richtiges Beispiel

Um die in einem Identitätsfeld gültigen Kontonamen einzuschränken, geben Sie das VALIDUSER Element mit einem Gruppennamensattribut an.

    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <VALIDUSER group="[PROJECT]\Program Manager Group" />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Stellen Sie vor dem Importieren des Prozesses sicher, dass Sie die Gruppe in den Projekten erstellt haben, die der Prozess aktualisiert.

Falsches Beispiel

Das folgende Beispiel ist ungültig, da es angibt:

  • Ein ALLOWEDVALUES-Element.
  • Ein DEFAULT -Element, das die Nonidentity-Zeichenfolge value="Not Assigned"angibt.
    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <ALLOWEDVALUES>
          <LISTITEM value="[PROJECT]\Program Manager Group" />
          <LISTITEM value="Not Assigned" />
        </ALLOWEDVALUES>
        <DEFAULT from="value" value="Not Assigned" />
        <VALIDUSER />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Workflow

Ein WORKFLOW-Element und seine untergeordneten Elemente müssen der syntax und den Regeln entsprechen, die unter WORKFLOW XML-Elementreferenz beschrieben werden. Außerdem muss er die folgenden Bedingungen erfüllen:

  • Schränkt jeden WIT auf 16 Workflowzustände ein.
  • Definiert alle Workflowzustände, die Metastates in der ProcessConfiguration-Definitionsdatei zugeordnet sind.
  • Definiert einen Übergang zwischen allen Workflowzuständen, die der Statuskategorie "Vorgeschlagen" zugeordnet sind, und Workflowzuständen, die der Statuskategorie "InProgress" zugeordnet sind.
  • Definiert einen Übergang zwischen allen Workflowzuständen, die der Statuskategorie "InProgress" zugeordnet sind, und Workflowzuständen, die der Statuskategorie "Abgeschlossen" zugeordnet sind.

Eine Beschreibung der Zustandskategorie und Zuordnungen finden Sie unter Workflowstatus und Zustandskategorien.

Globale Listen

Für das Modell des gehosteten XML-Prozesses gelten die folgenden Einschränkungen für den Import von globalen Listen:

  • Es gibt höchstens 64 globale Listen.
  • Es gibt höchstens 512 Elemente pro Liste.
  • Insgesamt können ungefähr 10.000 Elemente aus allen globalen Listen definiert werden, die in allen WITs angegeben sind.

Formularlayout

Ein FORM-Element und seine untergeordneten Elemente müssen der syntax und den Regeln entsprechen, die in FORM XML-Elementreferenz beschrieben werden.

Ein Control-Element kann kein benutzerdefiniertes Steuerelement angeben. Benutzerdefinierte Steuerelemente werden nicht unterstützt.