Personalizzare un processo XML ospitato

  • Articolo

Azure DevOps Services

Azure DevOps Services supporta l'aggiunta e l'aggiornamento dei processi tramite un'esperienza amministrativa che rappresenta un processo di importazione basato sul Web. Dopo aver aggiunto un processo, è possibile creare uno o più progetti da esso. È possibile aggiornare il processo in qualsiasi momento importandolo di nuovo. Le modifiche apportate al modello di processo vengono quindi applicate a tutti i progetti che usano il processo stesso.

Importante

Con il modello di processo XML ospitato, è possibile personalizzare il rilevamento del lavoro aggiornando selezionare file di definizione XML di un modello di processo. Questa funzionalità è disponibile solo quando i dati vengono migrati in Azure DevOps Services tramite il servizio di importazione del database di Team Foundation Server.

Per altre informazioni sulla personalizzazione e sui modelli di elaborazione, vedere Personalizzare il rilevamento del lavoro.

Un processo è un file zip che contiene un set di file interdipendenti. Questi file definiscono i blocchi predefiniti del sistema di rilevamento elementi di lavoro e altri sottosistemi in Azure DevOps Services. Alcuni blocchi predefiniti aggiornano i progetti esistenti, mentre altri si applicano solo ai nuovi progetti. Per l'elenco completo dei blocchi predefiniti, vedere la tabella seguente.

Usato durante l'importazione o l'aggiornamento di un processo

Usato durante la creazione di un nuovo progetto

Sostituito dalle impostazioni predefinite del sistema

Ignorato

Verifica elementi di lavoro

Ingegno

Categorie

Process Configuration

Aree e iterazioni

Gestione test

Work Items

Query elemento di lavoro

Compilare

Lab Management

Controllo della versione

Mapping di progetto Microsoft

Report

Portale (Prodotti SharePoint)

Plug-in e oggetti del processo supportati per l'importazione del processo

Esistono differenze tra le Azure DevOps Services supportate e le funzionalità supportate da Team Foundation Server locale. Per un riepilogo di queste differenze, vedere Elaborare le differenze tra le personalizzazioni dei modelli.

Come personalizzare un processo

Quando si personalizza un processo, a partire da un processo ben definito è più semplice rispetto alla creazione di una nuova.

Se si aggiorna un processo esistente usato con Team Foundation Server locale, assicurarsi che sia conforme ai vincoli inseriti nei modelli per l'importazione.

Apri processo impostazioni>

È possibile creare, gestire e apportare personalizzazioni ai processi dal processo delle impostazioni>dell'organizzazione.

  1. Scegliere il logo Azure DevOps per aprire Progetti. Quindi scegliere Impostazioni organizzazione.

    Aprire le impostazioni dell'organizzazione

  2. Scegliere Quindi Processo.

    Impostazioni organizzazione, pagina Processo

    Importante

    Se non viene visualizzato Processo, si lavora da TFS-2018 o versione precedente. La pagina Processo non è supportata. È necessario usare le funzionalità supportate per il modello di processo XML locale.

Esportare e importare un processo

  1. Nella scheda Processi selezionare i puntini di sospensione (...) per aprire il menu di scelta rapida per il processo XML ospitato da esportare. È possibile esportare solo processi XML ospitati.

    Opzione di menu Esporta processo XML ospitato nella pagina > Elaborazione

    Salvare il file zip ed estrarre tutti i file da esso.

  2. Rinominare il processo all'interno del file ProcessTemplate.xml situato nella directory radice.

    Assegnare un nome al processo per distinguerlo da quelli esistenti.

    <name>MyCompany Agile Process </name>

    Modificare il tipo di versione e modificare i numeri principali e secondari. Specificare un GUID distinto per il tipo come in questo esempio:

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

  3. Applicare personalizzazioni supportate.

  4. Creare un file zip di tutti i file e le cartelle nella directory radice.

  5. Importare il file zip del processo personalizzato.

Personalizzazioni supportate

È possibile applicare le personalizzazioni seguenti al processo:

Nella sezione seguente sono elencate le limitazioni imposte dal sistema.

Restrizioni

È possibile importare fino a 32 processi in Azure DevOps Services. I processi personalizzati devono essere conformi a tutte le regole riepilogate seguenti. In caso contrario, potrebbero essere visualizzati messaggi di errore di convalida all'importazione.

Modello di processo

Il file ProcessTemplate.xml deve essere conforme alla sintassi e alle regole descritte in Riferimento all'elemento XML ProcessTemplate. Inoltre, deve soddisfare le condizioni seguenti:

  • Limita il numero di WIT definiti a 64
  • Contiene un solo file di definizione Categories.xml
  • Contiene un solo file di definizione ProcessConfiguration.xml
  • Usa nomi descrittivi univoci in tutti i campi e definizioni di WIT

Inoltre, il processo deve passare i controlli di convalida seguenti:

  • I nomi dei processi sono univoci e contengono al massimo 155 caratteri Unicode.
    • Un modello con lo stesso nome e GUID della versione di un processo esistente sovrascrive tale processo.
    • Un modello con lo stesso nome ma un GUID di versione diverso genera un errore.
    • I nomi dei processi non possono contenere i caratteri speciali seguenti: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Per altri vincoli, vedere Restrizioni di denominazione .
  • Le cartelle di processo non contengono file .exe. Anche se è possibile importare un processo contenente un file .exe, la creazione del progetto ha esito negativo.
  • Le dimensioni totali del processo sono al massimo 2 GB. In caso contrario, la creazione del progetto non riesce.

Configurazione del processo

Il file di definizione ProcessConfiguration.xml deve essere conforme alla sintassi e alle regole descritte in Riferimento all'elemento XML ProcessConfiguration. Inoltre, deve soddisfare le condizioni seguenti:

  • Specifica tutti gli elementi TypeFields
  • È limitato a cinque backlog portfolio
  • Contiene un solo backlog portfolio non analizzato
  • Specifica un solo backlog del portfolio padre per ogni backlog del portfolio subordinato
  • Contiene mapping di stato del flusso di lavoro necessari per metastate e non fa riferimento a metastate non supportati

Categorie

Il file di definizione Categories.xml deve essere conforme alla sintassi e alle regole descritte in Riferimenti agli elementi XML categories. Inoltre, deve soddisfare le condizioni seguenti:

  • È limitato a 32 categorie
  • Definisce tutte le categorie a cui si fa riferimento nel file ProcessConfiguration.xml

Tipi di elemento di lavoro

Un elemento WITD e i relativi elementi figlio devono essere conformi alla sintassi e alle regole descritte in Informazioni di riferimento sugli elementi XML WITD. Inoltre, deve soddisfare le condizioni seguenti:

  • Sono presenti al massimo 512 campi all'interno di un singolo WIT e 512 campi in tutte le wit.
  • Il nome descrittivo e l'attributo refname obbligatorio assegnati a un WIT sono univoci all'interno del set di file di definizione WIT.
  • Il valore dell'attributo refname obbligatorio non contiene caratteri non consentiti o usa gli spazi dei nomi non consentiti System. Nome e Microsoft. Nome.
  • I nomi di riferimento contengono almeno un punto (.) e tutti gli altri caratteri non contengono spazi.
  • L'elemento WITD contiene un elemento FORM che definisce un elemento WebLayout conforme alla sintassi specificata negli elementi WebLayout e Control.

Campi dell'elemento di lavoro

Un elemento FIELDS e i relativi elementi figlio devono essere conformi alla sintassi e alle regole descritte in Riferimento agli elementi FIELD XML. Inoltre, deve soddisfare le condizioni seguenti:

  • Il nome descrittivo e l'attributo refname obbligatorio assegnati a un WIT sono univoci all'interno del set di file di definizione WIT.
  • Il valore dell'attributo refname obbligatorio non contiene caratteri non consentiti o usa gli spazi dei nomi non consentiti System. Nome e Microsoft. Nome.
  • I nomi di riferimento contengono almeno un punto (.) e tutti gli altri caratteri non contengono spazi.

Un elemento FIELD e i relativi elementi figlio possono contenere un elemento GLOBALLIST .

Limitare le restrizioni

  • Un elemento FIELDS è limitato a 512 campi.
  • Un tipo di elemento di lavoro è limitato a 64 campi nome persona. Un campo person-name è uno con l'attributo e il valore syncnamechanges=true.
  • Un elemento ALLOWEDVALUES o SUGGESTEDVALUES è limitato a 512 elementi LISTITEM .
  • Un campo è limitato a 1.024 regole.

Required fields

I campi seguenti vengono specificati nel file ProcessConfiguration.xml:

  • Per tutte le connessioni WIT in una categoria che definisce un backlog di configurazione del processo, specificare i campi usati per gli attributi e i valori type=Team e type=Order.
  • Per tutte le connessioni WIT in una categoria che definisce un backlog o un backlog di portfolio regolare, specificare il campo usato per type=Effort.
  • Per tutte le connessioni WIT nella categoria che definisce l'elemento TaskBacklog , specificare:
    • Campo utilizzato per type=RemainingWork.
    • Campo utilizzato per type=Activity.
    • Regola ALLOWEDVALUES per il campo utilizzato per type=Activity.

Restrizioni delle regole

Oltre alle restrizioni standard per le regole di campo, vengono applicate le restrizioni seguenti:

  • Gli elementi della regola di campo non possono specificare gli attributi per e non .
  • Gli elementi FIELD non possono contenere gli elementi della regola figlio CANNOTLOSEVALUE, NOTSAMEAS, MATCH e PROHIBITEDVALUES.
  • Ad eccezione dei campi seguenti, le definizioni FIELD per System. I campi dei nomi non possono contenere regole di campo.
    • System.Title può contenere le regole REQUIRED e DEFAULT.
    • System.Description può contenere le regole REQUIRED e DEFAULT.
    • System.AssignedTo può contenere le regole REQUIRED, DEFAULT, ALLOWEXISTINGVALUE e VALIDUSER.
    • System.ChangedBy può contenere le regole REQUIRED, DEFAULT, ALLOWEXISTINGVALUE e VALIDUSER.

Nomi e attributi coerenti

All'interno di un processo o di una raccolta di progetti, nome, tipo e altri attributi definiti da un elemento FIELD devono essere uguali in tutte le definizioni di WIT.

campi di identità

I campi Identity corrispondono ai campi usati per contenere nomi di account, utente o gruppo. I campi di sistema principali seguenti sono hardcoded come campi identity:

  • Assegnato a (System.AssignedTo)
  • Autorizzato come (System.AuthorizedAs)
  • Modificato da (System.ChangedBy)
  • Creato da (System.CreatedBy)
  • Attivato da (Microsoft.VSTS.Common.ActivatedBy)
  • Chiuso da (Microsoft.VSTS.Common.ClosedBy)
  • Risolto da (Microsoft.VSTS.Common.ResolvedBy)
Aggiungere un campo di identità personalizzato

Un campo stringa viene riconosciuto come campo Identity quando si specifica l'attributo syncnamechanges come True.

Restrizioni delle regole nei campi di identità

Per la versione corrente dell'importazione del processo, non specificare alcuna delle regole seguenti all'interno di una definizione FIELD .

  • SUGGESTEDVALUES
  • Regole che contengono valori di non rientro.
Esempio corretto

Per limitare i nomi di account validi all'interno di un campo Identity, specificare l'elemento VALIDUSER con un attributo nome gruppo.

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

Prima di importare il processo, assicurarsi di aver creato il gruppo nei progetti che il processo aggiorna.

Esempio non corretto

L'esempio seguente non è valido perché specifica:

  • Elemento ALLOWEDVALUES.
  • Elemento DEFAULT che specifica la stringa value="Not Assigned"di non rientro .
    <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>

Flusso di lavoro

Un elemento WORKFLOW e i relativi elementi figlio devono essere conformi alla sintassi e alle regole descritte in Riferimento agli elementi XML FLUSSO di lavoro. Inoltre, deve soddisfare le condizioni seguenti:

  • Limita ogni WIT a 16 stati del flusso di lavoro
  • Definisce tutti gli stati del flusso di lavoro mappati ai metastate nel file di definizione ProcessConfiguration
  • Definisce una transizione tra tutti gli stati del flusso di lavoro mappati alla categoria di stato "Proposta" e agli stati del flusso di lavoro mappati alla categoria di stato "InProgress"
  • Definisce una transizione tra tutti gli stati del flusso di lavoro mappati alla categoria di stato "InProgress" e agli stati del flusso di lavoro mappati alla categoria di stato "Completa".

Per una descrizione delle categorie di stato e dei mapping, vedere Stati del flusso di lavoro e categorie di stato.

Elenchi globali

Per il modello di processo XML ospitato, vengono inseriti i limiti seguenti all'importazione global-list:

  • Sono presenti al massimo 64 elenchi globali.
  • Sono presenti al massimo 512 elementi per elenco.
  • Circa 10.000 elementi possono essere definiti in totale tra tutti gli elenchi globali specificati in tutte le wit.

Layout del form

Un elemento FORM e i relativi elementi figlio devono essere conformi alla sintassi e alle regole descritte in Riferimento agli elementi XML FORM.

Un elemento Control non può specificare un controllo personalizzato. I controlli personalizzati non sono supportati.