Personalizar un proceso XML hospedado

Azure DevOps Services (XML hospedado)

Azure DevOps Services permite agregar y actualizar 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 si lo vuelve a importar. 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 uso de Team Foundation Server Database Import Service.

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 de Azure DevOps Services. Algunos bloques de creación actualizan los proyectos existentes, mientras que otros solo se aplican a proyectos nuevos. 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 nuevo proyecto

Reemplazado por valores predeterminados del sistema

Ignorado

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 Azure DevOps Services admite y lo que admite la Team Foundation Server local. Para obtener un resumen de estas diferencias, vea 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 la aplicación local Team Foundation Server, asegúrese de que se ajusta a las restricciones colocadasen las plantillas para importar .

Abrir Configuración > proceso

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

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

    Abrir configuración de la organización

  2. A continuación, elija Procesar.

    Página Configuración organización, Proceso

    Importante

    Si no ve Proceso, está trabajando desde TFS-2018 o una versión anterior. No se admite la página Proceso. Debe usar las características admitidas para 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.

    Página De procesos  Export Hosted XML process (Exportar proceso XML hospedado) opción de menú

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

  2. Cambie el nombre del proceso dentro ProcessTemplate.xml archivo 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 principal y menor. Proporcione un GUID distinto para el tipo como en este ejemplo:

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

  3. Aplique las personalizaciones admitidas.

  4. Cree un archivo ZIP de todos los archivos y carpetas del 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 resumida siguientes. De lo contrario, los mensajes de error de validación podrían aparecer al importarse.

Plantilla de proceso

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

  • Limita el número de WIT definidos a 64
  • Contiene solo un archivo Categories.xml definición de datos
  • Contiene solo un archivo ProcessConfiguration.xml definición de datos
  • 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 .exe archivos. 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 como máximo de 2 GB. De lo contrario, se produce un error en la creación del proyecto.

Configuración de proceso

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

  • Especifica todos los elementos TypeFields
  • Está limitado a cinco trabajo 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 a metaestado de flujo de trabajo necesarias y no hace referencia a metaestados no admitidos.

Categorías

El Categories.xml de definición debe cumplir la sintaxis y las reglas descritas en Categories XML element reference. 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 ProcessConfiguration.xml archivo

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 necesario asignados 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 los espacios de nombres no permitidos System. Name y Microsoft. Asigne el 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 que se ajusta 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 DE CAMPO. Además, debe cumplir las condiciones siguientes:

  • El nombre descriptivo y el atributo refname necesario asignados 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 los espacios de nombres no permitidos System. Name y Microsoft. Asigne el 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 se limita 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 ALLOWEDVALUESo SUGGESTEDVALUES está limitado a 512 elementos LISTITEM.
  • Un campo está limitado a 1024 reglas.

Campos obligatorios

En el archivo de ProcessConfiguration.xml se especifican los siguientes campos:

  • Para todos los WIT de una categoría que define un trabajo pendiente de configuración de proceso, 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 un trabajo pendiente de cartera, especifique el campo usado para type=Effort .
  • Para todos los WIT de la categoría que define el elemento TaskBacklog, especifique:
    • Campo que se usa para type=RemainingWork .
    • Campo que se usa para type=Activity .
    • Regla ALLOWEDVALUES para el campo utilizado para .

Restricciones de reglas

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

  • Los elementos de regla de campo no pueden especificar los atributos para yno .
  • Los elementos FIELD no pueden contener los elementos de regla secundaria CANNOTLOSEVALUE,NOTSAMEAS,MATCHy PROHIBITEDVALUES.
  • Excepto para los campos siguientes, definiciones 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, ALLOWEXISTINGVALUEy VALIDUSER.
    • System.ChangedBy puede contener las reglas REQUIRED, DEFAULT, ALLOWEXISTINGVALUEy VALIDUSER.

Atributos y nombres coherentes

Dentro de un proceso o una colección de proyectos,el nombre , eltipo 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 que se usan para contener nombres de cuenta, usuario o grupo. Los siguientes campos principales del sistema están codificados de forma hard-code como campos de identidad:

  • Asignado a (System.AssignedTo)
  • Autorizado como (System.AuthorizedAs)
  • Modificado por (System.ChangedBy)
  • Creado por (System.CreatedBy)
  • Activated By (Microsoft.VSTS.Common.ActivatedBy)
  • Closed By (Microsoft.VSTS.Common.ClosedBy)
  • Resolved By (Microsoft.VSTS.Common.ResolvedBy)
Agregar un campo de identidad personalizado

Un campo de cadena se reconoce como un 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 reglas siguientes dentro de una definición FIELD.

  • SUGGESTEDVALUES
  • Reglas que contienen valores de no identificación.
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 el proceso actualiza.

Ejemplo incorrecto

El ejemplo siguiente no es válido porque especifica:

  • Elemento ALLOWEDVALUES.
  • Elemento DEFAULT que especifica la cadena de no identificación value="Not Assigned" .
    <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 DE FLUJO DE TRABAJO. 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 metaestados 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 "Completo".

Para obtener una descripción de la categoría de estado y las asignaciones, vea 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.
  • Se pueden definir aproximadamente 10 000 elementos en total entre todas las listas globales que se especifican en todos los WIT.

Diseño de formulario

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

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