Applicare regole agli stati del flusso di lavoro (processo di ereditarietà)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Dopo aver aggiunto o modificato gli stati del flusso di lavoro per un tipo di elemento di lavoro, è possibile definire una o più regole applicate a seconda della modifica dello stato del flusso di lavoro. L'aggiunta di regole agli stati del flusso di lavoro supporta gli scenari seguenti:
- Supportare un processo di approvazione
- Impedire agli utenti non autorizzati di impostare uno stato non valido
- Apportare un campo obbligatorio o di sola lettura o altro valore in base alle modifiche dello stato
- Limitare la transizione da uno stato a un altro
- Limitare o consentire transizioni di stato a utenti o gruppi specifici
- Gestire un processo del flusso di lavoro controllato per supportare i requisiti di controllo
- Automatizzare la chiusura degli elementi di lavoro padre
- Supportare un processo di approvazione
- Impedire agli utenti non autorizzati di impostare uno stato non valido
- Apportare un campo obbligatorio o di sola lettura o altro valore in base alle modifiche dello stato
- Limitare la transizione da uno stato a un altro
- Automatizzare la chiusura degli elementi di lavoro padre
- Supportare un processo di approvazione
- Apportare un campo obbligatorio o di sola lettura o altro valore in base alle modifiche dello stato
- Automatizzare la chiusura degli elementi di lavoro padre
Esaminare questo articolo per comprendere come definire le regole che si applicano quando si modifica uno stato del flusso di lavoro.
- Informazioni sui tipi di regole del flusso di lavoro
- Limiti e procedure consigliate per lo stato e le regole del flusso di lavoro
- Impostare un valore di campo o impostare un campo di sola lettura o obbligatorio in base alla selezione dello stato
- Limitare le transizioni di stato
- Limitare o consentire transizioni di stato a utenti o gruppi specifici
- Automatizzare le transizioni di stato degli elementi di lavoro padre
- Informazioni sui tipi di regole del flusso di lavoro
- Limiti e procedure consigliate per lo stato e le regole del flusso di lavoro
- Impostare un valore di campo o impostare un campo di sola lettura o obbligatorio in base alla selezione dello stato
- Limitare le transizioni di stato
- Automatizzare le transizioni di stato degli elementi di lavoro padre
- Informazioni sui tipi di regole del flusso di lavoro
- Limiti e procedure consigliate per lo stato e le regole del flusso di lavoro
- Impostare un valore di campo o impostare un campo di sola lettura o obbligatorio in base alla selezione dello stato
- Automatizzare le transizioni di stato degli elementi di lavoro padre
Importante
Questo articolo si applica alle versioni Azure DevOps Services e Azure DevOps Server 2019 e versioni successive. Per personalizzare qualsiasi progetto definito in una raccolta per TFS 2018 o versioni precedenti, vedere Modello di processo XML locale.
Importante
È possibile usare solo il modello di processo di ereditarietà per i progetti definiti in una raccolta di progetti configurata per supportare il modello di processo di ereditarietà. Se la raccolta locale è configurata per l'uso del modello di processo XML locale, è possibile usare tale modello di processo solo per personalizzare l'esperienza di rilevamento del lavoro. Per altre informazioni, vedere Personalizzare il rilevamento del lavoro, scegliere il modello di processo per la raccolta di progetti.
Per personalizzare qualsiasi progetto definito in una raccolta per TFS 2018 o versioni precedenti, vedere Modello di processo XML locale.
Regole del flusso di lavoro
La tabella seguente indica i tre gruppi di regole del flusso di lavoro che è possibile definire. Il primo gruppo applica azioni standard quando viene creato un elemento di lavoro, in uno stato selezionato o viene spostato da uno stato a un altro. Queste azioni standard impostano il valore di un campo o rendono un campo di sola lettura o obbligatorio. In questo gruppo è possibile specificare una o due condizioni e diverse azioni.
Il secondo e il terzo gruppo supportano la limitazione delle transizioni di stato. Questi due gruppi consentono di specificare una e una sola condizione che indica lo stato in cui è stato spostato un elemento di lavoro. È quindi possibile specificare una o più azioni per limitare la transizione da tale stato ad altri stati.
La tabella seguente indica i due gruppi di regole del flusso di lavoro che è possibile definire. Il primo gruppo applica azioni standard quando viene creato un elemento di lavoro, in uno stato selezionato o viene spostato da uno stato a un altro. Queste azioni standard impostano il valore di un campo o rendono un campo di sola lettura o obbligatorio. In questo gruppo è possibile specificare una o due condizioni e diverse azioni.
Il secondo gruppo supporta la limitazione delle transizioni di stato. In questo secondo gruppo è possibile specificare una e una sola condizione che indica lo stato in cui è stato spostato un elemento di lavoro. È quindi possibile specificare una o più azioni per limitare la transizione da tale stato ad altri stati.
Nota
Alcune funzionalità richiedono l'installazione di Azure DevOps Server aggiornamento 2020.1. Per altre informazioni, vedere Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.
Le condizioni e le azioni del flusso di lavoro che è possibile impostare sono illustrate nelle immagini seguenti. È possibile applicare azioni standard quando viene creato un elemento di lavoro, in uno stato selezionato o viene spostato da uno stato a un altro. Queste azioni standard impostano il valore di un campo o rendono un campo di sola lettura o obbligatorio. Per questo set di regole è possibile specificare una o due condizioni e diverse azioni.
Condition
Azioni supportate
Impostare il valore del campo o impostare il valore di sola lettura/obbligatorio in base allo stato
Limitare una transizione in base allo stato
Nascondere il campo o rendere il campo di sola lettura o obbligatorio in base allo stato e all'appartenenza a un utente o a un gruppo
In base all'appartenenza a un utente o a un gruppo, impostare un attributo di campo o limitare una transizione di stato
Nota
Quando si personalizza un processo ereditato, tutti i progetti che usano tale processo vengono aggiornati automaticamente per riflettere le personalizzazioni. Per questo motivo, è consigliabile creare un processo di test e un progetto di test quando si dispone di numerose personalizzazioni da eseguire per testare le personalizzazioni prima di implementarle all'organizzazione. Per altre informazioni, vedere Creare e gestire processi ereditati.
Limiti dello stato e delle regole del flusso di lavoro
La tabella seguente riepiloga i limiti delle regole e degli stati del flusso di lavoro per il processo di ereditarietà.
Oggetto | Limite di ereditarietà |
---|---|
Tipi di elementi di lavoro definiti per un processo | 64 |
Stati del flusso di lavoro definiti per un tipo di elemento di lavoro | 32 |
Regole definite per un tipo di elemento di lavoro | 1024 |
Quando si definiscono gli stati e le regole del flusso di lavoro, è consigliabile considerare le indicazioni seguenti per ridurre al minimo i problemi di prestazioni.
- Ridurre al minimo il numero di regole definite per un WIT. Sebbene sia possibile creare più regole per un tipo di elemento di lavoro, l'aggiunta di regole può influire negativamente sulle prestazioni quando un utente aggiunge e modifica gli elementi di lavoro. Quando gli utenti salvano gli elementi di lavoro, il sistema convalida tutte le regole associate ai campi per il tipo di elemento di lavoro. In determinate condizioni, l'espressione di convalida delle regole è troppo complessa essere valutata da SQL.
- Ridurre al minimo il numero di tipi di elementi di lavoro personalizzati definiti.
Le regole del flusso di lavoro vengono applicate durante l'aggiunta o la modifica degli elementi di lavoro tramite una delle interfacce seguenti:
- Portale Web: modulo elemento di lavoro, aggiornamenti in blocco, aggiornamenti nella visualizzazione query
- Portale Web: scheda Kanban o Taskboard, spostare l'elemento di lavoro nella colonna
- Visual Studio 2017 e versioni precedenti, modulo elemento di lavoro
- Formato file CSV: importazione bulk o aggiornamento
- Excel: importazione bulk o aggiornamento
- API REST: aggiungere o modificare elementi di lavoro
Definire una regola
Prima di definire una regola in base agli stati del flusso di lavoro, assicurarsi di definire prima gli elementi seguenti:
- Il flusso di lavoro indica che si vuole come descritto in Personalizzare un flusso di lavoro
- Se la regola richiede una specifica di un campo personalizzato, aggiungere tale campo al tipo di elemento di lavoro come descritto in Aggiungere e gestire i campi
- Se la regola richiede una specifica di un gruppo di sicurezza per concedere o limitare le modifiche in base all'appartenenza all'utente o al gruppo, definire tale gruppo di sicurezza come descritto in Aggiungere o rimuovere utenti o gruppi, gestire i gruppi di sicurezza.
Per le nozioni di base sulla definizione delle regole, vedere Aggiungere una regola personalizzata. È necessario soddisfare i prerequisiti definiti in tale articolo.
Impostare il valore del campo o impostare il campo di sola lettura o obbligatorio
Con il primo raggruppamento di regole, è possibile specificare una o due condizioni e fino a 10 azioni per regola.
Esempio di garantire l'approvazione del team prima del lavoro attivo
In questo esempio, i team di sviluppo vogliono assicurarsi che nessuna storia utente venga eseguita fino all'approvazione da parte di un responsabile del team. Gli stati predefiniti del flusso di lavoro sono in uso e vengono aggiunti solo un singolo campo personalizzato, Approvato by e gruppo di sicurezza, Team Lead Group.
Stati del flusso di lavoro predefiniti
Requisiti delle regole
Per garantire l'approvazione prima del lavoro attivo, è necessario definire le regole seguenti:
- Richiedere che il campo Approvato by venga compilato quando lo stato viene spostato da Nuovo a Attivo
- Limitare gli utenti che non appartengono al gruppo di lead team per compilare il campo Approvato da
- Deselezionare il campo Approvato per quando lo stato passa a Nuovo o Rimosso
Definizioni delle regole
I requisiti della regola vengono convertiti nelle quattro definizioni di regole seguenti.
Nome regola
Condition
Actions
Approvato da deselezionato quando nuovo
Quando A work item state changes to New
Poi Clear the value of Approved By
Approvato Da deselezionato quando rimosso
Quando A work item state changes to Removed
Poi Clear the value of Approved By
Approvato solo da lettura
Quando Current user is not member of group Team Leads Group
Poi Make read-only Approved By
Approvato da obbligatorio
Quando A work item state changes from New to Active
Poi Make required Approved By
Limitare le transizioni di stato
Quando si specifica la condizione , A work item state moved from ...
è possibile specificare solo tale condizione. È possibile specificare fino a 10 azioni.
Nota
Questa funzionalità richiede Azure DevOps Server aggiornamento 2020.1 o versione successiva.
Esempio di limitazione delle transizioni di stato e stato approvato
In base alla terminologia usata da un gruppo aziendale, gli stati del flusso di lavoro seguenti sono definiti per la storia utente. Gli stati ereditati nuovi, risolti e rimossi sono nascosti. Vengono invece usati stati proposti, in revisione e Cut States. Sono inoltre definiti tre stati aggiuntivi: analisi, progettazione e approvazione. Questi Stati devono seguire la sequenza come illustrato nell'immagine seguente.
Senza restrizioni, gli utenti possono passare da uno stato a qualsiasi altro stato, sia avanti che indietro all'interno della sequenza.
Requisiti delle regole
Per supportare un flusso di lavoro più controllato, il gruppo aziendale ha deciso di istituto regole che supportano le transizioni di stato in avanti e inverso seguenti sul tipo di elemento di lavoro di User Story.
- La proposta può essere spostata solo in Ricerca e Taglio
- La ricerca può passare solo a Design e Cut
- La progettazione può passare solo a Ricerca, Approvazione e Taglio
- Approvato può passare solo a Design, Active e Cut
- Attiva può passare solo a In Review
- In Revisione può passare solo a Attivo (lavoro aggiuntivo trovato), Chiuso o Taglia
- Chiuso può passare a Research, Design, Active, In Review (Consente ai casi in cui l'utente ha chiuso l'elemento di lavoro in errore)
- Taglia può passare solo a Proposta.
Nota
Quando si limitano le transizioni di stato, prendere in considerazione i casi in cui un utente sposta uno stato in errore. Si vuole che gli utenti possano recuperare correttamente.
Inoltre, il gruppo aziendale vuole applicare regole per i campi obbligatori:
- Richiedere che il campo Approvato by venga compilato quando lo stato viene spostato da Approvato a Attivo
- Consente solo agli utenti che appartengono al gruppo Approvatori autorizzati di compilare il campo Approvato da
- Deselezionare il campo Approvato per quando lo stato passa a Taglia
- Richiedere che i criteri di accettazione vengano compilati quando lo stato viene spostato su Attivo
Definizioni delle regole
Per implementare le restrizioni precedenti, l'amministratore del processo aggiunge un campo personalizzato Approvato per identità, un gruppo di sicurezza di approvazione autorizzato e le undici regole seguenti.
Nome regola
Condition
Actions
Stato proposto
Quando A work item state moved from Proposed
Poi Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Stato di ricerca
Quando A work item state moved from Research
Poi Restrict the state transition to Proposed
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Stato di progettazione
Quando A work item state moved from Design
Poi Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Stato approvato
Quando A work item state moved from Approved
Poi Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Stato attivo
Quando A work item state moved from Active
Poi Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Closed
In Verifica stato
Quando A work item state moved from In Review
Poi Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
Stato chiuso
Quando A work item state moved from Closed
Poi Restrict the state transition to Proposed
E Restrict the state transition to Cut
Stato di taglio
Quando A work item state moved from Cut
Poi Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Campi obbligatori dello stato approvato
Quando A work item changes from Approved to Active
Poi Make required Acceptance Criteria
E Make required Approved By
Responsabili approvazione autorizzati
Quando Current user is not a member of Authorized Approvers
Poi Make read-only Approved By
Deselezionare il campo Approvato per
Quando A work item state changes to Cut
Poi Clear the value of Approved By
Verificare le restrizioni di transizione dello stato
Dopo aver definito le regole per il processo e il progetto aggiornato con il processo, aggiornare il browser e controllare le operazioni tramite il modulo dell'elemento di lavoro e dal browser Kanban.
Per le regole definite nella tabella precedente, verranno visualizzati i menu a discesa Stato seguenti. Aprire la bacheca Kanban e controllare la possibilità di passare da uno Stato a un altro.
Proposed | Ricerca | Progettazione | Approved |
---|---|---|---|
Attivo | In revisione | Chiusa | Taglia |
Limitare la transizione dello stato in base all'appartenenza a un utente o a un gruppo
Quando si specifica una delle due condizioni in base all'appartenenza Current user is member of group ...
a un utente o a un gruppo oppure Current user is not member of group ...
, è possibile specificare una sola condizione. Inoltre, se si specifica l'azione Restrict the transition to state...
, è possibile specificare solo un'azione.
Nota
Gli elementi di lavoro sono soggetti alle regole applicate. Le regole condizionali basate sull'appartenenza a utenti o gruppi vengono memorizzate nella cache per il Web browser. Se ci si trova limitato ad aggiornare un elemento di lavoro, potrebbe essere stata rilevata una di queste regole. Se si ritiene di aver riscontrato un problema che non si applica all'utente, vedere Problemi di memorizzazione nella cache di IndexDB nel modulo elemento di lavoro.
Automatizzare le transizioni di stato degli elementi di lavoro padre
Per automatizzare le transizioni di stato degli elementi di lavoro padre in base alle assegnazioni di stato effettuate agli elementi di lavoro figlio, è possibile aggiungere un web hook e usare il codice e la configurazione forniti nel progetto GitHub Automate State Transitions .
Nota
Il progetto GitHub Automate State Transitions non è una funzionalità supportata di Azure Boards e pertanto non è supportata dal team del prodotto. Per domande, suggerimenti o problemi che si verificano quando si usano queste estensioni, generarle nella pagina del progetto GitHub.
Automatizzare la riassegnazione in base alla modifica dello stato
Il tipo di elemento di lavoro del processo Agile aveva in precedenza una regola che riassegnava il bug alla persona che l'ha creata. Questa regola è stata rimossa dal processo di sistema predefinito. È possibile ripristinare la regola o aggiungere una regola simile ad altri tipi di elementi di lavoro usando la condizione e l'azione seguenti:
QuandoA work item state changes to
Risoltoe quindiCopy the value from
creato daaassegnato a.
Articoli correlati
Nota
È possibile esaminare le modifiche apportate a un processo ereditato tramite il log di controllo. Per altre informazioni, vedere Accedere, esportare e filtrare i log di controllo.
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per