Personalizzare un modello di processo

Azure DevOps Server 2022 - Azure DevOps Server 2019

I modelli di processo definiscono gli oggetti e i processi disponibili quando si crea un progetto. Personalizzando un modello di processo, si personalizza uno di più oggetti. I tipi comuni di personalizzazioni che è possibile apportare includono:

  • Aggiungere un nuovo campo a un tipo di elemento di lavoro esistente (WIT)
  • Modificare l'elenco di selezione dei valori per un campo
  • Modificare gli stati del flusso di lavoro, i motivi, le transizioni e le azioni di un tipo di elemento di lavoro predefinito o personalizzato
  • Modificare il layout di un modulo di un elemento di lavoro
  • Aggiungere o rimuovere un tipo di elemento di lavoro
  • Modificare la configurazione del processo o le impostazioni predefinite associate agli hub di Azure Boards

Nota

Questo articolo descrive i modelli di processo usati per creare progetti definiti in Azure DevOps Services. Per i modelli di progetto per lo sviluppo di software, vedere Creazione di modelli di Visual Studio.

I modelli di processo predefiniti definiscono le configurazioni predefinite e i tipi di elementi di lavoro usati da Azure Boards e dai piani di test di Azure. Ad esempio, il modello di processo Agile definisce il set di tipi di elemento di lavoro illustrati nell'immagine seguente.

Immagine concettuale degli artefatti del modello di processo Agile.

Molti di questi artefatti dipendono dai tipi di elemento di lavoro usati per tenere traccia del lavoro. Ad esempio, i campi dati definiti nella definizione di Funzionalità, Bug, Storia utente o Attività vengono usati anche per definire query sugli elementi di lavoro. Oltre a questi artefatti, è anche possibile definire le aree e le iterazioni iniziali del progetto, la configurazione di sicurezza e altre impostazioni predefinite che supportano i piani di test.

Dopo aver creato un progetto, è possibile modificare le configurazioni e personalizzare gli artefatti. Tuttavia, personalizzando il modello di processo prima di creare i progetti, tutti i progetti risultanti creati corrispondono a un set standard di processi del team. I motivi principali per cui è possibile personalizzare un modello di processo includono:

  • Si prevede di creare diversi progetti e si vogliono ridurre al minimo le attività ripetitive che sarà necessario implementare più avanti in ogni progetto creato
  • Si vuole assicurarsi che tutti i team rispettino determinati standard fornendo i modelli e le strutture all'interno del set di strumenti usato dai team di sviluppo software
  • È necessario aggiornare un modello di processo personalizzato per supportare l'uso della procedura guidata Configura funzionalità dopo un aggiornamento

Se si lavora con un solo progetto, è possibile prendere in considerazione semplicemente la creazione del progetto e la personalizzazione di uno o più oggetti in un secondo momento.

Come vengono usati i modelli di processo?

L'uso principale dei modelli di processo consiste nel creare un progetto. Per il modello di processo XML ospitato, viene usato anche per aggiornare un progetto. Un progetto fornisce il set di oggetti, artefatti e configurazioni definiti nel set interdipendente di file modello. Il progetto viene usato per organizzare il codice sorgente, tenere traccia del lavoro e delle informazioni, compilare software e supportare le attività di test.

Modello di processo XML ospitato

Modello di processo XML locale

da dove iniziare?

Prima di iniziare a personalizzare un modello di processo, è necessario acquisire familiarità con ciò che è possibile configurare e personalizzare e quindi pianificare le modifiche di conseguenza.

  • Se non si ha familiarità con l'elaborazione dei modelli, esaminare prima di tutto i modelli di processo predefiniti.

  • Per acquisire familiarità con la struttura di file di un modello di processo, esaminare una descrizione per ogni file o scaricare un modello di processo.

    È possibile modificare i processi per il progetto dopo la creazione. Quando si lavora con un progetto, le impostazioni iniziali definite dal modello di processo non possono più soddisfare le proprie esigenze.

  • Se si è più interessati a personalizzare gli oggetti usati per tenere traccia del lavoro, inclusi piani di test, gruppi di test e test case, vedere Personalizzare l'esperienza di rilevamento del lavoro. Le personalizzazioni eseguite modificando un file di definizione XML per un progetto sono gli stessi tipi di personalizzazioni eseguite in un file modello di processo.

    Se si desidera aggiungere o modificare tipi di elementi di lavoro, è possibile ottenere questo risultato senza modificare l'intero modello di processo. È possibile apportare e testare le modifiche usando un progetto esistente. Per il modello di processo XML locale, è possibile usare gli strumenti da riga di comando witadmin exportwitd e importwitd per scaricare e caricare i file di definizione XML per i tipi di elemento di lavoro.

  • Se si sta valutando la possibilità di effettuare personalizzazioni complete, esaminare il modo in cui le modifiche apportate influiranno sulla manutenzione e sull'aggiornamento dei progetti.

Elaborare file modello e aree funzionali che è possibile personalizzare

I modelli di processo sono costituiti da nove plug-in. Ogni plug-in definisce un set di attività che vengono eseguite e le schermate visualizzate quando si crea un progetto. Le attività impostano le autorizzazioni, creano cartelle, caricano file, attivano siti o impostano altre variabili configurabili. I plug-in specificano anche le dipendenze che un'attività ha al completamento corretto di altre attività.

Immagine concettuale dei plug-in del modello di processo.

Importante

Quando si crea un progetto dal portale Web, vengono ignorati diversi file modello di processo. In particolare, i file che creano un sito di Gestione report non sono supportati. Per supportare la creazione di report per una raccolta di progetti, vedere Aggiungere report a un progetto team.

Per personalizzare un modello di processo, personalizzare uno o più file associati a un'area funzionale. Durante la personalizzazione di un oggetto è piuttosto semplice, è consigliabile assicurarsi di non interrompere le interdipendenze durante la personalizzazione. Il file plug-in ProcessTemplate.xml definisce quali plug-in includere nel modello. Questo file contiene tutti i gruppi di attività da eseguire per creare un progetto. Ogni gruppo di attività fa riferimento a un file plug-in XML subordinato in cui sono definite le attività specifiche per tale plug-in.

Dipendenze plug-in

Molti oggetti si basano sulla definizione di altri oggetti all'interno di un modello di processo. Per una panoramica dei plug-in e delle dipendenze dei plug-in necessari, vedere Definire le dipendenze per gruppi di attività e attività.

Restrizioni relative a plug-in e denominazione

Quando si aggiungono oggetti a un modello di processo, assicurarsi di etichettarli correttamente in modo da evitare errori di convalida XML.

  • Le restrizioni vengono applicate ai nomi o alle etichette della maggior parte degli oggetti Team Foundation. Per una panoramica delle restrizioni di denominazione applicabili ai modelli di processo, ai gruppi di sicurezza, ai nodi di area e iterazione, ai tipi di elementi di lavoro e ai campi degli elementi di lavoro, vedere Restrizioni di denominazione.

  • La maggior parte dei componenti del modello di processo personalizzati influirà solo sul progetto creato usando il modello di processo. Le eccezioni a questa regola sono elenchi globali, tipi di collegamento e campi elemento di lavoro. Questi oggetti sono definiti per una raccolta di progetti.

  • Ogni campo dell'elemento di lavoro ha un nome di riferimento di campo associato che identifica in modo univoco ogni campo. Non è possibile modificare il nome del riferimento dopo l'assegnazione.

    Inoltre, se si usa SQL Server Reporting Services per la raccolta di progetti, il nome del report assegnato a un campo dell'elemento di lavoro deve corrispondere a tutti i tipi di elemento di lavoro definiti per la raccolta di progetti. In caso contrario, potrebbero verificarsi errori di convalida durante il caricamento del modello di processo o conflitti nei database del data warehouse.

    I nomi dei campi degli elementi di lavoro, i nomi dei tipi di collegamento e gli elenchi globali hanno come ambito una raccolta di progetti. Se si personalizza uno di questi oggetti, la modifica verrà riflessa in tutti i progetti definiti nella raccolta e nei tipi di elemento di lavoro che contengono tale campo dell'elemento di lavoro.

  • La dimensione massima di un modello di processo è di due gigabyte. Quando si personalizza un modello di processo, assicurarsi che le modifiche non aumentino le dimensioni oltre tale valore.

Passaggi per personalizzare un modello di processo

La personalizzazione di un modello di processo è un processo iterativo. Sarà necessaria una raccolta di progetti definita in un server che esegue Azure DevOps Server in cui è possibile testare il modello di processo per assicurarsi che sia stato personalizzato correttamente.

Per personalizzare un modello di processo, scaricare prima di tutto un modello di processo esistente, modificare o aggiungere file, caricare i file modello di processo e quindi verificare le modifiche.

Immagine concettuale che mostra il flusso di lavoro di personalizzazione del modello di processo.

Passaggio Attività
Passaggio 1 Scaricare un modello di processo. Prima di personalizzare un modello di processo, è necessario scaricarlo nel computer locale.

Per ridurre al minimo le modifiche da apportare, selezionare un modello più simile ai processi del team. In generale, si sceglie un modello di processo basato su tipi di elementi di lavoro e flusso di lavoro.
Passaggio 2 Modificare o aggiungere file. È possibile personalizzare un modello di processo modificando, eliminando o aggiungendo file definiti per un modello di processo. È possibile personalizzare un file di definizione o plug-in modificandone il contenuto XML. Ogni file di file plug-in e un file di definizione del tipo deve essere conforme alla definizione dello schema XML.

La prima volta che si personalizza un modello di processo, apportare una piccola modifica. Se si apportano molte modifiche senza una buona comprensione del modo in cui le modifiche possono influire sul modello, si rischia di riscontrare più errori che saranno difficili da eseguire per il debug.

Assicurarsi che il nome del modello di processo sia univoco. Se si scarica un modello di processo, si apportano modifiche e lo si carica, è necessario modificarne il nome oppure sovrascrivi il modello di processo esistente dalla raccolta di progetti.
Passaggio 3 Caricare un modello di processo. Dopo aver personalizzato il modello, caricarlo nella raccolta di progetti in cui verrà creato il progetto.

Idealmente, è consigliabile usare una raccolta di progetti non usata da altri progetti. Lavorando in una raccolta di progetti test-bed, è possibile evitare di introdurre una modifica che potrebbe scontrarsi con i processi del team esistenti ancora in fase di sviluppo. È inoltre necessario che la raccolta di progetti supporti le stesse risorse a cui si vuole accedere, ad esempio un portale di progetto e un sito di report.

Assicurarsi che il nome del modello di processo sia univoco. Se è stato scaricato un modello di processo da una raccolta di progetti, è stata apportata una modifica e ora si carica il modello, è necessario modificarne il nome o eliminare il modello di processo esistente dalla raccolta di progetti.

Il processo di caricamento esegue un controllo di verifica per assicurarsi che il codice XML sia valido. Se si ricevono errori quando si tenta di caricare il modello di processo, le modifiche apportate avranno causato l'errore. Esaminare le modifiche e correggere eventuali errori di sintassi XML presenti.
Passaggio 4 Creare un progetto. Per testare nuovi modelli di processo, è necessario creare un progetto. Se si verificano errori, visualizzare il log per la creazione del progetto. Contiene un elenco delle attività che ha tentato di eseguire e mostra quali attività non sono riuscite. È possibile eseguire il mapping delle attività non riuscite al codice XML per determinare la causa degli errori.

È possibile pulire i progetti non necessari usando lo strumento da riga di comando TFSDeleteProject.
Passaggio 5 Verificare le modifiche apportate ai modelli di elaborazione. Prima di inserire il modello di processo in modalità di produzione e usarlo come base per diversi progetti, è necessario verificare che sia ben definito. Eseguire questa attività verificando sistematicamente che ogni oggetto e artefatto funzioni come previsto.

Strumenti che supportano la personalizzazione di un modello di processo

È possibile personalizzare un modello di processo usando uno degli strumenti seguenti:

  • Qualsiasi editor di testo o editor XML per modificare i file XML.

  • Strumento editor di processi.
    In base alla versione di Visual Studio installata, ottenere lo strumento Editor di processi da una delle estensioni seguenti.

    • Visual Studio 2019: Editor modelli di processo.
    • Visual Studio 2017: Editor modelli di processo TFS. È anche possibile usare questa versione dell'editor di processi per modificare i moduli degli elementi di lavoro in stile precedente. Non è possibile usarlo per modificare i moduli associati ai nuovi web form.
    • Visual Studio 2015: TFS Power Tools.