Automatizar transiciones de estado

Artículo
10/07/2008

Actualización: noviembre 2007

Es posible que los clientes y los socios quieran automatizar la transición de elementos de trabajo de un estado a otro en función de los eventos que tienen lugar en Microsoft Visual Studio Team System o de eventos que tienen lugar fuera de Microsoft Visual Studio Team System, por ejemplo, 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.

Nota:
La API de Seguimiento de elementos de trabajo forma parte del SDK de Visual Studio Team System en el sitio web de Microsoft.

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, Finalizado, Listo para pruebas, Incluir en generación, etc. Una opción sería requerir a todos los creadores del tipo de elemento de trabajo incluyeran explícitamente un estado denominado "Resolved".

Esa solución es demasiado restrictiva y 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.