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

Budowa

Zarządzanie Laboratorium

Kontrola wersji

Mapowania programu Microsoft Project

Raporty

Portal (produkty programu SharePoint)

Istnieją różnice między tym, co obsługują Azure DevOps Services i lokalny Team Foundation Server. Podsumowanie tych różnic można znaleźć w temacie Process template customizations differences (Różnice w dostosowywaniu szablonu procesu).

Warunki wstępne

Aby uzyskać wskazówki dotyczące dostosowywania usługi Azure Boards do konkretnych wymagań biznesowych, zobacz Informacje o konfigurowaniu i dostosowywaniu usługi Azure Boards.

Kategoria	Wymagania
uprawnienia	— Aby utworzyć, usunąć lub edytować proces: członek administratorów kolekcji projektów grupy lub określonych uprawnień na poziomie kolekcji Tworzenie procesu, Usuwanie procesu, Edytowanie procesulub Usuń pole z organizacji ustawione na Zezwalaj. Aby uzyskać więcej informacji, zobacz Ustaw uprawnienia i dostęp do śledzenia pracy oraz Dostosuj dziedziczony proces. — Aby zaktualizować tablice: administrator zespołu lub członek grupy Administratorzy projektów.
Access	— Nawet jeśli masz dostęp podstawowy lub niższy, nadal możesz zmienić proces, jeśli ktoś udzieli Ci uprawnień. — Aby zaktualizować i zmienić typ istniejących elementów roboczych, musisz być członkiem projektu.
model procesu projektu	— model procesu dziedziczenia projektów dla kolekcji projektów zawierającej projekt. — W przypadku migrowania danych do usługi Azure DevOps Services użyj usługi importowania bazy danych Team Foundation Server.
Wiedza	Znajomość modeli dostosowywania i przetwarzania .

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

Tworzysz, zarządzasz i dostosowujesz procesy w ustawieniach organizacji>Proces.

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 Proces, pracujesz w TFS-2018 lub wcześniejszej wersji. Strona Proces nie jest obsługiwana. Należy użyć funkcji obsługiwanych dla modelu procesu XML lokalnie zainstalowanego.

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ęć zaległości 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 streszczonymi 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 dotyczące reguł dla 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 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 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 GUID wersji co istniejący proces zastępuje istniejący proces.
  • Szablon o tej samej nazwie, ale o innym identyfikatorze GUID wersji generuje błąd.
  • Nazwy procesów nie mogą zawierać następujących znaków specjalnych: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
    Zobacz Ograniczenia nazewnictwa, aby poznać dodatkowe wymagania.
• 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 archiwów 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 odwołaniu 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 referencji elementu XML WITD. Ponadto musi spełniać następujące warunki:

• Istnieje co najwyżej 1024 pola w jednej WIT i 1024 pola we wszystkich WIT.
• Przyjazna nazwa i wymagany atrybut refname przypisane do WIT są unikatowe w zestawie plików definicji WIT.
• Wymagana wartość atrybutu refname nie zawiera niedozwolonych znaków ani nie używa niedozwolonych przestrzeni nazw System.Nazwa i Microsoft.Nazwa.
• Nazwy odwołań zawierają co najmniej jedną kropkę (.), 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 and 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 niedozwolonych przestrzeni nazw System.Nazwa i Microsoft.Nazwa.
• Nazwy odwołań zawierają co najmniej jedną kropkę (.), a wszystkie inne znaki to litery bez spacji.

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

Ograniczanie ograniczeń

• Element FIELDS jest ograniczony do 1024 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 elementów roboczych (WITs) w kategorii definiującej zaległość konfiguracji procesu określ pola używane dla atrybutów oraz wartości type=Team i type=Order.
• W przypadku wszystkich typów elementów roboczych w kategorii, która definiuje regularną listę prac lub listę prac portfela, określ pole używane dla type=Effort.
• Dla wszystkich WITs w kategorii definiującej element TaskBacklog określ:
  • Pole stosowane dla type=RemainingWork.
  • Pole używane dla type=Activity.
  • Reguła ALLOWEDVALUES dla pola używanego 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 for i not.
• 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 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)

Dodaj pole tożsamości niestandardowej

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

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

W 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 element VALIDUSER 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 nieidentyczności value="Not Assigned".

    <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 WORKFLOW i jego elementy podrzędne muszą być zgodne ze składnią i regułami opisanymi w WORKFLOW XML element reference. Ponadto musi spełniać następujące warunki:

• Ogranicza każdy element WIT do 16 stanów przepływu pracy
• Definiuje wszystkie stany workflow, które są mapowane na metastany w definicji pliku ProcessConfiguration.
• Definiuje przejście między wszystkimi etapami pracy przypisanymi do kategorii stanu "Proponowane" a etapami pracy przypisanymi do kategorii stanu "W trakcie realizacji"
• Definiuje przejście między wszystkimi stanami przepływu pracy sprowadzonymi do kategorii stanu „W trakcie” i stanami przepływu pracy sprowadzonymi do kategorii stanu „Ukończono”.

Aby uzyskać opis kategorii stanu i mapowań, zobacz Stany przepływu pracy i kategorie stanu.

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 liście znajduje się co najwyżej 1,024 elementy.
• W sumie można zdefiniować około 10 000 elementów we wszystkich listach globalnych określonych w całej WITs.

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
• Skopiuj hostowany proces XML do procesu dziedziczonego
• Obsługiwane operacje podczas przechodzenia z hostowanego procesu XML do procesu dziedziczonego