Aggiunta dei campi di integrazione nei tipi di elemento di lavoro

Articolo
08/11/2011

È possibile personalizzare i tipi di elemento di lavoro in modo da contenere informazioni generate dai processi automatizzati, aggiungendo campi che si integrano con Team Foundation Build, Microsoft Test Manager e Controllo della versione di Team Foundation.

In questo argomento

Campi che si integrano con Team Build
Campi che si integrano con Visual Studio Test Tools
Campi che si integrano con il codice sorgente di Team Foundation

Campi che si integrano con Team Foundation Build

Team Foundation Build è il processo di compilazione automatica di Team Foundation Server. È possibile configurare il processo di compilazione tramite Team Foundation Build. Team Foundation Build consente di generare elementi di lavoro quando si verifica un errore di compilazione e di aggiungere informazioni sulla compilazione agli elementi di lavoro risolti in una compilazione particolare. Per il funzionamento di questa operazione, Team Foundation Build richiede la presenza di due campi: Found In e Integration Build.

Aggiunta del campo Found in

Team Foundation Build crea un nuovo elemento di lavoro quando si verifica un errore nella compilazione e imposta il campo Found In sul numero di build in cui si è verificato l'errore. Il campo Found In deve essere presente nel tipo di elemento di lavoro che Team Foundation Build dovrà creare quando si verifica l'errore nella compilazione. Se il campo Found In manca, Team Foundation Build non crea un elemento di lavoro per la compilazione non riuscita e tutte le altre operazioni funzionano nel modo previsto.

Nella tabella seguente è riportato un riepilogo dei nomi e dei valori degli attributi del campo Found In.

Nome attributo	Valore attributo
RefName	Microsoft.VSTS.Build.FoundIn
Nome	Può essere impostato su qualsiasi valore, in quanto le integrazioni funzionano sulla base dei nomi di riferimento dei campi, non dei nomi dei campi.
Tipo	Stringa

Esempio di campo Found In

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
</FIELD>

Aggiunta del campo Integration Build

Team Foundation Build identifica gli elementi di lavoro risolti con ciascuna compilazione e aggiorna tali elementi per impostare il numero di compilazione in cui sono stati risolti. Il numero di build viene impostato nel campo Integration Build. Se il campo Integration Build manca, Team Foundation Build non memorizza il numero di compilazione negli elementi di lavoro e tutte le altre operazioni funzionano nel modo previsto.

Nella tabella seguente è riportato un riepilogo dei nomi e dei valori degli attributi del campo Integration Build.

Nome attributo	Valore attributo
RefName	Microsoft.VSTS.Build.IntegrationBuild
Nome	Può essere impostato su qualsiasi valore, in quanto le integrazioni funzionano sulla base dei nomi di riferimento dei campi, non dei nomi dei campi.
Tipo	Stringa

Esempio del campo Integration Build

<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
</FIELD>

Campi che si integrano con Visual Studio Test Tools

Alcune edizioni di Visual Studio includono strumenti di test integrati nell'ambiente di sviluppo. Una funzionalità disponibile negli strumenti di sviluppo consiste nella possibilità di creare elementi di lavoro quando si verifica un errore in un test. Per effettuare questa operazione, nella finestra Risultati test, fare clic con il pulsante destro del mouse sul risultato per il quale si desidera creare un bug, scegliere Crea elemento di lavoro, quindi scegliere il tipo di elemento di lavoro da creare, ad esempio Bug. Per ulteriori informazioni, vedere Procedura: creare un elemento di lavoro dai risultati di un test.

Quando un elemento di lavoro viene creato in questo modo, è possibile inserire dati in tre campi per fornire informazioni sull'errore del test. I tre campi sono TestName, TestId e TestPath. Test Manager imposta questi tre campi utilizzando informazioni specifiche sul test con esito negativo. Se i campi TestName, TestId e TestPath mancano nell'elemento di lavoro, i campi non vengono impostati e tutte le altre operazioni funzionano nel modo previsto.

Nella tabella riportata di seguito vengono riepilogati i valori e gli attributi di questi tre campi.

Nome attributo	Valore attributo
RefName	Microsoft.VSTS.Test.TestName, Microsoft.VSTS.Test.TestId, Microsoft.VSTS.Test.TestPath
Name	Può essere impostato su qualsiasi valore, in quanto le integrazioni funzionano sulla base dei nomi di riferimento dei campi, non dei nomi dei campi.
Tipo	Stringa

Esempio di campi TestName, TestId e TestPath

<FIELD name="Test Name" refname="Microsoft.VSTS.Test.TestName" type="String" reportable="detail">
    <HELPTEXT>The name of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Id" refname="Microsoft.VSTS.Test.TestId" type="String" reportable="detail">
    <HELPTEXT>The Id of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Path" refname="Microsoft.VSTS.Test.TestPath" type="String" reportable="detail">
    <HELPTEXT>The full pathname of the test that found this bug</HELPTEXT>

Campi che si integrano con il controllo della versione di Team Foundation

Una delle funzionalità disponibili in Controllo della versione di Team Foundation consente di associare o risolvere gli elementi di lavoro durante l'archiviazione del codice. Se è stato utilizzato un particolare elemento di lavoro durante la modifica del codice, è possibile impostare tale associazione dalla finestra di archiviazione del controllo del codice sorgente una volta terminate le operazioni sul codice.

La possibilità di Controllo della versione di Team Foundation di risolvere un elemento di lavoro richiede la presenza di un'azione particolare nell'elemento di lavoro. Il sistema di controllo del codice sorgente interroga la gestione degli elementi di lavoro per determinare se l'elemento di lavoro supporta tale azione e, in tale caso, richiede gli stati di origine e di destinazione della transizione. Se l'azione viene individuata, il sistema di controllo del codice sorgente può eseguire la transizione dell'elemento di lavoro in base alla transizione impostata durante l'archiviazione del codice.

Nota

Quando si utilizza l'azione Checkin, è necessario impostare gli stati "from" e "to" appropriati per riflettere la transizione di stato desiderata.

Per ulteriori informazioni sulle azioni, vedere Associazione di una transizione di stato a un'azione e Informazioni dettagliate sulle azioni di transizione.

Esempio dell'azione Checkin

<TRANSITION from="Active" to="Resolved">
....
    <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
    </ACTIONS>
....  
</TRANSITION>

Vedere anche

Condividi tramite