Condividi tramite

Personalizzare un processo XML ospitato

  • Articolo

Servizi di Azure DevOps

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 i file di definizione XML di un modello di processo. Questa funzionalità è disponibile solo quando i dati vengono migrati in Azure DevOps Services usando Team Foundation Server servizio di importazione del database.

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 degli elementi di lavoro e di 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.

Utilizzato durante l'importazione/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 sugli elementi di lavoro

Build

Lab Management

Controllo della versione

Mapping di Microsoft Project

Report

Portale (prodotti SharePoint)

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

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

Come personalizzare un processo

Quando si personalizza un processo, iniziare con un processo ben definito è più semplice rispetto alla creazione di un nuovo processo.

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 di 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 sta lavorando 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 che si trova nella directory radice.

    Denominare il 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 le 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 superare 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: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Vedere Restrizioni di denominazione per vincoli aggiuntivi.
  • 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 di 2 GB. In caso contrario, la creazione del progetto ha esito negativo.

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 del portfolio nonparentato
  • Specifica un solo backlog del portfolio padre per ogni backlog del portfolio subordinato
  • Contiene i mapping dello stato del flusso di lavoro necessari per metastate e non fa riferimento a metastate non supportati

Categorie

Il file di definizione di Categories.xml deve essere conforme alla sintassi e alle regole descritte in Categorie riferimento agli elementi XML. 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 Riferimento agli elementi XML WITD. Inoltre, deve soddisfare le condizioni seguenti:

  • Sono presenti al massimo 1024 campi all'interno di un singolo WIT e 1024 campi in tutte le reti 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 richiesto 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 sono lettere senza spazi.
  • L'elemento WITD contiene un elemento FORM che definisce un elemento WebLayout conforme alla sintassi specificata negli elementi WebLayout e Control.

Campi 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 richiesto 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 sono lettere senza spazi.

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

Limitazioni del limite

  • Un elemento FIELDS è limitato a 1024 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.

Campi obbligatori

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 tutti i wit in una categoria che definisce un backlog regolare o un backlog del portfolio, 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 nome 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 Identity

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 identity

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 aggiornati dal processo.

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>

Workflow

Un elemento WORKFLOW e i relativi elementi figlio devono essere conformi alla sintassi e alle regole descritte in Informazioni di riferimento sugli 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 e dei mapping dello stato, 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.
  • Ci sono al massimo 1.024 elementi per elenco.
  • Circa 10.000 elementi possono essere definiti in totale tra tutti gli elenchi globali specificati in tutte le reti WIT.

Layout del form

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

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