Udostępnij za pośrednictwem

Dostosowywanie hostowanego procesu XML

  • Artykuł

Usługa Azure DevOps Services

Usługi Azure DevOps Services obsługują dodawanie i aktualizowanie procesów za pośrednictwem środowiska administracyjnego, które jest procesem importowania opartym na Internecie. Po dodaniu procesu możesz utworzyć co najmniej jeden projekt. Proces można zaktualizować w dowolnym momencie, importując go ponownie. Zmiany wprowadzone w szablonie procesu są następnie stosowane do wszystkich projektów używających tego procesu.

Ważne

Za pomocą modelu przetwarzania hostowanego kodu XML można dostosować śledzenie pracy, aktualizując wybrane pliki definicji XML szablonu procesu. Ta funkcja jest dostępna tylko wtedy, gdy dane są migrowane do Azure DevOps Services za pomocą usługi importu bazy danych serwera Team Foundation Server.

Aby dowiedzieć się więcej na temat dostosowywania i modeli procesów, zobacz Dostosowywanie śledzenia pracy.

Proces to plik zip zawierający zestaw wzajemnie zależnych plików. Te pliki definiują bloki konstrukcyjne systemu śledzenia elementów roboczych i innych podsystemów w Azure DevOps Services. Niektóre bloki konstrukcyjne aktualizują istniejące projekty, a inne mają zastosowanie tylko do nowych projektów. Aby uzyskać pełną listę bloków konstrukcyjnych, zobacz poniższą tabelę.

Używane podczas importowania/aktualizowania procesu

Używane podczas tworzenia nowego projektu

Zamieniono na wartości domyślne systemu

Ignorowane

Śledzenie elementów roboczych

Wits

Kategorie

Konfiguracja procesu

Obszary i iteracji

Zarządzanie testami

Elementy robocze

Zapytania dotyczące elementów roboczych

Kompilacja

Lab Management

Kontrola wersji

Mapowania programu Microsoft Project

Raporty

Portal (produkty programu SharePoint)

Obsługiwane wtyczki i obiekty procesu na potrzeby importowania procesów

Istnieją różnice między tym, co obsługuje Azure DevOps Services, a czym obsługuje lokalny serwer Team Foundation Server. Aby zapoznać się z podsumowaniem tych różnic, zobacz Process template customizations differences (Różnice w dostosowywaniu szablonu procesu).

Jak dostosować proces

Podczas dostosowywania procesu rozpoczęcie od dobrze zdefiniowanego procesu jest łatwiejsze niż tworzenie nowego.

Jeśli zaktualizujesz istniejący proces używany z lokalnym serwerem Team Foundation Server, upewnij się, że jest on zgodny z ograniczeniami umieszczonymi w szablonach do zaimportowania.

Otwórz proces ustawień>

Tworzenie i dostosowywanie procesów przy użyciu ustawień>organizacji oraz zarządzanie nimi.

  1. Wybierz logo usługi Azure DevOps, aby otworzyć projekty. Następnie wybierz pozycję Ustawienia organizacji.

    Otwórz ustawienia organizacji

  2. Następnie wybierz pozycję Proces.

    Ustawienia organizacji, strona Proces

    Ważne

    Jeśli nie widzisz polecenia Proces, pracujesz z serwera TFS-2018 lub starszej wersji. Strona Proces nie jest obsługiwana. Należy użyć funkcji obsługiwanych dla lokalnego modelu procesów XML.

Eksportowanie i importowanie procesu

  1. Na karcie Procesy wybierz wielokropek (...), aby otworzyć menu skrótów dla hostowanego procesu XML, który chcesz wyeksportować. Można eksportować tylko hostowane procesy XML.

    Opcja menu Menu Eksportowanie hostowanego procesu XML na stronie > Przetwarzania

    Zapisz plik zip i wyodrębnij z niego wszystkie pliki.

  2. Zmień nazwę procesu w pliku ProcessTemplate.xml znajdującym się w katalogu głównym.

    Nadaj procesowi nazwę , aby odróżnić go od istniejących.

    <name>MyCompany Agile Process </name>

    Zmień typ wersji i zmień numery główne i pomocnicze. Podaj unikatowy identyfikator GUID dla typu, jak w tym przykładzie:

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

  3. Zastosuj obsługiwane dostosowania.

  4. Utwórz plik zip wszystkich plików i folderów w katalogu głównym.

  5. Zaimportuj plik zip procesu niestandardowego.

Obsługiwane dostosowania

Do procesu można zastosować następujące dostosowania:

W poniższej sekcji wymieniono ograniczenia nakładane przez system.

Ograniczenia

Do usług Azure DevOps Services można zaimportować maksymalnie 32 procesy. Procesy niestandardowe muszą być zgodne ze wszystkimi poniższymi podsumowaniami regułami. W przeciwnym razie podczas importowania mogą pojawić się komunikaty o błędach walidacji.

Szablon procesu

Plik ProcessTemplate.xml musi być zgodny ze składnią i regułami opisanymi w dokumentacji elementu XML ProcessTemplate. Ponadto musi spełniać następujące warunki:

  • Ogranicza liczbę zdefiniowanych sieci WITs do 64
  • Zawiera tylko jeden plik definicji Categories.xml
  • Zawiera tylko jeden plik definicji ProcessConfiguration.xml
  • Używa unikatowych przyjaznych nazw we wszystkich polach i definicjach funkcji WIT

Ponadto proces musi przejść następujące testy weryfikacyjne:

  • Nazwy procesów są unikatowe i zawierają co najwyżej 155 znaków Unicode.
    • Szablon o tej samej nazwie i identyfikatorze GUID wersji co istniejący proces zastępuje ten proces.
    • Szablon o tej samej nazwie, ale inny identyfikator GUID wersji generuje błąd.
    • Nazwy procesów nie mogą zawierać następujących znaków specjalnych: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Zobacz Ograniczenia nazewnictwa, aby uzyskać dodatkowe ograniczenia.
  • Foldery przetwarzania nie zawierają plików .exe. Nawet jeśli możesz zaimportować proces zawierający plik .exe, tworzenie projektu kończy się niepowodzeniem.
  • Całkowity rozmiar procesu wynosi co najwyżej 2 GB. W przeciwnym razie tworzenie projektu nie powiedzie się.

Konfiguracja procesu

Plik definicji ProcessConfiguration.xml musi być zgodny ze składnią i regułami opisanymi w dokumentacji elementu XML ProcessConfiguration. Ponadto musi spełniać następujące warunki:

  • Określa wszystkie elementy TypeFields
  • Jest ograniczona do pięciu list prac portfela
  • Zawiera tylko jedną nieparzystą listę prac portfela
  • Określa tylko jedną nadrzędną listę prac portfela dla każdej podrzędnej listy prac portfela
  • Zawiera wymagane mapowania stanu do metastate przepływu pracy i nie odwołuje się do nieobsługiwanych metadanych

Kategorie

Plik definicji Categories.xml musi być zgodny ze składnią i regułami opisanymi w temacie Odwołania do elementu XML kategorii. Ponadto musi spełniać następujące warunki:

  • Jest ograniczona do 32 kategorii
  • Definiuje wszystkie kategorie, do których odwołuje się plik ProcessConfiguration.xml

Typy elementów roboczych

Element WITD i jego elementy podrzędne muszą być zgodne ze składnią i regułami opisanymi w dokumentacji elementu XML funkcji WITD. Ponadto musi spełniać następujące warunki:

  • Istnieje co najwyżej 512 pól w obrębie jednego elementu WIT i 512 pól we wszystkich sieciach WIT.
  • Przyjazna nazwa i wymagany atrybut refname przypisany do elementu WIT są unikatowe w zestawie plików definicji funkcji WIT.
  • Wymagana wartość atrybutu refname nie zawiera niedozwolonych znaków ani nie używa niedozwolonych przestrzeni nazw System. Nazwa i firma Microsoft. Nazwa.
  • Nazwy odwołań zawierają co najmniej jeden kropka (.), a wszystkie inne znaki są literami bez spacji.
  • Element WITD zawiera element FORM , który definiuje element WebLayout zgodny ze składnią określoną w elementach WebLayout i Control.

Pola elementów roboczych

Element FIELDS i jego elementy podrzędne muszą być zgodne ze składnią i regułami opisanymi w dokumentacji elementu XML POLA. Ponadto musi spełniać następujące warunki:

  • Przyjazna nazwa i wymagany atrybut refname przypisany do elementu WIT są unikatowe w zestawie plików definicji funkcji WIT.
  • Wymagana wartość atrybutu refname nie zawiera niedozwolonych znaków ani nie używa niedozwolonych przestrzeni nazw System. Nazwa i firma Microsoft. Nazwa.
  • Nazwy odwołań zawierają co najmniej jeden kropka (.), a wszystkie inne znaki są literami bez spacji.

Element FIELD i jego elementy podrzędne mogą zawierać element GLOBALLIST .

Ograniczenia limitu

  • Element FIELDS jest ograniczony do 512 pól.
  • Typ elementu roboczego jest ograniczony do 64 pól nazwiska osoby. Pole person-name to jedno z atrybutem i wartością syncnamechanges=true.
  • Element ALLOWEDVALUES lub SUGGESTEDVALUES jest ograniczony do 512 elementów LISTITEM .
  • Pole jest ograniczone do 1024 reguł.

Wymagane pola

Następujące pola są określone w pliku ProcessConfiguration.xml:

  • Dla wszystkich sieci WIT w kategorii, która definiuje listę prac konfiguracji procesu, określ pola używane dla atrybutów i wartości type=Team oraz type=Order.
  • Dla wszystkich sieci WIT w kategorii, która definiuje zwykłą listę prac lub listę prac portfela, określ pole używane dla type=Effortprogramu .
  • Dla wszystkich sieci WIT w kategorii, która definiuje element TaskBacklog , określ:
    • Pole używane dla .type=RemainingWork
    • Pole używane dla .type=Activity
    • Reguła ALLOWEDVALUES dla pola używanego dla type=Activity.

Ograniczenia reguł

Oprócz standardowych ograniczeń reguł pól wymuszane są następujące ograniczenia:

  • Elementy reguły pola nie mogą określać atrybutów dla i nie .
  • Elementy POLA nie mogą zawierać elementów reguł podrzędnych CANNOTLOSEVALUE, NOTSAMEAS, MATCH i PROHIBITEDVALUES.
  • Z wyjątkiem następujących pól definicje PÓL dla systemu. Pola nazw nie mogą zawierać reguł pól.
    • System.Title może zawierać reguły WYMAGANE i DOMYŚLNE.
    • System.Description może zawierać reguły WYMAGANE i DOMYŚLNE.
    • Element System.AssignedTo może zawierać reguły REQUIRED, DEFAULT, ALLOWEXISTINGVALUE i VALIDUSER.
    • System.ChangedBy może zawierać reguły REQUIRED, DEFAULT, ALLOWEXISTINGVALUE i VALIDUSER.

Spójne nazwy i atrybuty

W ramach procesu lub kolekcji projektu nazwa, typ i inne atrybuty zdefiniowane przez element FIELD muszą być takie same we wszystkich definicjach funkcji WIT.

Pola tożsamości

Pola tożsamości odpowiadają polam używanym do przechowywania nazw kont, użytkowników lub grup. Następujące podstawowe pola systemowe są zakodowane jako pola tożsamości:

  • Przypisane do (System.AssignedTo)
  • Autoryzowane jako (System.AuthorizedAs)
  • Zmienione przez (System.ChangedBy)
  • Utworzone przez (System.CreatedBy)
  • Aktywowane przez (Microsoft.VSTS.Common.ActivatedBy)
  • Zamknięte przez (Microsoft.VSTS.Common.ClosedBy)
  • Rozwiązane przez (Microsoft.VSTS.Common.ResolvedBy)
Dodawanie pola tożsamości niestandardowej

Pole ciągu jest rozpoznawane jako pole tożsamości podczas określania atrybutu syncnamechanges jako True.

Ograniczenia reguły dotyczące pól tożsamości

W przypadku bieżącej wersji importu procesu nie należy określać żadnej z poniższych reguł w ramach definicji POLA .

  • SUGGESTEDVALUES
  • Reguły zawierające wartości niezidentyfikacyjne.
Prawidłowy przykład

Aby ograniczyć nazwy kont, które są prawidłowe w polu tożsamości, określ VALIDUSER element z atrybutem nazwy grupy.

    <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>

Przed zaimportowaniem procesu upewnij się, że grupa została utworzona w projektach, które proces aktualizuje.

Nieprawidłowy przykład

Poniższy przykład nie jest prawidłowy, ponieważ określa:

  • Element ALLOWEDVALUES .
  • Element DEFAULT , który określa ciąg value="Not Assigned"nonidentity .
    <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>

Przepływ pracy

Element przepływu pracy i jego elementy podrzędne muszą być zgodne ze składnią i regułami opisanymi w dokumentacji elementu XML przepływu pracy. Ponadto musi spełniać następujące warunki:

  • Ogranicza każdy element WIT do 16 stanów przepływu pracy
  • Definiuje wszystkie stany przepływu pracy, które są mapowane na metastany w pliku definicji ProcessConfiguration
  • Definiuje przejście między wszystkimi stanami przepływu pracy zamapowane na kategorię stanu "Proponowane" i stany przepływu pracy zamapowane na kategorię stanu "InProgress"
  • Definiuje przejście między wszystkimi stanami przepływu pracy mapowane na kategorię stanu "InProgress" i stany przepływu pracy mapowane na kategorię stanu "Ukończono".

Aby zapoznać się z opisem kategorii stanu i mapowań, zobacz Kategorie stanów i stanu przepływu pracy.

Listy globalne

W przypadku modelu procesów hostowanego kodu XML następujące limity są umieszczane w importowaniu listy globalnej:

  • Istnieje co najwyżej 64 listy globalne.
  • Na listę jest co najwyżej 512 elementów.
  • W sumie można zdefiniować około 10 000 elementów we wszystkich listach globalnych określonych we wszystkich sieciach sieci WIT.

Układ formularza

Element FORM i jego elementy podrzędne muszą być zgodne ze składnią i regułami opisanymi w dokumentacji elementu FORM XML.

Element kontrolki nie może określić kontrolki niestandardowej. Kontrolki niestandardowe nie są obsługiwane.