Personalizar un proceso XML hospedado
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 mediante la actualización de 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 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 valores predeterminados del sistema
Ignorado
Seguimiento de elemento de trabajo
Ingenio
Categorías
Configuración de procesos
Á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)
Hay diferencias entre lo que admite Azure DevOps Services y lo que 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 del proceso de configuración de la organización>.
Elija el logotipo de Azure DevOps para abrir Proyectos. A continuación, elija Configuración de la organización.
A continuación, elija Procesar.
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
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.
Guarde el archivo ZIP y extraiga todos los archivos de él.
Cambie el nombre del proceso dentro del 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"/>
Aplicar personalizaciones admitidas.
Cree un archivo ZIP de todos los archivos y carpetas en el directorio raíz.
Importe el archivo ZIP del proceso personalizado.
Personalizaciones compatibles
Puede aplicar las siguientes personalizaciones al proceso:
- Agregue, quite o modifique un WIT.
- Agregue o modifique un campo.
- Agregue hasta cinco trabajos pendientes de cartera.
- Agregue categorías que usará en la configuración del proceso.
- Modificar la configuración del proceso.
- Agregar listas globales.
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.
- Personalizar un proceso XML hospedado
Plantilla de proceso
El archivo ProcessTemplate.xml debe cumplir la sintaxis y las reglas descritas en La referencia de elementos XML ProcessTemplate. Además, debe cumplir las condiciones siguientes:
- 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 contenga 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 de elementos XML ProcessConfiguration. Además, debe cumplir las condiciones siguientes:
- Especifica todos los elementos TypeFields
- Está limitado 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 flujo de trabajo a metastate necesarias y no hace referencia a los metastates no admitidos.
Categorías
El archivo de definición de Categories.xml debe ajustarse a la sintaxis y las reglas descritas en La 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 elementos de trabajo
Un elemento WITD y sus elementos secundarios deben cumplir la sintaxis y las reglas descritas en la referencia de elementos XML de WITD. Además, debe cumplir las condiciones siguientes:
- Hay como máximo 1024 campos dentro de un único WIT y 1024 campos en todas las REDES 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 requerido no contiene caracteres no permitidos ni usa los espacios de nombres no permitidos System.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 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 la 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 requerido no contiene caracteres no permitidos ni usa los espacios de nombres no permitidos System.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 1024 campos.
- Un tipo de elemento de trabajo está limitado a 64 campos de nombre de persona. Un campo 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 campos siguientes se especifican en el archivo ProcessConfiguration.xml:
- Para todos los 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
ytype=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 usado para
type=RemainingWork
. - Campo usado para
type=Activity
. - Regla ALLOWEDVALUES para el campo usado para
type=Activity
.
- Campo usado para
Restricciones de reglas
Además de las restricciones de reglas de campo estándar, se aplican las restricciones siguientes:
- Los elementos field-rule no pueden especificar para y no atributos.
- Los elementos FIELD no pueden contener los elementos de regla secundaria CANNOTLOSEVALUE, NOTSAMEAS, MATCH y PROHIBITEDVALUES.
- Excepto en los campos siguientes, 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.
Campos de identidad
Los campos de identidad corresponden a los campos usados para contener nombres de cuenta, usuario o grupo. Los siguientes campos principales del sistema se codifican 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 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 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 cadenavalue="Not Assigned"
que no es de identidad.
<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 ajustarse a la sintaxis y las reglas descritas en la 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 que se asignan a los 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 "Propuesta" 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 "Complete".
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, se colocan los límites siguientes en la importación de lista global:
- Hay como máximo 64 listas globales.
- Hay como máximo 1024 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 del elemento FORM XML.
Un elemento Control no puede especificar un control personalizado. No se admiten controles personalizados.