Automatizar las asignaciones de campo en función del estado, la transición o la razón

Tal vez desee automatizar la transición de elementos de trabajo de un estado a otro en función de los eventos que tienen lugar en Visual Studio Application Lifecycle Management (ALM) o fuera de Visual Studio ALM. Por ejemplo, tal vez desee automatizar la transición de elementos de trabajo de un estado a otro en función de lo que ocurre en una herramienta de seguimiento de llamadas. El modelo del tipo de elemento de trabajo y la API de Seguimiento de elementos de trabajo se amplían para admitir la automatización de transiciones de elementos de trabajo por otros sistemas.

Si tiene código que cambia el estado de un elemento de trabajo, puede generalizarlo asociando la acción con el estado de transición adecuado mediante el elemento ACTION. Puede pasar el valor de la acción al método [WorkItem.GetNextState] para obtener el estado posterior a la acción de ese elemento de trabajo. El cuadro de diálogo de protección de control de versiones emplea este método para resolver errores y cerrar tareas asociadas con la protección.

ACTION es un elemento secundario opcional de ACTIONS.

Por ejemplo, se establece una herramienta para que automatice la transición de un elemento de trabajo a "Resolved" una vez que el usuario ha protegido un cambio. Sin embargo, como proveedor de la integración, usted no sabe qué estado ha establecido como "Resolved" el creador del tipo de elemento de trabajo. El creador puede querer decir Resuelto, Cerrado, Completado, Listo para pruebas, Incluir en compilación, etc. Una opción sería requerir a todos los creadores del tipo de elemento de trabajo que incluyeran explícitamente un estado denominado "Resolved".

Esa solución es demasiado restrictiva. También resulta pobre desde una perspectiva internacional, porque no permite la traducción de estados. En su lugar, los integradores de sistemas pueden declarar una acción como "Check-in" o "Complete" que induce a una transición automática de los elementos de trabajo. El creador del tipo de elemento de trabajo declararía después esta acción en la transición adecuada.

En este tema

• Sintaxis de ACTION (elemento)

• Pasos obligatorios para la compatibilidad con la automatización

• Asociar una transición de estado con una acción

• Detalles de la acción de transición

• Comprobación de errores de transición automática

Sintaxis de ACTION (elemento)

La sintaxis siguiente se usa para el elemento ACTION. El valor del atributo especifica el nombre de la acción y es obligatorio. Debe seguir las mismas convenciones de nombres para las acciones que para los nombres de referencia de los campos. Por ejemplo, control de versiones de Team Foundation utiliza Microsoft.VSTS.Actions.CheckIn para identificar la transición adecuada para los elementos de trabajo asociados a la protección. Para obtener más información, vea Convenciones de nomenclatura para objetos de seguimiento de elementos de trabajo.

<ACTION value="NameOfAction" />

minOccurs="0"

maxOccurs="unbounded"

Pasos obligatorios para la compatibilidad con la automatización

Para integrar una herramienta en el Seguimiento de elementos de trabajo, la herramienta debe realizar los pasos siguientes:

1. Determine a qué estado debería cambiar el elemento de trabajo cuando se realiza la acción.

2. Establezca el elemento de trabajo en estado "to".

   La API del Seguimiento de elementos de trabajo proporciona los métodos para realizar estos pasos. La API del Seguimiento de elementos de trabajo forma parte del SDK de Visual Studio ALM. Para obtener más información, vea la página siguiente en el sitio web de Microsoft: Extending Team Foundation.

   Nota

   No se registra la acción de la transacción que provocó una transición de estado determinada. Si tiene que realizar el seguimiento de la acción que causa la transición, especifique un campo de elemento de trabajo adicional o bien defina un valor para Reason.

Volver al principio

Asociar una transición de estado con una acción

Se pueden utilizar las acciones de transición de estado para automatizar las transiciones de los elementos de trabajo en varios puntos del flujo de trabajo. Por ejemplo, un sistema de control de versiones de Team Foundation Server debe admitir transiciones automáticas de los elementos de trabajo en el momento de la protección. Para que haya compatibilidad, se ha definido una acción "microsoft.vsts.actions.checkin".

El autor del tipo del elemento de trabajo puede definir un tipo de elemento de trabajo "Defect" que tenga un estado denominado "Working" y utilizar ese elemento de trabajo cuando el desarrollador está realizando cambios. El autor del tipo del elemento de trabajo puede definir otro estado denominado "Ready To Build", lo que significa que el desarrollador ha declarado que el código que estaba afectado por el defecto está listo para la generación nocturna.

El autor puede realizar automáticamente una transición del elemento de trabajo del estado "Working" al estado "Ready To Build" durante una operación de protección declarando lo siguiente:

<TRANSITION from="Working" to="Ready To Build">
   <ACTIONS>
      <ACTION value="microsoft.vsts.actions.checkin"/>
   </ACTIONS>
</TRANSITION>

Volver al principio

Detalles de la acción de transición

Utilice las acciones de transición de estados para automatizar las transiciones de los elementos de trabajo en varios puntos del flujo de trabajo. Tenga en cuenta los detalles de uso siguientes sobre las acciones de transición:

• Las acciones de transición son opcionales. Si el estado actual de la instancia del elemento de trabajo tiene una entrada de acción para la acción especificada, vuelve al estado "to". En caso contrario, el valor devuelto es Null. Las integraciones deberían controlar sin problemas los valores Null devueltos, es decir:

  • Sin error.

  • Deja un seguimiento o registro que indica que la integración no realizó la transición automáticamente porque requería una acción no encontrada.

• Para cada tipo de elemento de trabajo, las acciones deben ser únicas para los pares de estado From/acción. Esto significa que los creadores del tipo de elemento de trabajo no pueden especificar varios estados "to" para la misma acción.

• Sin embargo, se admiten varias acciones en la misma transición para permitir diversas integraciones de transiciones automáticas, tal y como se muestra en el ejemplo siguiente:

  <TRANSITION from="Working" to="Ready To Build">
     <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
        <ACTION value="ADatum.Actions.Complete"/>
     </ACTIONS>
  </TRANSITION>
  

• Los nombres de acciones son nombres de programación en los que sólo se permite la utilización de caracteres ingleses.

• Los nombres de acciones deben seguir la misma convención de espacio de nombres de referencia que los nombres de referencia de campos para evitar conflictos de nombres de acciones entre proveedores y clientes. Sin embargo, la herramienta no aplica esta convención. Visual Studio ALM usa Microsoft.VSTS.Actions.<your action>.

Volver al principio

Comprobación de errores de transición automática

Los integradores pueden probar dos tipos de transiciones automáticas. El primero es una transición automática que se produce debido a una acción del usuario. El segundo es una transición automática que se produce por automatización desatendida, como una generación nocturna.

• Transiciones automáticas de la acción del usuario   Para este tipo de transición automática, un usuario está presente para reaccionar a cualquier problema relacionado con las reglas que se producen. Además, debe asegurarse de que se admite la situación que se produce cuando el autor de un tipo de elemento de trabajo agrega un campo obligatorio que no reconoce la integración. Para admitir esta situación, realice la transición automática y, a continuación, inspeccione el tipo de elemento de trabajo para las infracciones de la regla. Si encuentra alguna, se muestra el formulario para que el usuario la resuelva.

• Transiciones automáticas de automatización desatendidas   Debe suponer que ningún usuario está presente para resolver estos problemas. En este caso, se debería producir un error leve en la integración. Un registro de errores debería indicar que se probó la transición automática y debería proporcionar una razón para el error.

Al definir cualquier tipo de transición automática, se define la transición de modo que cada elemento de trabajo alcanza un estado válido al final de la transición sin necesidad de la intervención del usuario. Es decir, todas las reglas definidas para el estado objeto de la transición se cumplen al proporcionar valores predeterminados o copiados para todos los campos. Si cualquier campo se convierte en no válido después de la transición, se producirá un error en la transición de estado.

Para conservar los campos como no válidos, haga lo siguiente:

• Defina DEFAULTREASON para la transición de estado.

• Para los campos que se requerirán después de la transición de estado, especifique un valor usando la regla DEFAULT o COPY.

Por ejemplo, ha creado la acción de transición Protección, que realiza la transición del estado de un elemento de trabajo de "Trabajando" a "Preparado para compilar". Las reglas del elemento de trabajo para "Preparado para generar" requieren que se establezca el campo "Resuelto por". A continuación, hay que definir un elemento de regla DEFAULT o COPY para "ResolvedBy" en la sección TRANSITION. Además, debe definir DEFAULTREASON para asegurarse de que el campo obligatorio se puede establecer sin la intervención del usuario.

Volver al principio

Vea también

Conceptos

Cuándo y dónde aplicar una regla de campo

Associating a State Transition with an Action

Historial de cambios