Rendere automatiche le assegnazioni dei campi in base a stato, transizione o motivo
Potrebbe essere necessario eseguire la transizione automatica di elementi di lavoro da uno stato all'altro in base a un evento che si verifica in un altro punto di Visual Studio Application Lifecycle Management (ALM) o a un evento che si verifica all'esterno di Visual Studio ALM. Si può ad esempio decidere di automatizzare la transizione di un bug da uno stato all'altro in base a quanto si verifica in uno strumento di traccia delle chiamate Il modello del tipo di elemento di lavoro e l'API di Gestione elementi di lavoro vengono estesi per supportare la transizione automatica degli elementi di lavoro tramite altri sistemi.
Se si dispone di codice che modifica lo stato di un elemento di lavoro, è possibile generalizzare tale codice associando l'azione alla transizione di stato appropriata tramite l'elemento ACTION. È possibile passare il valore dell'azione al metodo [WorkItem.GetNextState] per ottenere lo stato successivo all'azione per l'elemento di lavoro specificato. La finestra di dialogo di archiviazione del controllo della versione usa questo metodo per risolvere i bug e chiudere le attività associate all'archiviazione.
ACTION è un elemento figlio facoltativo di ACTIONS.
Nota
L'API di Gestione elementi di lavoro fa parte di Visual Studio ALM SDK, come descritto nella pagina seguente sul sito Web Microsoft: Estensione di Team Foundation.
Uno strumento può essere ad esempio preimpostato per la transizione automatica di un elemento di lavoro allo stato "Risolto" dopo che l'utente ha archiviato una modifica. Un provider di integrazione non può tuttavia sapere quale sia lo stato dichiarato come "Risolto" dall'autore del tipo di elemento di lavoro. L'autore potrebbe avere inteso Risolto, Chiuso, Completato, Pronto per il test, Includere nella compilazione e così via.. Una soluzione potrebbe consistere nel richiedere a tutti gli autori dei tipi di elemento di lavoro di includere uno stato denominato esplicitamente "Risolto".
Questa soluzione è tuttavia troppo restrittiva. anche dal punto di vista internazionale, in quanto non consente la localizzazione degli stati. Gli integratori dei sistemi possono invece dichiarare un'azione come "Archiviazione" o "Completamento" per indurre una transizione automatica per gli elementi di lavoro. L'autore del tipo di elemento di lavoro potrebbe quindi dichiarare questa azione nella transizione appropriata.
Contenuto dell'argomento
Sintassi dell'elemento ACTION
Passaggi richiesti per supportare l'automazione
Associazione di una transizione di stato a un'azione
Informazioni dettagliate sulle azioni di transizione
Controllo degli errori delle transizioni automatiche
Sintassi dell'elemento ACTION
Per l'elemento ACTION viene usata la sintassi seguente. L'attributo Value specifica il nome dell'azione ed è obbligatorio. Per le azioni è necessario seguire le stesse convenzioni di denominazione usate per i nomi di riferimento di campo. Ad esempio, Controllo della versione di Team Foundation usa Microsoft.VSTS.Actions.CheckIn per identificare la transizione appropriata per gli elementi di lavoro associati all'archiviazione. Per altre informazioni, vedere Convenzioni di denominazione per oggetti di rilevamento di elementi di lavoro.
<ACTION value="NameOfAction" />
minOccurs="0"
maxOccurs="unbounded"
Passaggi richiesti per supportare l'automazione
Per integrare uno strumento con Gestione elementi di lavoro, è necessario che nello strumento venga eseguita la procedura seguente:
Determinare a quale stato dovrà passare l'elemento di lavoro quando viene eseguita l'azione.
Impostare l'elemento di lavoro sullo stato "to".
L'API di Gestione elementi di lavoro fornisce metodi per l'esecuzione di questa procedura. L'API di Gestione elementi di lavoro fa parte di Visual Studio ALM SDK. Per altre informazioni, vedere la pagina seguente sul sito Web Microsoft: Team Foundation Server SDK.
Nota
La transazione che ha determinato una particolare transizione di stato non viene registrata.Se è necessario tenere traccia dell'azione che ha causato una transizione, è possibile specificare un altro campo dell'elemento di lavoro a tale scopo oppure è possibile definire un valore Reason.
Torna all'inizio
Associazione di una transizione di stato a un'azione
È possibile usare azioni di transizione dello stato per automatizzare le transizioni di elementi di lavoro in vari punti del flusso di lavoro. Un sistema di controllo della versione di Team Foundation Server deve ad esempio supportare transizioni automatiche degli elementi di lavoro in fase di archiviazione. A questo scopo è stata definita un'azione "microsoft.vsts.actions.checkin".
L'autore di un tipo di elemento di lavoro può definire un tipo di elemento di lavoro "Defect" con uno stato denominato "Working" e usare tale elemento di lavoro quando uno sviluppatore apporta modifiche. L'autore può definire un altro stato denominato "Ready To Build", per indicare che lo sviluppatore ha dichiarato pronto per la generazione notturna il codice in cui si è verificato il problema.
L'autore può quindi specificare la transizione automatica dell'elemento di lavoro dallo stato "Working" allo stato "Ready To Build" durante un'operazione di archiviazione dichiarando quanto riportato di seguito:
<TRANSITION from="Working" to="Ready To Build">
<ACTIONS>
<ACTION value="microsoft.vsts.actions.checkin"/>
</ACTIONS>
</TRANSITION>
Torna all'inizio
Informazioni dettagliate sulle azioni di transizione
Usare azioni di transizione dello stato per automatizzare le transizioni di elementi di lavoro in vari punti del flusso di lavoro. Per le azioni di transizione è opportuno considerare i seguenti dettagli di utilizzo:
Le azioni di transizione sono facoltative. Se lo stato attuale dell'istanza dell'elemento di lavoro include una voce per l'azione specificata, viene restituito lo stato "to". In caso contrario, il valore restituito è Null. Le integrazioni devono gestire correttamente i valori Null restituiti. In altre parole:
Non determinare errori.
Lasciare una traccia o un log che indichi che l'integrazione non ha determinato la transizione automatica, in quanto era necessaria un'azione che non è stata trovata.
Per ogni tipo di elemento di lavoro le azioni devono essere univoche per la coppia From State/Action. Ciò significa che gli autori dei tipi di elemento di lavoro non possono specificare più stati "to" per la stessa azione.
Sono tuttavia supportate più azioni nella stessa transizione per consentire più integrazioni di transizione automatica, come illustrato nell'esempio seguente:
<TRANSITION from="Working" to="Ready To Build"> <ACTIONS> <ACTION value="Microsoft.VSTS.Actions.Checkin"/> <ACTION value="ADatum.Actions.Complete"/> </ACTIONS> </TRANSITION>I nomi delle azioni sono nomi assegnati a livello di codice per i quali vengono usati solo caratteri latini.
Tali nomi devono seguire la stessa convenzione relativa allo spazio dei nomi di riferimento usata per i nomi di riferimento di campo, in modo da evitare conflitti di nomi tra fornitori e clienti. Questa convenzione non viene tuttavia applicata dallo strumento. Visual Studio ALM usa Microsoft.VSTS.Actions.<your action>.
Controllo degli errori delle transizioni automatiche
Gli integratori possono provare a eseguire due tipi di transizioni automatiche. Il primo è costituito da una transizione automatica che si verifica a seguito di un'azione da parte dell'utente. Il secondo è costituito da una transizione automatica senza intervento dell'utente, ad esempio una compilazione notturna.
Transizioni automatiche con intervento dell'utente Per questo tipo di transizioni automatiche è presente un utente che reagisce agli eventuali problemi correlati alle regole. È necessario verificare di avere il supporto necessario per le situazioni che si verificano quando l'autore di un tipo di elemento di lavoro aggiunge un campo obbligatorio che l'integrazione non riconosce. Per supportare questa situazione, eseguire la transizione automatica e quindi verificare le eventuali violazioni delle regole nel tipo di elemento di lavoro. In caso di violazioni, visualizzare il modulo che l'utente potrà usare per risolverle.
Transizioni automatiche senza intervento dell'utente In questo caso si presume che nessun utente sia presente per risolvere i problemi. L'integrazione avrà esito negativo in modo normale. Nel log degli errori verranno riportati il tentativo di transizione automatica e il motivo dell'errore.
Definire uno dei tipi di transizione automatica in modo che ciascun elemento di lavoro raggiunga uno stato valido alla fine della transizione, senza che sia necessario l'intervento dell'utente. In altre parole, per soddisfare tutte le regole definite per la transizione dello stato è opportuno fornire valori predefiniti o copiati per tutti i campi. Se uno dei campi diventa non valido dopo la transizione, la transizione dello stato non riuscirà.
Per evitare che i campi diventino non validi, eseguire le operazioni seguenti:
Definire una regola DEFAULTREASON per la transizione dello stato.
Per i campi che dovrebbero diventare obbligatori dopo la transizione di stato, usare gli elementi della regola DEFAULT o COPY per specificare un valore per il campo.
Ad esempio, è stata creata l'azione di transizione Archiviazione che esegue la transizione dello stato di un elemento di lavoro da "In corso" a "Pronto per la compilazione". Le regole dell'elemento di lavoro relative a "Pronto per la compilazione" richiedono l'impostazione del campo "Risolto da". Si dovrà quindi definire un elemento per la regola DEFAULT o COPY per "ResolvedBy" nella sezione TRANSITION e definire anche una regola DEFAULTREASON per accertarsi che il campo obbligatorio possa essere impostato senza l'intervento dell'utente.