Campi che supportano l'integrazione con il test, la compilazione e il controllo della versione

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

Campi che si integrano con Team Foundation Build

Team Foundation Build è il sistema di compilazione automatica di Team Foundation Server. Il processo di compilazione può essere configurato tramite Team Foundation Build, in modo che Team Foundation Build possa generare elementi di lavoro in caso di errore durante la compilazione. È anche possibile aggiungere informazioni sulla build agli elementi di lavoro risolti in una determinata build. Affinché questa procedura funzioni, Team Foundation Build richiede che i due campi Found In e Integration Build siano aggiunti alla definizione del tipo di elemento di lavoro.

Nei modelli di processo predefiniti disponibili in Team Foundation Server, nelle definizioni dei tipi per i bug sono presenti i campi Found In e Integrated in Build. Questi campi associano i bug alle compilazioni in cui vengono trovati o corretti. È possibile usare il frammento di codice seguente per aggiungere questi campi a una definizione del tipo di elemento di lavoro.

<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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Quando il campo Found In è presente nella definizione di un tipo di elemento di lavoro, Team Foundation Build crea un elemento di lavoro quando si verifica un errore di compilazione e imposta il campo Found In sul numero della build in cui si è verificato il problema. Se il campo Found In non è presente, Team Foundation Build non crea un elemento di lavoro per la build in cui si è verificato l'errore e tutto il resto funziona come previsto.

Quando il campo Integration Build è presente nella definizione del tipo di elemento di lavoro, Team Foundation Build identifica gli elementi di lavoro risolti con ogni compilazione e quindi li aggiorna in modo da impostare il numero della build in cui sono stati risolti nel campo Integration Build. Se il campo Integration Build non è presente, Team Foundation Build non memorizza il numero della build negli elementi di lavoro e tutto il resto funziona come previsto.

Associazioni della build con gli insiemi di modifiche e gli elementi di lavoro

Una build standard basata sul modello di build predefinito associa gli insiemi di modifiche e gli elementi di lavoro alle build. Questa operazione viene eseguita recuperando prima l'etichetta della build corretta precedente per la definizione della build in questione e quindi determinando gli insiemi di modifiche inclusi nella build corrente e non presenti in quella precedente. Alcuni o tutti gli insiemi di modifiche potrebbero contenere elementi di lavoro associati, che verranno di conseguenza associati alla build. Questa operazione fa parte dell'attività AssociateChangesetsAndWorkItems.

Build e popolamento automatico dell'elenco globale

La prima volta che si inserisce in coda una build per un progetto team con Team Foundation Build, viene aggiunto automaticamente un elenco globale denominato "Build - <nome progetto team>". Ogni volta che viene eseguita una compilazione, viene aggiunto un elemento LISTITEM all'elenco globale con il nome della build.

Aggiungendo un elemento GLOBALLIST alla definizione FIELD, è possibile fornire un elenco a discesa delle build che gli utenti potranno selezionare. Ad esempio:

<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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

Campi che si integrano con Microsoft Test Manager

Con Test Manager, è possibile automatizzare la creazione di un bug o di un altro tipo di elemento di lavoro quando un test ha esito negativo. Per altre informazioni, vedere Invio di bug in Microsoft Test Manager.

Quando un elemento di lavoro viene creato in questo modo, le informazioni sul sistema e i passaggi per riprodurre il bug vengono acquisiti nei campi System Info e Repro Steps.

È possibile aggiungere questi campi ai tipi di elemento di lavoro creati per tenere traccia degli errori tramite il frammento di codice seguente.

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Per altre informazioni sugli altri campi usati da Test Manager, vedere Riferimento ai campi Integrare test e compilare.

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 quando si archivia il codice. È possibile lavorare su un determinato elemento di lavoro e apportare una modifica al codice, quindi impostare tale associazione dalla finestra di archiviazione del controllo del codice sorgente al termine delle operazioni di modifica.

Affinché Controllo della versione di Team Foundation possa risolvere un elemento di lavoro è necessario che gli elementi di lavoro contengano una determinata azione. Il sistema di controllo del codice sorgente esegue quindi una query nei dati di verifica dell'elemento di lavoro per determinare se l'elemento di lavoro supporta l'azione. In caso affermativo, esegue anche una query sullo stato dell'origine e della destinazione della transizione. Se l'azione viene trovata, il sistema di controllo del codice sorgente può eseguire la transizione dell'elemento di lavoro in base alla transizione impostata quando esegue l'archiviazione del codice.

Nota

Se si usa l'azione Checkin, è necessario impostare gli stati iniziale e finale in modo appropriato in modo che riflettano la transizione di stato desiderata.

Per altre informazioni sulle azioni, vedere Rendere automatiche le assegnazioni dei campi in base a stato, transizione o motivo.

Esempio di azione Checkin

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

Domande e risposte

D: Quali altri campi sono associati alle build e a Test Manager?

A: Vedere Riferimento ai campi Integrare test e compilare per campi aggiuntivi,

Vedere anche

Attività

Sviluppi applicati da una compilazione precedente

Altre risorse

Modificare o aggiungere un campo per supportare query, report e flusso di lavoro