Cómo configurar la integración de Azure DevOps con Tableros de Fluid
Dan Justin·
Para ayudar a los gerentes de proyecto y a sus equipos de desarrollo a optimizar sus procesos de flujo de trabajo ágil, la integración de DevOps con Fluid permitirá a los gerentes establecer un flujo de trabajo ágil que se alinee con los requisitos técnicos de su equipo, fomentando así la colaboración e impulsando el progreso.
Este artículo explica cómo integrar DevOps con los Tableros de Fluid, permitiendo que el Propietario del Proyecto tenga visibilidad sobre el trabajo y la entrega de los equipos de TI/Tecnología sin la complejidad de DevOps y el proceso técnico.
NOTA: Esta función no está habilitada de forma predeterminada. Dependiendo de la complejidad de su entorno interno de DevOps, le recomendamos que primero hable sobre sus requisitos con su gestor de Éxito de Fluid. Esa persona podrá ayudarle a habilitar la función y guiarle a través de los pasos clave para integrarse con DevOps.
Acceder a la opción de integraciones en el tablero
Para empezar, vaya a las opciones de integraciones desde la vista de tablero Kanban, en la pestaña Herramientas.
Para otras vistas relacionadas con el tablero, como la vista de Backlog o la vista de Espacio de trabajo del tablero, la opción Configurar integración se encuentra en la columna de navegación izquierda. Como regla general, la navegación izquierda es donde debe buscar las opciones relacionadas con la vista actual. Sin embargo, para vistas como el tablero Kanban anterior, no hay navegación izquierda, por lo que las opciones se encuentran en el menú de herramientas.
Una vez seleccionada la opción de Integración y abierto el diálogo, podrá seleccionar la integración para AzureDevOps.
El siguiente diálogo mostrará la página de Configuración donde se pueden completar los detalles de la integración para el tablero.
Puede obtener más información sobre cómo crear inicialmente un tablero en Fluid haciendo clic aquí.
Completar los detalles de la integración
Cada una de las secciones de los detalles de la integración es la siguiente:
Nombre
El nombre del tablero que se reflejará en DevOps.
Activo
Indica si la integración está actualmente habilitada para este tablero.
Frecuencia
Con qué frecuencia se ejecuta el trabajo para cualquier actualización/cambio realizado en el tablero. - Cada hora - Cada 6 horas - Cada 12 horas - Diario - Semanal
Bloquear tareas de creación/actualización para DevOps
Habilita un bloqueo estricto para impedir que se envíe cualquier solicitud a DevOps.
Use esta opción cuando desee que Fluid funcione en modo de solo lectura, obteniendo información de DevOps sin realizar actualizaciones ni modificaciones en los elementos de trabajo de DevOps.
Proveedor de autenticación
Vea a continuación en la siguiente sección.
Proveedor de autenticación
Fluid admite Service Principals o tokens PAT para el acceso a DevOps. Los gerentes de proyecto deben trabajar con sus equipos internos de TI para proporcionar la información siguiente como parte de los requisitos de configuración.
Service Principals
A continuación se indican los detalles de configuración requeridos:
El GUID único de ID de cliente del Service Principal.
El secreto de cliente. El secreto se almacena de forma segura en un Azure Key Vault, no se conserva en ningún otro lugar fuera del Key Vault y el acceso al Key Vault está restringido al proceso que ejecuta la instancia de Fluid dentro de la plataforma Azure.
Su ID de inquilino de Azure AD.
Los detalles anteriores se utilizan según nuestra configuración:
NOTA: En cuanto a los permisos del Service Principal en los proyectos de DevOps, es importante que la cuenta también tenga permisos a nivel del Área en la que reside el proyecto, y no solo en el proyecto en sí. El Service Principal requiere acceso a lo largo del árbol jerárquico hasta el proyecto específico.
El Service Principal deberá tener permisos sobre el/los proyecto(s) de Azure DevOps con los que desea integrarse y tener los mismos permisos que un usuario habitual que contribuye al tablero/elementos de trabajo en DevOps.
Siga la guía para Service Principals. Las identidades administradas no son compatibles.
Tokens PAT
A continuación se indican los detalles de configuración requeridos:
Token PAT generado desde su instancia de DevOps
Organización
El dominio de la organización que se va a integrar. Puede encontrar su organización observando la url con la que accede a su instancia de DevOps. p. ej. https://[organisation_name].visualstudio.com o https://dev.azure.com/[organisation_name]. Ingrese únicamente el valor [organisatation_name] en este campo.
Tablero
Especifica el tablero de DevOps que se va a vincular o integrar.
Este campo se completa automáticamente y no se puede modificar.
Controlar que los asuntos confidenciales no se sincronicen
Permite controlar qué elementos de trabajo se sincronizan desde DevOps hacia Fluid, permitiendo importar únicamente los elementos de trabajo aprobados.
Hay dos opciones de configuración: Lista negra o Lista blanca.
Lista negra – Define las etiquetas usadas para excluir elementos de trabajo de la sincronización. Si un asunto contiene una etiqueta incluida en la lista negra, no se importará a Fluid.
Lista blanca – Define las etiquetas que permiten explícitamente la sincronización. Solo se sincronizarán los elementos de trabajo que contengan una etiqueta incluida en la lista blanca; todos los demás se excluirán.
Etiquetas que se usarán para BLOQUEAR/PERMITIR la sincronización de asuntos
Si "Controlar que los asuntos confidenciales no se sincronicen" está habilitado, ingrese una lista de valores de etiqueta delimitada por comas que se comparará con la etiqueta del elemento de trabajo de DevOps.
Proyecto
El nombre de su proyecto en Azure DevOps. Puede encontrarlo en la URL que usa para acceder a su instancia de DevOps, por ejemplo:
Ingrese únicamente la parte [project_name] en este campo.
Ruta de iteración
Puede ubicar su ruta de iteración utilizando cualquiera de los siguientes métodos:
Elementos de trabajo
Abra cualquier elemento de trabajo dentro de su proyecto de Azure DevOps (p. ej., historia de usuario, tarea o error).
Ubique el campo etiquetado "Iteration Path" o "Iteration" (el nombre puede variar ligeramente según la configuración del proyecto).
Este campo normalmente se muestra junto a Área (Area Path), Asignado a y otros campos de metadatos.
Tableros (Backlogs/Sprints)
Navegue a la sección Boards de su proyecto de Azure DevOps.
Si utiliza metodologías ágiles, la ruta de iteración es visible al gestionar backlogs o sprints.
Generalmente se muestra al crear o editar elementos de trabajo dentro de estos tableros.
Configuración del proyecto
Los Administradores de proyecto o usuarios con los permisos adecuados pueden ver y gestionar las rutas de iteración en Configuración del proyecto (Project Settings).
Vaya a Project Settings > Project Configuration para crear, editar o configurar rutas de iteración.
Ruta de iteración del backlog
La ruta de iteración del backlog se refiere a la iteración o sprint específico donde se planifican o asignan los elementos del backlog.
Puede ubicarla utilizando los siguientes métodos:
Sección Boards
Navegue a la sección Boards en su proyecto de Azure DevOps.
Abra el tablero correspondiente a su backlog (p. ej., “Backlog” o un tablero personalizado).
Cambie entre iteraciones o sprints — la iteración actualmente seleccionada representa la ruta de iteración del backlog.
Navegación del backlog
Al crear o gestionar elementos del backlog, estos se asocian con una iteración o sprint específico. Esta asociación define la ruta de iteración del backlog.
Configuración de iteraciones
Los Administradores de proyecto o usuarios con los permisos adecuados pueden configurar los ajustes de iteración.
Vaya a Project Settings > Project Configuration y luego navegue a Iterations o Sprints para ver o ajustar qué iteraciones están vinculadas al backlog.
Ruta de área
Puede ubicar y gestionar las rutas de área utilizando los siguientes métodos:
Elementos de trabajo
Abra cualquier elemento de trabajo en su proyecto de Azure DevOps (p. ej., historia de usuario, tarea o error).
Busque el campo etiquetado "Area Path" (a veces solo "Area") entre los detalles del elemento de trabajo.
Este campo normalmente se muestra junto a Ruta de iteración, Asignado a y otros campos de metadatos.
Boards y Backlogs
Navegue a la sección Boards de su proyecto de Azure DevOps.
Según su configuración, puede tener opciones para filtrar o ver tableros y backlogs por ruta de área, lo que le permite enfocarse en elementos de trabajo de áreas o equipos específicos.
Configuración del proyecto
Los Administradores de proyecto o usuarios con los permisos adecuados pueden crear o gestionar rutas de área.
Vaya a Project Settings > Project Configuration para ver, crear o configurar rutas de área para su proyecto.
Proyecto de equipo
Puede ubicar o gestionar un proyecto de equipo utilizando los siguientes métodos:
URL de Azure DevOps
La URL de un proyecto de equipo específico normalmente sigue este formato:
Puede navegar directamente a un proyecto usando esta URL.
Al ingresar el nombre del proyecto en los campos de configuración, ingrese únicamente la parte [project_name].
Administración de Azure DevOps
Los usuarios con los permisos adecuados pueden gestionar proyectos de equipo a través de la administración de Azure DevOps.
Acceda al panel de administración a través de Organization Settings para crear, eliminar o configurar proyectos de equipo y sus ajustes.
Permitir Webhooks entrantes desde DevOps
Habilita la creación y eliminación automática de elementos de trabajo en Fluid en función de las acciones en DevOps. Los elementos de trabajo recién creados se vinculan automáticamente y se sincronizarán según su configuración.
Cuando está habilitado, se muestra una URL—esta URL debe proporcionarse en la configuración del Service Hook de DevOps para propagar los eventos de DevOps hacia Fluid.
Actualizar estado desde DevOps
[Actualizaciones bidireccionales] – Habilita la sincronización bidireccional de los estados de tarea entre Fluid y DevOps. Cualquier cambio de estado realizado en Fluid se enviará a DevOps, y cualquier actualización de estado en DevOps se reflejará en la tarjeta correspondiente de Fluid.
Esto garantiza que los estados en ambos sistemas permanezcan totalmente sincronizados.
Nota: Si esta opción no está habilitada, los cambios de estado en Fluid no se sincronizarán con DevOps, y las actualizaciones de estado en DevOps no se reflejarán en Fluid.
Permitir eliminar en DevOps
Permite que Fluid elimine tareas en DevOps. Tenga en cuenta que esta es una acción no destructiva; es una eliminación reversible en DevOps y puede restaurarse desde el propio DevOps. Las políticas de retención son específicas de cada proyecto, consulte a su administrador de sitio para conocer los tiempos de retención exactos.
Eliminar elementos de trabajo pendientes de DevOps
Cuando está habilitado, mover elementos al Backlog en Fluid eliminará automáticamente sus elementos de trabajo de DevOps vinculados.
Si esta opción no está habilitada, los elementos de trabajo de DevOps permanecen sin cambios y siguen vinculados a los elementos de Backlog correspondientes de Fluid.
Crear tareas pendientes en DevOps
Cuando está habilitado, crear una tarea de Backlog en Fluid también creará y vinculará un elemento de trabajo correspondiente en DevOps.
Si esta opción no está habilitada, los elementos de trabajo de DevOps solo se crean y vinculan cuando la tarea de Fluid se mueve fuera del Backlog.
Omitir primera columna Crear en DevOps
Cuando está habilitado, cualquier tarea de Fluid creada en la primera columna del tablero no se creará ni se vinculará a un asunto correspondiente en DevOps.
Si está habilitado, estas tareas solo se crearán y vincularán cuando la tarea de Fluid se mueva a una columna posterior del tablero.
Permitir que los archivos adjuntos se sincronicen de Fluid a DevOps
Cuando está habilitado, vinculará los archivos adjuntos del elemento de Fluid con DevOps. Los archivos adjuntos son enlaces url que remiten a Fluid para verse/descargarse.
Sincronizar elemento después de crear o vincular
Una vez que se crea un elemento de Fluid en el tablero, se sincroniza de inmediato con DevOps. No es necesario esperar a la sincronización programada ni hacer clic manualmente en "Sync Schedule" en la parte superior del tablero para actualizar sus propiedades.
Calculadora de % de progreso
El progreso de la tarea puede calcularse según el estado de sus elementos secundarios usando uno de los siguientes métodos:
Frecuencia de estado
El progreso se determina por la proporción de elementos secundarios completados respecto al número total de elementos secundarios.
Fórmula:
Progreso = Número de elementos secundarios completados ÷ Número total de elementos secundarios
Basado en puntos
El progreso se determina por la proporción de puntos asociados a los elementos secundarios completados respecto al total de puntos de todos los elementos secundarios.
Fórmula:
Progreso = Suma de puntos de los elementos secundarios completados ÷ Puntos totales de todos los elementos secundarios
Basado en duración
El progreso se determina por la proporción de la duración planificada de los elementos secundarios completados respecto a la duración total planificada de todos los elementos secundarios.
Fórmula:
Progreso = Suma de duraciones de los elementos secundarios completados ÷ Duración total de todos los elementos secundarios
Incluir el elemento principal en el cálculo del % de progreso
Decida si el elemento de trabajo principal de DevOps debe incluirse en el cálculo del progreso. Si la tarea principal solo funciona como contenedor de subtareas, es posible que no desee que contribuya al cálculo.
Habilitado: El elemento principal se incluye en el cálculo del progreso.
Deshabilitado: Solo se consideran los elementos secundarios de nivel hoja al determinar el progreso.
Esto garantiza que las tareas contenedoras no infleen ni distorsionen artificialmente las métricas de progreso.
Incluir elementos de "Relates To" en el cálculo del % de progreso
Determina si los elementos de trabajo secundarios de DevOps "Relates To" se incluyen en el cálculo del progreso de las subtareas.
Habilitado: Se consideran tanto las subtareas secundarias directas como los elementos de trabajo de DevOps "Relates To".
Deshabilitado: Solo se usan las subtareas secundarias directas para calcular el progreso.
Mostrar el estado de DevOps en los elementos de trabajo secundarios
El estado real de DevOps de cada elemento secundario se muestra en línea en la barra de progreso.
Registro detallado
Se usa al configurar inicialmente; actívelo para ver mensajes detallados en caso de problemas de comunicación entre Fluid y DevOps.
Mapeo de estado
Configure las columnas de estado que se mapearán en DevOps para cuando se actualicen los estados de las tareas.
Mapeos de tipos de tareas
Configure los tipos de tarea que se mapearán a DevOps. Solo las tareas que hayan sido configuradas y mapeadas se usarán para integrarse con DevOps.
Propiedades comunes
Configure qué propiedades comunes se asociarán a todas las tareas mapeadas para minimizar la duplicación. Si las propiedades están definidas, se enviarán a DevOps al crear y actualizar la tarjeta de fluid.
Task Properties
Configure las propiedades específicas de este tipo de tarea únicamente. Solo las propiedades mapeadas aquí se aplicarán a la tarea, además de las que se hayan definido como comunes.
Generación de tokens PAT desde la API
Todos los usuarios pueden crear sus propios PATs, que coincidirán con su nivel de permisos actual. Para crear los tokens, puede seguir estos pasos:
DevOps puede cambiar su configuración y ajustes específicos entre versiones e implementaciones. Los detalles a continuación son correctos en el momento actual, pero visite https://learn.microsoft.com/en-us/azure/devops/organizations/?view=azure-devops para obtener información más actualizada.
En su instancia de DevOps:
1. Inicie sesión en Azure DevOps:
Vaya a la URL de su organización de Azure DevOps (p. ej., https://dev.azure.com/[organization_name]).
2. Acceda a la Configuración de usuario:
Haga clic en el icono de su perfil (esquina superior derecha) para abrir el menú.
Seleccione "Security" o "User settings" (el texto exacto puede variar según la configuración de su organización).
3. Personal Access Tokens:
Busque una opción como "Personal access tokens" o "PATs."
Haga clic en esta opción para navegar a la página de Personal Access Tokens.
4. Cree un nuevo token:
En la página de PATs, haga clic en el botón "New Token" o "Create Token".
5. Configuración del token:
Ingrese un nombre para su token. Esto es para su referencia y puede describir su propósito o uso.
Elija el alcance de organización o proyecto para el acceso del token.
6. Elija el nivel de acceso y los alcances:
Seleccione el nivel de acceso que debe tener el token (p. ej., acceso completo, lectura, escritura).
Especifique los alcances o áreas a las que el token tendrá acceso (p. ej., elementos de trabajo, repositorios, pipelines).
7. Configure la fecha de caducidad:
Establezca una fecha de caducidad para el token.
Asegúrese de establecer una fecha de caducidad adecuada acorde a las fechas de inicio/fin de su proyecto.
Puede editar su token y extender la caducidad más adelante.
8. Cree el token:
Haga clic en el botón "Create" o "Generate".
9. Copie y guarde el token:
Una vez generado, el PAT se mostrará solo una vez. Cópielo y guárdelo en un lugar seguro.
Trate este token como una contraseña; proporciona acceso a sus recursos de Azure DevOps.
Recuerde:
Seguridad: Mantenga sus tokens seguros. Evite compartirlos abiertamente.
Revocación: Si un token se ve comprometido o ya no es necesario, puede revocarlo o eliminarlo desde el portal de Azure DevOps.
Sincronización de estado
Cuando está habilitada, esta opción controla el comportamiento de la sincronización del estado desde DevOps hacia fluid y viceversa. Si está habilitada, se considera una sincronización bidireccional.
Si el estado de Fluid cambia, esto se envía a DevOps y el elemento se actualizará en consecuencia.
Si el estado de DevOps cambia, cuando se ejecute el trabajo de sincronización configurado, la tarjeta de fluid se actualizará para coincidir con el estado del elemento de DevOps.
Una vez sincronizados, ambos elementos se corresponden en cuanto a sus respectivos estados según el Modo de sincronización de estado (ver más abajo) y de acuerdo con el mapeo de estado definido; consulte la sección "Mapeo de estado" a continuación para más información.
Cuando está deshabilitada, no se enviará ninguna información de estado como parte de la creación del elemento de DevOps. De forma predeterminada, DevOps creará el elemento de DevOps en su estado predeterminado, tal como esté definido para ese tipo de tarea dentro de DevOps. Consulte la configuración de DevOps para cada tipo de tarea dentro de la propia aplicación DevOps para saber qué estado predeterminado se utiliza.
Modo de sincronización de estado
Si la sincronización de estado está habilitada, habrá un botón visible como el resaltado arriba en el que puede hacer clic para elegir el modo de sincronización que desea aplicar.
Solo crear [Push]
El estado de Fluid se envía una única vez, y solo al crear el elemento, a DevOps. Los cambios posteriores de estado en Fluid no se reflejarán en DevOps. Puede seguir actualizando el estado en Fluid, y el estado aparecerá cambiado en Fluid, pero el estado del elemento vinculado en DevOps no cambiará.
Unidireccional [Empujar]
Cualquier cambio en el estado en Fluid se envía a DevOps. Sin embargo, ningún estado de DevOps se obtiene/actualiza de vuelta en Fluid. Use esto si desea que Fluid sea la fuente principal de datos de estado para el elemento.
Unidireccional [Pull]
Cualquier cambio en el estado del elemento de DevOps se obtiene en Fluid y reemplaza el estado actual del elemento de Fluid cuando ocurre la sincronización. Use esto si desea que DevOps sea la fuente principal del estado del elemento.
Sincronización [Bidireccional]
El estado de Fluid y el estado de DevOps se mantienen sincronizados. Cualquier cambio en Fluid se envía a DevOps y, viceversa, cualquier cambio de estado en DevOps se sincroniza de vuelta en Fluid cuando se ejecuta el proceso de sincronización.
Mapeo de estado
En Fluid, las columnas de estado de cada tablero pueden configurarse para mover las tareas a medida que avanzan en el flujo de trabajo ágil. Es importante mapear qué columnas de estado deben incluirse en DevOps para garantizar que, cuando se actualice el estado de una tarea en Fluid, esto se sincronice en DevOps.
Nota: Si los estados no están mapeados, las actualizaciones realizadas en Fluid en las tareas no se integrarán en DevOps.
Los estados pueden tener una relación 1 : M (1 a Muchos). Por ejemplo, "In Progress" y "Dev Complete" en fluid se han mapeado al mismo estado "In Progress" en DevOps. Además, "Not Started" y "Returned" se han mapeado ambos a "To Do" en DevOps.
Nota: La primera fila está coloreada en gris. Esto indica que es el estado inicial para los elementos creados. La última fila está coloreada en verde para indicar que es el estado final del elemento. Todos los demás estados son azules y, por definición, se consideran un estado "In Progress".
Haga clic en [+ New Status Mapping] para agregar una nueva fila.
Seleccione de una lista de posibles opciones de estado a la izquierda.
En el lado derecho, escriba el nombre del estado y a qué estado de Fluid debe aplicarse.
Haga clic en [ X ] para eliminar la fila.
Propiedades comunes
Configurar propiedades comunes brinda la capacidad de establecer propiedades que se aplicarán de manera consistente en los datos de tarea que se optimizan en su flujo de trabajo.
Estas propiedades se usan ampliamente y se aplican a múltiples tareas, lo que a su vez reduce el esfuerzo duplicado.
Solo las propiedades mapeadas se enviarán a DevOps.
Nota: DevOps puede ser inconsistente con el uso de mayúsculas y sus convenciones de nomenclatura. Al configurar el campo de DevOps, es recomendable asegurarse de usar exactamente el mismo uso de mayúsculas y minúsculas tal como está definido en DevOps.
Modo de sincronización de propiedades comunes
Solo crear [Push]
Las propiedades de Fluid se envían una única vez, y solo al crear el elemento, a DevOps. Los cambios posteriores en las propiedades en Fluid no se reflejan en DevOps. Puede seguir actualizando las propiedades en Fluid, y aparecerán como cambiadas en Fluid, pero las propiedades del elemento vinculado en DevOps no cambiarán.
Unidireccional [Empujar]
Las propiedades que cambien en Fluid se envían a DevOps. Sin embargo, ninguna propiedad de DevOps se obtiene/actualiza de vuelta en Fluid. Use esto si desea que Fluid sea la fuente principal de propiedades para el elemento.
Unidireccional [Pull]
Las propiedades que cambien en el elemento de DevOps se obtienen de vuelta en Fluid y reemplazan los valores de las propiedades del elemento de Fluid cuando ocurre la sincronización. Use esto si desea que DevOps sea la fuente principal de propiedades para el elemento.
Sincronización [Bidireccional]
Las propiedades de Fluid y las propiedades de DevOps se mantienen sincronizadas. Cualquier cambio en Fluid se envía a DevOps y, viceversa, cualquier cambio de propiedades en DevOps se sincroniza de vuelta en Fluid cuando se ejecuta el proceso de sincronización.
Tipo de tarea
Para cada tarea con la que desee crear un elemento de DevOps en su flujo de trabajo, se debe definir el Tipo de tarea y mapearlo al tipo equivalente en DevOps.
Si un tipo de tarea de Fluid no está mapeado, no se creará el elemento correspondiente en DevOps en el flujo de trabajo.
Task Type Properties
Las propiedades del tipo de tarea proporcionan información adicional sobre los distintos tipos de actividades que se llevan a cabo dentro de un flujo de trabajo. Estas se relacionan específicamente solo con este Tipo de tarea definido.
Si tiene una propiedad que solo se define para un tipo de tarea en particular, use este flujo. Si tiene una propiedad que se aplicará a todos los tipos de tarea, use Propiedades comunes como se definió anteriormente. Las propiedades comunes se incluyen como un conjunto unión de propiedades para este tipo de tarea.
Task Type Status
El estado del tipo de tarea le permite definir cualquier estado específico adicional que solo aplique a este Tipo de tarea. Tenga en cuenta que puede seguir teniendo mapeos de estado definidos como se mencionó anteriormente en la sección de mapeo de estado de este documento, pero cualquier estado que defina aquí a nivel de Tipo de tarea se suma a los mapeos de estado ya definidos y son específicos solo para este Tipo de tarea.
Si ya ha definido el mapeo "Not Started"->"New", entonces agregar un mapeo de estado de Tipo de tarea de "In Progress"-> "Working" significará que, para el Tipo de tarea de Fluid Nueva funcionalidad, hemos mapeado "Not Started" y "In Progress" de Fluid en consecuencia.
Esto le permite, si lo prefiere, tener conjuntos de estados completamente diferentes para cada Tipo de tarea, según cómo haya configurado sus estados y reglas en DevOps.
Sincronización de campos desde DevOps hacia Fluid
Cada vez que se actualiza una tarea/tarjeta del tablero, los cambios se sincronizan con la tarjeta en DevOps. A continuación se muestra un ejemplo de una tarjeta creada en un tablero de fluid y cómo se representa en DevOps.
Esta es la tarjeta creada en DevOps como una Feature.
Al hacer clic en la tarjeta en Fluid se abre el diálogo de edición; la sección de Integraciones se muestra en la parte inferior de la tarjeta del tablero, donde puede ver la sincronización del elemento de DevOps con fluid.
El estado "In Progress" indica que el elemento de DevOps se está trabajando actualmente. Puede hacer clic en el título "Risk Matrix Chart" para ver el elemento real en DevOps.
"0% Done" indica que el cálculo de % completado está en 0%, no hay elementos asociados en estado hecho/completado.
Nota: Puede iniciar manualmente un trabajo de sincronización haciendo clic en el botón "Sync Integrations"
ubicado en la parte superior del tablero. Esto ejecutará manualmente el trabajo que obtiene todos los datos de DevOp. Es el mismo trabajo que se ejecuta con la frecuencia definida en la configuración anterior.
Si solo desea "Sync Integration" en esta tarjeta en particular, puede hacer clic en el texto "Última sincronización: 01 Dec 2023 10:23" para activar una actualización solo para este elemento.
Para ilustrar mejor, el equipo de TI/Tecnología ha agregado 3 subtareas en DevOps a este elemento principal en el siguiente ejemplo. Esto muestra cómo el equipo de TI/Tecnología gestiona el asunto de DevOps por sí mismo, usando su propia metodología ágil, al margen del Propietario del Proyecto.
Las 3 subtareas son controladas por el equipo de TI/Tecnología, todos los campos son establecidos por TI, y TI es libre de usar estas subtareas en cualquier metodología de desarrollo que elija. A medida que estas subtareas se actualizan por TI, el elemento principal de DevOps se actualiza para mostrar el cambio en el estado de las subtareas. TI también ha establecido una Fecha de vencimiento en este elemento principal, “30 Mar 2023”.
Nota: No es un requisito que TI use subtareas; son libres de trabajar directamente sobre el elemento principal de DevOps y actualizarlo en consecuencia, usarlo en sprints, etc. Las subtareas son el proceso recomendado de DevOps para dividir una tarea más grande en componentes más pequeños, que pueden trabajarse por separado y luego consolidarse en un elemento principal.
Después de que los datos se hayan sincronizado, se muestra la siguiente sección en el diálogo de edición de la acción.
“In Progress” es el estado del elemento de DevOps; al hacer clic en “Open DevOps” le llevará directamente al elemento de DevOps en una nueva pestaña del navegador.
El “30 Mar 23” es la fecha de vencimiento que se ha establecido en el propio elemento de DevOps. Esta NO es la Fecha de vencimiento del elemento de Fluid.
“33% complete” indica el porcentaje de subtareas completadas / total de subtareas. La barra le muestra una barra de progreso de cuánto trabajo falta antes de completarse: Verde es “Completed”, Azul es “In Progress”, Gris es “Not Started”
Al hacer clic en “Mostrar detalles” se mostrará una vista ampliada y podrá ver todas las subtareas asignadas, un título/descripción, estado y fecha de vencimiento de cada subtarea
El Propietario del Proyecto tiene visibilidad sobre el trabajo y el propio equipo de TI/Tecnología; puede ver que el equipo de TI/Tecnología está al 33% de finalización en este trabajo y que las fechas de vencimiento actuales coinciden.
El equipo de TI/tecnología agregó las tareas a su ciclo de sprint y realizó el desarrollo dentro de sus propios procesos sin tener que cambiar la forma en que operan como equipo. El Propietario del Proyecto tampoco tuvo que perseguir al líder técnico de TI para obtener actualizaciones; el Propietario del Proyecto puede ver esto directamente en la tarjeta/acción.
