Automazione delle assegnazioni dei campi in base a stato, transizione o causa

È possibile che si desideri eseguire la transizione automatica di elementi di lavoro da uno stato all'altro in base a un evento che si verifica altrove in Visual Studio Application Lifecycle Management (ALM) o a un evento che si verifica all'esterno di ALM di Visual Studio. 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 Gestione elementi di lavoro vengono estesi per supportare la transizione automatica degli elementi di lavoro mediante 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 post-azione dell'elemento di lavoro specificato. La finestra di dialogo di archiviazione di controllo della versione utilizza questo metodo per risolvere bug e chiudere attività associate all'archiviazione.

ACTION è un elemento figlio facoltativo di ACTIONS.

Uno strumento può essere preimpostato per la transizione automatica di un elemento di lavoro allo stato "Risolto" dopo che l'utente ha archiviato una modifica; tuttavia, il fornitore dell'integrazione non può sapere quale stato sia stato dichiarato dall'autore del tipo di elemento di lavoro come "Risolto". 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".

Tale soluzione risulta tuttavia troppo restrittiva dal punto di vista internazionale in quanto non consente la localizzazione degli stati. Gli integratori dei sistemi possono invece dichiarare una azione come "Archiviazione" o "Completamento" per indurre una transizione automatica per gli elementi di lavoro. L'autore del tipo di elemento di lavoro può quindi dichiarare questa azione nella transizione appropriata.

In questo 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 utilizzata la sintassi seguente. L'attributo Value specifica il nome dell'azione ed è obbligatorio. Per le azioni è necessario seguire le stesse convenzioni di denominazione utilizzate per i nomi di riferimento del campo. Ad esempio, Controllo della versione di Team Foundation utilizza Microsoft.VSTS.Actions.CheckIn per identificare la transizione appropriata per gli elementi di lavoro associati all'archiviazione. Per ulteriori 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 lo strumento effettui i seguenti passaggi:

1. Determinare lo stato dell'elemento di lavoro che dovrà essere sottoposto a transizione quando l'azione viene eseguita.

2. 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 ALM di Visual Studio SDK. Per ulteriori informazioni, vedere la pagina seguente nel 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 provocato una transizione, è possibile specificare un altro campo dell'elemento di lavoro da gestire, oppure è possibile definire un valore Reason.

Torna all'inizio

Associazione di una transizione di stato a un'azione

È possibile utilizzare le azioni di transizione dello stato per automatizzare le transizioni degli elementi di lavoro in vari punti all'interno del flusso di lavoro. Ad esempio, in un sistema di controllo della versione di Team Foundation Server è necessario che siano supportate le 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 utilizzare tale elemento di lavoro quando uno sviluppatore apporta modifiche. L'autore può definire un altro stato denominato "Ready To Build", che indica 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

Utilizzare le azioni di transizione dello stato per automatizzare le transizioni degli elementi di lavoro in vari punti all'interno del flusso di lavoro. Per le transizioni è opportuno considerare i seguenti dettagli di utilizzo:

• Le azioni di transizione sono facoltative. Se lo stato attuale dell'istanza dell'elemento di lavoro dispone di una voce per l'azione specificata, viene restituito lo stato "to". In caso contrario, il valore restituito sarà 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 individuata.

• Per ciascun tipo di elemento di lavoro, le azioni devono essere univoche per la coppia From State/Action. In altre parole, gli autori dei tipi di elemento di lavoro non possono specificare più stati "to" per la stessa azione.

• Sono tuttavia supportate più azioni sulla 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 utilizzati i caratteri latini.

• Tali nomi devono seguire la stessa convenzione relativa allo spazio dei nomi di riferimento utilizzata per i nomi di riferimento di campo per evitare conflitti di nomi tra produttori e clienti. Questa convenzione non viene tuttavia applicata dallo strumento. ALM di Visual Studio utilizza Microsoft.VSTS.Actions.<your action>.

Torna all'inizio

Controllo degli errori delle transizioni automatiche

I programmi di integrazione 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 un processo automatico non presidiato, ad esempio una compilazione notturna.

• Transizioni automatiche determinate da azioni dell'utente   Per questo tipo di transizioni automatiche è presente un utente che reagisce a tutti i problemi collegati alle regole. È necessario verificare di disporre del supporto necessario per le situazioni che si verificano quando un 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 verificare eventuali violazioni delle regole nel tipo di elemento di lavoro. Se si rilevano violazioni, comunicare all'utente il modo per risolverle.

• Transizioni automatiche non presidiate   In questo caso, si presume che nessun utente sia presente per risolvere questi problemi. L'integrazione avrà esito negativo in modo regolare. e nel log degli errori verranno riportati il tentativo di transizione automatica e il motivo dell'errore.

Quando si definisce uno dei tipi di transizione automatica, definire la transizione in modo che ciascun elemento di lavoro raggiunga uno stato di validità alla fine della transizione senza che sia necessario l'intervento dell'utente. Per soddisfare tutte le regole della transizione dello stato è opportuno quindi fornire valori predefiniti o copiati per tutti i campi. Se uno dei campi perde validità dopo la transizione, la transizione dello stato non avrà esito positivo.

Per evitare che i campi perdano validità, attenersi alla procedura riportata di seguito.

• Definire una regola DEFAULTREASON per la transizione dello stato.

• Per i campi che dovrebbero essere obbligatori dopo la transizione di stato, utilizzare gli elementi di 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". Andrebbe quindi definito un elemento di regola DEFAULT o COPY per "ResolvedBy" nella sezione TRANSITION. Andrebbe inoltre definito un elemento DEFAULTREASON per accertarsi che il campo obbligatorio possa essere impostato senza l'intervento dell'utente.

Torna all'inizio

Vedere anche

Concetti

Quando e dove applicare una regola di campo

Associazione di una transizione di stato a un'azione

Cronologia delle modifiche