Dostosowywanie hostowanego procesu XML

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 usług Azure DevOps Services przy użyciu 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 usługach Azure DevOps Services. Niektóre bloki konstrukcyjne aktualizują istniejące projekty, a inne dotyczą tylko nowych projektów. Aby uzyskać pełną listę bloków konstrukcyjnych, zobacz poniższą tabelę.

Używane podczas importowania/aktualizowania procesu

Używany podczas tworzenia nowego projektu

Zastępowane przez wartości domyślne systemu

Ignorowane

Śledzenie elementów roboczych

Wits

Kategorie

Konfiguracja procesu

Obszary i iteracje

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)

Istnieją różnice między obsługą usług Azure DevOps Services i lokalnym serwerem Team Foundation Server. Podsumowanie tych różnic można znaleźć w temacie 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 wprowadzonymi w szablonach do importowania.

Proces otwierania ustawień>

Tworzenie i dostosowywanie procesów w ustawieniach> organizacji oraz zarządzanie nimi.

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

   

2. Następnie wybierz pozycję Proces.

   

   Ważne

   Jeśli nie widzisz ustawienia 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.

   

   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ń główne i pomocnicze numery. 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:

• Dodawanie, usuwanie lub modyfikowanie funkcji WIT.
• Dodaj lub zmodyfikuj pole.
• Dodaj maksymalnie pięć list prac portfela.
• Dodaj kategorie , które będą używane w konfiguracji procesu.
• Modyfikowanie konfiguracji procesu.
• Dodaj listy globalne.

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.

• Dostosowywanie hostowanego procesu XML
  • Jak dostosować proces
    • Eksportowanie i importowanie procesu
  • Obsługiwane dostosowania
  • Ograniczenia
    • Szablon procesu
    • Konfiguracja procesu
    • Kategorie
    • Typy elementów roboczych
    • Pola elementów roboczych
      • Ograniczenia limitu
      • Wymagane pola
      • Ograniczenia reguł
      • Spójne nazwy i atrybuty
      • Pola tożsamości
        • Dodawanie pola tożsamości niestandardowej
        • Ograniczenia reguły dotyczące pól tożsamości
        • Prawidłowy przykład
        • Niepoprawny przykład
    • Przepływ pracy
    • Listy globalne
    • Układ formularza
  • Powiązane artykuły

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ą 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 kończy się niepowodzeniem.

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ą listę prac portfela nadrzędnego dla każdej podrzędnej listy prac portfela podrzędnego
• Zawiera wymagane mapowania stanu do metastanu 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 artykule Kategorie odwołania do elementu XML. 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 ramach jednego pola WIT i 512 we wszystkich WIT.
• Przyjazna nazwa i wymagany atrybut refname przypisany do funkcji WIT są unikatowe w zestawie plików definicji funkcji WIT.
• Wymagana wartość atrybutu refname nie zawiera niedozwolonych znaków ani nie korzysta z niedozwolonego systemu przestrzeni nazw.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 FIELD. Ponadto musi spełniać następujące warunki:

• Przyjazna nazwa i wymagany atrybut refname przypisany do funkcji WIT są unikatowe w zestawie plików definicji funkcji WIT.
• Wymagana wartość atrybutu refname nie zawiera niedozwolonych znaków ani nie korzysta z niedozwolonego systemu przestrzeni nazw.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ł.

Pola wymagane

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

• Dla wszystkich sieci WITs w kategorii definiującej listę prac konfiguracji procesu określ pola używane dla atrybutów i wartości type=Team oraz type=Order.
• W przypadku wszystkich sieci WIT w kategorii, która definiuje regularną listę prac lub listę prac portfela, określ pole używane dla programu type=Effort.
• Dla wszystkich sieci WITs w kategorii definiujących element TaskBacklog określ:
  • Pole używane dla type=RemainingWorkelementu .
  • Pole używane dla type=Activityelementu .
  • Reguła ALLOWEDVALUES dla pola używanego dla type=Activityelementu .

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 FIELD nie mogą zawierać elementów reguły podrzędnej CANNOTLOSEVALUE, NOTSAMEAS, MATCH i PROHIBITEDVALUES.
• Z wyjątkiem następujących pól definicje FIELD 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 WYMAGANE, DOMYŚLNE, 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 definicji POLA .

• SUGEROWANE WARTOŚCI
• 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 zaimportowanie procesu upewnij się, że grupa została utworzona w projektach, które są aktualizowane przez proces.

Niepoprawny 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 zamapowane na kategorię stanu "InProgress" i stany przepływu pracy zamapowane na kategorię stanu "Ukończono".

Opis kategorii stanu i mapowań można znaleźć w temacie Stany i kategorie 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ę znajduje się co najwyżej 1024 elementy.
• W sumie można zdefiniować około 10 000 elementów we wszystkich listach globalnych określonych we wszystkich sieciach sieciowych.

Układ formularza

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

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

Powiązane artykuły

• Importowanie i eksportowanie hostowanego procesu XML
• Reguły i ocena reguł
• Zmienianie projektu z hostowanego kodu XML na dziedziczony proces
• Klonowanie hostowanego procesu XML do procesu dziedziczenia
• Obsługiwane operacje podczas przechodzenia z hostowanego procesu XML do procesu dziedziczonego