Personalizar un proceso XML hospedado

  • Artículo

Azure DevOps Services

Azure DevOps Services admite la adición y actualización de procesos a través de una experiencia administrativa que es un proceso de importación basado en web. Después de agregar un proceso, puede crear uno o varios proyectos a partir de él. Puede actualizar el proceso en cualquier momento importándolo de nuevo. Los cambios realizados en la plantilla de proceso se aplican a todos los proyectos que usan el proceso.

Importante

Con el modelo de proceso XML hospedado, puede personalizar el seguimiento del trabajo actualizando los archivos de definición XML seleccionados de una plantilla de proceso. Esta característica solo está disponible cuando los datos se migran a Azure DevOps Services mediante el servicio de importación de bases de datos de Team Foundation Server.

Para más información sobre la personalización y los modelos de proceso, consulte Personalización del seguimiento del trabajo.

Un proceso es un archivo ZIP que contiene un conjunto de archivos interdependientes. Estos archivos definen los bloques de creación del sistema de seguimiento de elementos de trabajo y otros subsistemas en Azure DevOps Services. Algunos bloques de creación actualizan los proyectos existentes, mientras que otros solo se aplican a nuevos proyectos. Consulte la tabla siguiente para obtener la lista completa de bloques de creación.

Se usa al importar o actualizar un proceso

Se usa al crear un proyecto

Reemplazado por los valores predeterminados del sistema

Omitido

Seguimiento de elemento de trabajo

Ingenio

Categorías

Configuración del proceso

Áreas e iteraciones

Administración de pruebas

Elementos de trabajo

Consultas de elementos de trabajo

Build

Lab Management

Control de versiones

Asignaciones de Microsoft Project

Informes

Portal (Productos de SharePoint)

Complementos y objetos de proceso admitidos para la importación de procesos

Hay diferencias entre lo que admite Azure DevOps Services y qué admite Team Foundation Server local. Para obtener un resumen de estas diferencias, consulte Diferencias de personalizaciones de plantillas de proceso.

Personalización de un proceso

Al personalizar un proceso, comenzar con un proceso bien definido es más fácil que crear uno nuevo.

Si actualiza un proceso existente que ha usado con Team Foundation Server local, asegúrese de que se ajusta a las restricciones colocadas en las plantillas para la importación.

Abrir Configuración>Proceso

Puede crear, administrar y realizar personalizaciones en los procesos en Configuración de la organización>Proceso.

  1. Elija el logotipo de Azure DevOps para abrir Proyectos. Luego, elija Configuración de la organización.

    Apertura de Configuración de la organización

  2. A continuación, elija Proceso.

    Configuración de la organización, página Proceso

    Importante

    Si no ve la opción Proceso, es que está trabajando desde TFS-2018 o una versión anterior. Si este es el caso, la página Proceso no se admite. Debe usar las características compatibles con el modelo de proceso XML local.

Exportación e importación de un proceso

  1. En la pestaña Procesos , seleccione los puntos suspensivos (...) para abrir el menú contextual del proceso XML hospedado que desea exportar. Solo puede exportar procesos XML hospedados.

    Opción de menú Exportar proceso XML hospedado en la página > Proceso

    Guarde el archivo ZIP y extraiga todos los archivos de él.

  2. Cambie el nombre del proceso en el archivo ProcessTemplate.xml ubicado en el directorio raíz.

    Asigne un nombre al proceso para distinguirlo de los existentes.

    <name>MyCompany Agile Process </name>

    Cambie el tipo de versión y cambie los números principales y secundarios. Proporcione un GUID distinto para el tipo como en este ejemplo:

    <version type="F50EFC58-C2FC-4C66-9814-E395D90778A3" major="1" minor="1"/>

  3. Aplicar personalizaciones admitidas.

  4. Cree un archivo ZIP de todos los archivos y carpetas en el directorio raíz.

  5. Importe el archivo ZIP del proceso personalizado.

Personalizaciones compatibles

Puede aplicar las siguientes personalizaciones al proceso:

En la sección siguiente se enumeran las limitaciones que impone el sistema.

Restricciones

Puede importar hasta 32 procesos en Azure DevOps Services. Los procesos personalizados deben cumplir todas las reglas resumidas siguientes. De lo contrario, es posible que aparezcan mensajes de error de validación al importar.

Plantilla de proceso

El archivo ProcessTemplate.xml debe cumplir la sintaxis y las reglas descritas en Referencia de elementos XML ProcessTemplate. Además, debe cumplir las siguientes condiciones:

  • Limita el número de WIT definidos a 64.
  • Contiene solo un archivo de definición de Categories.xml
  • Contiene solo un archivo de definición de ProcessConfiguration.xml
  • Usa nombres descriptivos únicos en todos los campos y definiciones de WIT

Además, el proceso debe pasar las siguientes comprobaciones de validación:

  • Los nombres de proceso son únicos y contienen como máximo 155 caracteres Unicode.
    • Una plantilla con el mismo nombre y GUID de versión que un proceso existente sobrescribe ese proceso.
    • Una plantilla con el mismo nombre, pero un GUID de versión diferente genera un error.
    • Los nombres de proceso no pueden contener los siguientes caracteres especiales: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Consulte Restricciones de nomenclatura para obtener restricciones adicionales.
  • Las carpetas de proceso no contienen archivos .exe. Incluso si puede importar un proceso que contiene un archivo .exe, se produce un error en la creación del proyecto.
  • El tamaño total del proceso es de 2 GB como máximo. De lo contrario, se produce un error en la creación del proyecto.

Configuración de proceso

El archivo de definición de ProcessConfiguration.xml debe cumplir la sintaxis y las reglas descritas en La referencia del elemento XML ProcessConfiguration. Además, debe cumplir las condiciones siguientes:

  • Especifica todos los elementos TypeFields
  • Se limita a cinco trabajos pendientes de cartera
  • Contiene solo un trabajo pendiente de cartera no primario.
  • Especifica solo un trabajo pendiente de cartera principal para cada trabajo pendiente de cartera subordinada.
  • Contiene las asignaciones de estado de metastate de flujo de trabajo necesarias y no hace referencia a los metastates no admitidos.

Categorías

El archivo de definición de Categories.xml debe cumplir la sintaxis y las reglas descritas en Referencia de elementos XML categories. Además, debe cumplir las condiciones siguientes:

  • Está limitado a 32 categorías
  • Define todas las categorías a las que se hace referencia en el archivo ProcessConfiguration.xml

Tipos de elemento de trabajo

Un elemento WITD y sus elementos secundarios deben cumplir la sintaxis y las reglas descritas en referencia de elementos XML de WITD. Además, debe cumplir las condiciones siguientes:

  • Hay como máximo 512 campos dentro de un único WIT y 512 campos en todos los WIT.
  • El nombre descriptivo y el atributo refname requerido asignado a un WIT son únicos dentro del conjunto de archivos de definición de WIT.
  • El valor de atributo refname necesario no contiene caracteres no permitidos ni usa el sistema de espacios de nombres no permitidos. Nombre y Microsoft. Nombre.
  • Los nombres de referencia contienen al menos un punto (.) y todos los demás caracteres son letras sin espacios.
  • El elemento WITD contiene un elemento FORM que define un elemento WebLayout conforme a la sintaxis especificada en los elementos WebLayout y Control.

Campos de elementos de trabajo

Un elemento FIELDS y sus elementos secundarios deben cumplir la sintaxis y las reglas descritas en referencia de elementos XML FIELD. Además, debe cumplir las condiciones siguientes:

  • El nombre descriptivo y el atributo refname requerido asignado a un WIT son únicos dentro del conjunto de archivos de definición de WIT.
  • El valor de atributo refname necesario no contiene caracteres no permitidos ni usa el sistema de espacios de nombres no permitidos. Nombre y Microsoft. Nombre.
  • Los nombres de referencia contienen al menos un punto (.) y todos los demás caracteres son letras sin espacios.

Un elemento FIELD y sus elementos secundarios pueden contener un elemento GLOBALLIST .

Restricciones de límite

  • Un elemento FIELDS está limitado a 512 campos.
  • Un tipo de elemento de trabajo está limitado a 64 campos de nombre de persona. Un campo de nombre de persona es uno con el atributo y el valor syncnamechanges=true.
  • Un elemento ALLOWEDVALUES o SUGGESTEDVALUES está limitado a 512 elementos LISTITEM .
  • Un campo está limitado a 1024 reglas.

Campos obligatorios

Los siguientes campos se especifican en el archivo ProcessConfiguration.xml:

  • Para todas las WIT de una categoría que define un trabajo pendiente de configuración de procesos, especifique los campos usados para los atributos y valores type=Team y type=Order.
  • Para todos los WIT de una categoría que define un trabajo pendiente normal o trabajo pendiente de cartera, especifique el campo usado para type=Effort.
  • Para todas las WIT de la categoría que define el elemento TaskBacklog , especifique:
    • Campo utilizado para type=RemainingWork.
    • Campo utilizado para type=Activity.
    • Regla ALLOWEDVALUES para el campo utilizado para type=Activity.

Restricciones de reglas

Además de las restricciones de reglas de campo estándar, se aplican las siguientes restricciones:

  • Los elementos de regla de campo no pueden especificar para yno atributos.
  • Los elementos FIELD no pueden contener los elementos de regla secundaria CANNOTLOSEVALUE, NOTSAMEAS, MATCH y PROHIBITEDVALUES.
  • Excepto en los siguientes campos, definiciones de FIELD para System. Los campos de nombre no pueden contener reglas de campo.
    • System.Title puede contener las reglas REQUIRED y DEFAULT.
    • System.Description puede contener las reglas REQUIRED y DEFAULT.
    • System.AssignedTo puede contener las reglas REQUIRED, DEFAULT, ALLOWEXISTINGVALUE y VALIDUSER.
    • System.ChangedBy puede contener las reglas REQUIRED, DEFAULT, ALLOWEXISTINGVALUE y VALIDUSER.

Nombres y atributos coherentes

Dentro de un proceso o una colección de proyectos, el nombre, el tipo y otros atributos que define un elemento FIELD deben ser los mismos en todas las definiciones de WIT.

Identity (campos)

Los campos de identidad corresponden a los campos usados para contener nombres de cuenta, usuario o grupo. Los siguientes campos principales del sistema están codificados de forma rígida como campos de identidad:

  • Asignado a (System.AssignedTo)
  • Autorizado como (System.AuthorizedAs)
  • Modificado por (System.ChangedBy)
  • Creado por (System.CreatedBy)
  • Activado por (Microsoft.VSTS.Common.ActivatedBy)
  • Cerrado por (Microsoft.VSTS.Common.ClosedBy)
  • Resuelto por (Microsoft.VSTS.Common.ResolvedBy)
Adición de un campo de identidad personalizada

Un campo de cadena se reconoce como campo de identidad cuando se especifica el atributo syncnamechanges como True.

Restricciones de reglas en campos de identidad

Para la versión actual de la importación de procesos, no especifique ninguna de las siguientes reglas dentro de una definición FIELD .

  • SUGGESTEDVALUES
  • Reglas que contienen valores de no identidad.
Ejemplo correcto

Para limitar los nombres de cuenta que son válidos dentro de un campo de identidad, especifique el VALIDUSER elemento con un atributo de nombre de grupo.

    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <VALIDUSER group="[PROJECT]\Program Manager Group" />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Antes de importar el proceso, asegúrese de que ha creado el grupo en los proyectos que actualiza el proceso.

Ejemplo incorrecto

El ejemplo siguiente no es válido porque especifica:

  • Elemento ALLOWEDVALUES.
  • Elemento DEFAULT que especifica la cadena value="Not Assigned"noidentidad .
    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <ALLOWEDVALUES>
          <LISTITEM value="[PROJECT]\Program Manager Group" />
          <LISTITEM value="Not Assigned" />
        </ALLOWEDVALUES>
        <DEFAULT from="value" value="Not Assigned" />
        <VALIDUSER />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Flujo de trabajo

Un elemento WORKFLOW y sus elementos secundarios deben cumplir la sintaxis y las reglas descritas en referencia de elementos XML workflow. Además, debe cumplir las condiciones siguientes:

  • Limita cada WIT a 16 estados de flujo de trabajo
  • Define todos los estados de flujo de trabajo asignados a metastates en el archivo de definición ProcessConfiguration.
  • Define una transición entre todos los estados de flujo de trabajo asignados a la categoría de estado "Propuesto" y los estados de flujo de trabajo asignados a la categoría de estado "InProgress"
  • Define una transición entre todos los estados de flujo de trabajo asignados a la categoría de estado "InProgress" y los estados de flujo de trabajo asignados a la categoría de estado "Completa".

Para obtener una descripción de la categoría de estado y las asignaciones, consulte Estados de flujo de trabajo y categorías de estado.

Listas globales

Para el modelo de proceso XML hospedado, los límites siguientes se colocan en la importación de lista global:

  • Hay como máximo 64 listas globales.
  • Hay como máximo 512 elementos por lista.
  • Aproximadamente 10 000 elementos se pueden definir en total entre todas las listas globales que se especifican en todas las WIT.

Diseño de formulario

Un elemento FORM y sus elementos secundarios deben cumplir la sintaxis y las reglas descritas en la referencia de elementos FORM XML.

Un elemento Control no puede especificar un control personalizado. No se admiten controles personalizados.