Agregar campos de integración a tipos de elementos de trabajo

Artículo
08/10/2011

Puede personalizar los tipos de elemento de trabajo para que contengan la información generada por los procesos automatizados agregando campos que se integran con Team Foundation Build, Microsoft Test Manager y control de versiones de Team Foundation.

En este tema

Campos que se integran con Team Build
Campos que se integran con Visual Studio Test Tools
Campos que se integran con el control de código fuente de Team Foundation

Campos que se integran con Team Foundation Build

Team Foundation Build es el sistema de generación automatizado de Team Foundation Server. Puede configurar su proceso de compilación mediante Team Foundation Build. Team Foundation Build puede generar elementos de trabajo cuando se produce un error de compilación y también puede agregar información de compilación a los elementos de trabajo que se resolvieron en una compilación concreta. Para que esto funcione, Team Foundation Build requiere los dos campos siguientes: Found In e Integration Build.

Agregar el campo Encontrado en

Team Foundation Build crea un nuevo elemento de trabajo cuando se produce un error de compilación y establece el campo Found In en el número de la compilación en la que se ha producido el error. El campo Found In debe estar presente en el tipo de elemento de trabajo que desea que Team Foundation Build cree cuando se produce un error en una generación. Si falta el campo Found In, Team Foundation Build no crea el elemento de trabajo para la generación en la que se ha producido el error y todo lo demás funciona de la forma esperada.

En la tabla siguiente se resumen los nombres y valores de los atributos del campo Found In.

Nombre del atributo	Valor del atributo
RefName	Microsoft.VSTS.Build.FoundIn
Name	Se puede establecer en cualquier valor porque las integraciones se basan en los nombres de referencia de campo, no en los nombres de los campos.
Tipo	Cadena

Ejemplo del campo Encontrado en

<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>

Agregar el campo Integración de generación

Team Foundation Build identifica los elementos de trabajo que se resolvieron en cada generación y, a continuación, actualiza esos elementos para establecer el número de la generación en la que se resolvieron. Establece el número de compilación en el campo Integration Build. Si falta el campo Integration Build, Team Foundation Build no almacena el número de compilación en los elementos de trabajo y todo lo demás funciona de la forma esperada.

En la tabla siguiente se resumen los nombres y valores de los atributos del campo Integration Build.

Nombre del atributo	Valor del atributo
RefName	Microsoft.VSTS.Build.IntegrationBuild
Nombre	Se puede establecer en cualquier valor porque las integraciones se basan en los nombres de referencia de campo, no en los nombres de los campos.
Tipo	Cadena

Ejemplo del campo Integración de generación

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

Campos que se integran con Visual Studio Test Tools

Algunas ediciones de Visual Studio incluyen herramientas de prueba que se integran en el entorno de desarrollo. Una característica disponible de las herramientas de prueba es la capacidad de crear elementos de trabajo cuando se produce un error en una prueba. Para ello, en la ventana Resultados de pruebas, haga clic con el botón secundario en el resultado de la prueba para la que desea crear un error, seleccione Crear elemento de trabajo y, a continuación, haga clic en el tipo de elemento de trabajo que desea crear, como, por ejemplo, Error. Para obtener más información, vea How to: Create a Work Item from a Test Result.

Cuando un elemento de trabajo se ha creado de esta forma, se rellenan automáticamente tres campos para proporcionar información sobre el error de las pruebas. Los tres campos son TestName, TestId y TestPath. Test Manager establece estos tres campos con información concreta sobre la prueba en la que se produjo un error. Si faltan los campos TestName, TestId y TestPath del elemento de trabajo, los campos no se establecen y todo lo demás funciona de la forma esperada.

En la tabla siguiente hay un resumen de los nombres y valores de los atributos de estos tres campos.

Nombre del atributo	Valor del atributo
RefName	Microsoft.VSTS.Test.TestName, Microsoft.VSTS.Test.TestId, Microsoft.VSTS.Test.TestPath
Nombre	Se puede establecer en cualquier valor porque las integraciones se basan en los nombres de referencia de campo, no en los nombres de los campos.
Tipo	String

Ejemplo de los campos TestName, TestId y 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>

Campos que se integran con el control de versiones de Team Foundation

Una de las características disponibles en control de versiones de Team Foundation permite asociar o resolver los elementos de trabajo cuando se protege el código. Quizá haya trabajado en un elemento de trabajo concreto al realizar una modificación de código determinada y puede establecer esa asociación en la ventana de protección de control de código fuente cuando termine de trabajar en el código.

La capacidad de control de versiones de Team Foundation para resolver un elemento de trabajo requiere que los elementos de trabajo contengan una acción determinada. El sistema de control de código fuente consulta a continuación el seguimiento del elemento de trabajo para determinar si el elemento de trabajo admite esa acción, y en caso afirmativo, también consulta los estados de origen y destino de la transición. Si se encuentra la acción, el sistema de control de código fuente puede realizar la transición del elemento de trabajo de acuerdo con la transición establecida cuando protege el código.

Nota

Cuando utiliza la acción Checkin, debe establecer los estados 'from' y 'to' apropiados para reflejar la transición de estado que desea.

Para obtener más información acerca de las acciones, vea Associating a State Transition with an Action y Transition Action Details.

Ejemplo de la acción de protección

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

Vea también

Compartir a través de