Automatizar las asignaciones de campo en función del estado, la transición o el motivo
Puede que quiera transicionar automáticamente los elementos de trabajo de un estado a otro basándose en un evento que ocurra en otro lugar de Visual Studio Application Lifecycle Management (ALM) o en un evento que suceda fuera de Visual Studio ALM. Por ejemplo, puede automatizar la transición de un error de un estado a otro basándose en lo que ocurre en una herramienta de seguimiento de llamadas. El modelo de tipos de elemento de trabajo y la API de seguimiento de elementos de trabajo se amplían para admitir la transición automática de los elementos de trabajo por parte de otros sistemas.
Si tiene código que cambia el estado de un elemento de trabajo, puede generalizar este código asociando su acción con la transición de estado adecuada usando el elemento ACTION. Puede pasar el valor de su acción al método [WorkItem.GetNextState] para obtener el estado posterior a la acción de ese elemento de trabajo. En el cuadro de diálogo de protección del control de versiones se usa este método para resolver errores y cerrar tareas que están asociadas con la protección.
ACTION es un elemento secundario opcional de ACTIONS.
Nota
La API de seguimiento de elementos de trabajo forma parte del SDK de Visual Studio ALM, tal como se describe en la siguiente página del sitio web de Microsoft: Ampliar Team Foundation.
Por ejemplo, una herramienta se preestablece para que haga la transición automática de un elemento de trabajo al estado "Resuelto" cuando el usuario protege un cambio. Sin embargo, como proveedor de integraciones, usted no sabe cuál es el estado que el autor del tipo de elemento de trabajo ha declarado como "Resuelto". El autor pudo haber querido decir Resuelto, Cerrado, Completado, Listo para las pruebas, Incluir en compilación, etc. Una opción sería exigir a todos los autores de tipos de elemento de trabajo que incluyesen un estado explícitamente llamado "Resuelto".
Esta solución es demasiado restrictiva. También limita un poco desde una perspectiva internacional, ya que no permite la localización de estados. Lo que pueden hacer los integradores de sistemas es declarar una acción como "Proteger" o "Completar" que induzca una transición automática para los elementos de trabajo. Así, el autor del tipo de elemento de trabajo declararía esta acción en la transición correspondiente.
En este tema
Sintaxis del elemento ACTION
Pasos necesarios para admitir 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 del elemento ACTION
La sintaxis siguiente se usa para el elemento ACTION. El atributo de valor especifica el nombre de la acción y es obligatorio. Para las acciones debe seguir las mismas convenciones de nomenclatura que para los nombres de referencia de campo. Por ejemplo, control de versiones de Team Foundation usa Microsoft.VSTS.Actions.CheckIn para identificar la transición que es apropiada para los elementos de trabajo asociados con la protección. Para obtener más información, consulta Convenciones de nomenclatura para objetos de seguimiento de elementos de trabajo.
<ACTION value="NameOfAction" />
minOccurs="0"
maxOccurs="unbounded"
Pasos necesarios para admitir la automatización
Para integrar una herramienta con el seguimiento de elementos de trabajo, la herramienta debe hacer los pasos siguientes:
Determinar a qué estado debe transicionar el elemento de trabajo cuando se lleva a cabo la acción.
Establecer el elemento de trabajo en el estado "a".
La API de seguimiento de elementos de trabajo ofrece métodos para realizar estos pasos. La API de seguimiento de elementos de trabajo forma parte del SDK de Visual Studio ALM. Para más información, vea la siguiente página del sitio web de Microsoft: SDK de Team Foundation Server.
Nota
La acción de transacción que desencadenó una transición de estado determinada no se registra.Si tiene que registrar qué acción causó una transición, puede especificar un campo de elemento de trabajo adicional para que quede constancia o puede definir un valor Motivo.
Volver al principio
Asociar una transición de estado con una acción
Puede usar acciones de transición de estado para automatizar transiciones de 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 elementos de trabajo en el momento de la protección. Para que sea posible, se ha definido la acción "microsoft.vsts.actions.checkin".
Un autor de tipos de elemento de trabajo puede definir un tipo de elemento de trabajo "Defecto" que tenga un estado llamado "Trabajando" y usar este elemento de trabajo cuando un desarrollador esté haciendo cambios. El autor de tipos de elemento de trabajo puede definir otro estado llamado "Listo para la compilación", que significa que el desarrollador ha declarado que el código afectado por el defecto está listo para la compilación nocturna.
El autor puede transicionar automáticamente el elemento de trabajo del estado "Trabajando" al estado "Listo para la compilación" 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
Use acciones de transición de estado para automatizar transiciones de elementos de trabajo en varios puntos del flujo de trabajo. Tenga en cuenta los siguientes detalles de uso 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, devuelve el estado "a". Si no, devuelve el valor NULL. Las integraciones deben tratar los valores NULL devueltos eficazmente. Es decir:
No hay que generar errores.
Deje un seguimiento o un registro que indique que la integración no hizo la transición automática porque requería una acción que no se encontró.
Para cada tipo de elemento de trabajo, las acciones deben ser únicas para los pares Del estado/Acción. Esto significa que los autores de tipos de elemento de trabajo no pueden especificar varios estados "a" en la misma acción.
Sin embargo, se admiten varias acciones en la misma transición para permitir varias integraciones de transición automática, tal como se ve 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 acción son nombres de programación para los que solo se pueden usar caracteres ingleses.
Los nombres de acción deben seguir la misma convención de espacio de nombres de referencia que los nombres de referencia de campo para evitar conflictos de nombre entre proveedores y clientes. Sin embargo, esta convención no la exige la herramienta. Visual Studio ALM usa Microsoft.VSTS.Actions.<your action>.
Comprobación de errores de transición automática
Los integradores pueden probar dos tipos de transiciones automáticas. La primera es una transición automática que ocurre por una acción del usuario. La segunda ocurre por una automatización desatendida, como una compilación nocturna.
Transiciones automáticas de acción del usuario: en este tipo de transición automática, existe un usuario que reacciona ante los problemas relacionados con reglas que surjan. Debe asegurarse de admitir la situación que se produzca cuando el autor de un tipo de elemento de trabajo agregue un campo necesario que la integración no reconozca. Para admitir esta situación, haga la transición automática y luego inspeccione el tipo de elemento de trabajo para ver si infringe alguna regla. Si encuentra alguna infracción, muestre el formulario para que el usuario la resuelva.
Transiciones automáticas de automatización desatendida: debe suponer que no hay ningún usuario para resolver estos problemas. En este caso, la integración debe generar un error. Un registro de error debe indicar que se intentó hacer la transición automática, así como dar el motivo del error.
Al definir uno de los dos tipos de transición automática, defina la transición de modo que cada elemento de trabajo alcance un estado válido al final de la transición sin requerir la intervención del usuario. En otras palabras, todas las reglas que se definen para el estado al que se va a transicionar se cumplen proporcionando valores predeterminados o copiados para todos los campos. Si algún campo deja de ser válido después de la transición, la transición de estado dará error.
Para evitar que estos campos se invaliden, haga lo siguiente:
Defina un DEFAULTREASON para la transición de estado.
Para los campos que serían necesarios después de la transición de estado, use los elementos de regla DEFAULT o COPY para especificar un valor para el campo.
Por ejemplo, ha creado la acción de transición Proteger, que transiciona el estado de un elemento de trabajo de "Trabajando" a "Listo para la compilación". Las reglas de elemento de trabajo para "Listo para la compilación" requieren que el campo "Resuelto por" esté establecido. Tendría que definir un elemento de regla DEFAULT o COPY para "Resuelto por" en la sección TRANSITION. Además, tendría que definir un DEFAULTREASON para asegurarse de que el campo necesario se pueda establecer sin la intervención del usuario.