Su Template de datos para el ciclo de vida del desarrollo de software
Su Template de datos para el ciclo de vida del desarrollo de software
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía para extraer los datos
Atributos del ciclo de vida del desarrollo de software
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
Nombre del paso o evento específico del proceso que se produjo, como 'Incidencia creada' o 'Solicitud de fusión integrada'. | ||
|
Descripción
El atributo Actividad recoge los distintos eventos que afectan a un elemento de desarrollo. En GitLab, no se almacenan en un único campo, sino que se derivan de diversas acciones y marcas de tiempo de Issues, Merge Requests y CI/CD Pipelines. Por ejemplo, la creación de una incidencia, el envío de un commit, el fallo de un pipeline o la aprobación de una solicitud de fusión son actividades distintas. Este atributo es fundamental para crear el mapa del proceso, visualizar el flujo de trabajo y analizar la secuencia y la frecuencia de los eventos. Permite identificar desviaciones, cuellos de botella entre etapas y las rutas más habituales del proceso.
Por qué es importante
Define los pasos del mapa del proceso y permite visualizar y analizar el flujo de trabajo del desarrollo de principio a fin.
Dónde obtenerlo
Se deriva de los tipos de evento y los cambios de estado del flujo de eventos de GitLab, o de la interpretación de marcas de tiempo como 'created_at', 'merged_at' y 'closed_at' en Issues y Merge Requests.
Ejemplos
Incidencia creadaDesarrollo iniciadoSolicitud de fusión integradaPipeline fallidoImplementado en producción
|
|||
|
Elemento de desarrollo
DevelopmentItem
|
Identificador único de una unidad de trabajo, como una funcionalidad, una corrección de errores o una tarea. Se utiliza como identificador principal del caso. | ||
|
Descripción
El elemento de desarrollo representa una unidad de trabajo individual y rastreable que avanza a lo largo del ciclo de vida del desarrollo de software. Vincula en un caso coherente todas las actividades relacionadas, desde su creación hasta la implementación final. En GitLab, suele corresponder al ID interno (IID) de la incidencia, que es único dentro de cada proyecto. Analizar los datos por elemento de desarrollo permite medir el tiempo de ciclo de principio a fin, identificar cuellos de botella y comprobar la conformidad del proceso. Es la base para entender con qué eficiencia se entrega el trabajo desde la idea hasta la puesta en producción.
Por qué es importante
Este es el identificador esencial del caso, que vincula todos los eventos del proceso y permite rastrear el ciclo de vida completo de cualquier elemento de trabajo.
Dónde obtenerlo
Suele ser el ID interno (IID) de una incidencia de GitLab. Puede consultarse en la respuesta de la API de Issues, en el campo 'iid'.
Ejemplos
1024512PRJ-2345
|
|||
|
Hora de inicio
StartTime
|
Marca de tiempo que indica cuándo comenzó una actividad o un evento. | ||
|
Descripción
StartTime indica la fecha y hora exactas en que se produjo una actividad específica. En GitLab, se obtiene de distintos campos de marca de tiempo. Por ejemplo, la hora de inicio de la actividad 'Incidencia creada' corresponde a la marca de tiempo Esta marca de tiempo es el elemento temporal fundamental de Process Mining. Se utiliza para ordenar cronológicamente los eventos, calcular la duración entre actividades, medir los tiempos de ciclo y analizar el rendimiento del proceso a lo largo del tiempo.
Por qué es importante
Este atributo proporciona la secuencia cronológica de los eventos, necesaria para calcular todas las métricas basadas en el tiempo y entender el flujo del proceso.
Dónde obtenerlo
Se extrae de distintos campos de marca de tiempo de GitLab, como 'created_at', 'updated_at' y 'closed_at' en las incidencias, y 'merged_at' en las solicitudes de fusión.
Ejemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Gravedad
Severity
|
Nivel de gravedad del elemento de desarrollo, normalmente en el caso de errores o incidentes. | ||
|
Descripción
La gravedad indica el impacto de un error o problema, desde crítico hasta leve. GitLab no incluye un campo de gravedad de forma nativa, por lo que casi siempre se implementa mediante etiquetas, por ejemplo, 'severity::1' y 'severity::2'. Este atributo es esencial para el Dashboard de tendencias de escalación de gravedad y el KPI asociado. Analizar los cambios de gravedad a lo largo del ciclo de vida permite detectar problemas cuya gravedad se subestimó al principio o procesos que agravan las incidencias.
Por qué es importante
Ayuda a priorizar el trabajo y a analizar si los elementos de gravedad alta se atienden más rápido. Registrar los cambios permite calcular el KPI de frecuencia de escalación de gravedad.
Dónde obtenerlo
Se deriva de las etiquetas aplicadas a una incidencia de GitLab. Se necesita una asignación para interpretar etiquetas como 'S1' y 'S2' como niveles de gravedad.
Ejemplos
1 - Crítico2 - Alto3 - Medio4 - Bajo
|
|||
|
Hora de fin
EndTime
|
Marca de tiempo que indica cuándo terminó una actividad o un evento. | ||
|
Descripción
EndTime indica la fecha y hora exactas en que terminó una actividad. En muchos eventos atómicos de GitLab, como 'Incidencia creada', la hora de fin coincide con la hora de inicio. En las actividades que tienen una duración, como la revisión del código, indica la marca de tiempo de finalización, por ejemplo, cuando se concede la aprobación final. Este atributo es esencial para calcular con precisión la duración de cada actividad (tiempo de procesamiento). También permite analizar los cuellos de botella en detalle, al distinguir entre el tiempo dedicado activamente a una tarea y el tiempo de espera entre tareas.
Por qué es importante
Permite calcular con precisión la duración de las actividades (tiempos de procesamiento), un dato clave para identificar pasos ineficientes en el proceso.
Dónde obtenerlo
En los eventos atómicos, coincide con StartTime. Para las actividades con duración, debe obtenerse a partir del evento de finalización correspondiente en los datos.
Ejemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Nombre del proyecto
ProjectName
|
Nombre del proyecto de GitLab al que pertenece el elemento de desarrollo. | ||
|
Descripción
Este atributo identifica el repositorio de código o proyecto específico donde se realiza el trabajo. En GitLab, cada incidencia y solicitud de fusión pertenece a un proyecto. Analizar los datos por nombre del proyecto permite comparar el rendimiento de distintos productos, componentes o servicios. Puede ayudar a identificar qué proyectos tienen procesos de SDLC más eficientes y permite filtrar los Dashboards para centrarse en un área concreta.
Por qué es importante
Permite segmentar el análisis del proceso por producto, aplicación o componente y facilita la aplicación de mejoras específicas.
Dónde obtenerlo
Se obtiene de los campos 'name' o 'path_with_namespace' de la API de Project, vinculados mediante 'project_id' en Issues y Merge Requests.
Ejemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Responsable
Assignee
|
Usuario asignado a la incidencia o solicitud de fusión en el momento del evento. | ||
|
Descripción
El responsable es el desarrollador o usuario que se encarga del elemento de trabajo en un momento determinado del proceso. En GitLab, se obtiene del campo Analizar los datos por responsable es fundamental para el Dashboard de carga de trabajo y asignación de desarrolladores. Ayuda a entender el uso de los recursos, identificar a las personas o equipos con exceso de trabajo y analizar las transferencias entre personas.
Por qué es importante
Registra quién realizó el trabajo y permite analizar la carga de trabajo, la eficiencia en la asignación de recursos y las demoras causadas por las transferencias.
Dónde obtenerlo
Se obtiene de los campos 'assignee.username' o 'assignees' de las respuestas de la API de GitLab Issues y Merge Requests.
Ejemplos
jdoeasmithr.williams
|
|||
|
Tipo de elemento de desarrollo
DevelopmentItemType
|
Clasificación del elemento de desarrollo, como 'Funcionalidad', 'Error', 'Tarea' o 'Mantenimiento'. | ||
|
Descripción
Este atributo clasifica la naturaleza del trabajo realizado. En GitLab, suele implementarse mediante etiquetas en una incidencia. Los equipos utilizan etiquetas para distinguir entre nuevas funcionalidades, correcciones de errores, deuda técnica y otros tipos de trabajo. Analizar los datos por tipo de elemento de desarrollo permite comparar los flujos de proceso y los tiempos de ciclo de distintos tipos de trabajo. Por ejemplo, permite comprobar si los errores se resuelven más rápido que las funcionalidades o si las tareas de deuda técnica siguen un proceso de revisión diferente.
Por qué es importante
Segmentar el proceso por tipo de trabajo ayuda a identificar si algunos tipos son más propensos a sufrir demoras, retrabajo o desviaciones.
Dónde obtenerlo
Suele derivarse de las etiquetas aplicadas a una incidencia de GitLab. Se necesita una lógica de asignación para convertir etiquetas específicas en tipos estandarizados.
Ejemplos
FuncionalidadErrorTareaDeuda técnica
|
|||
|
Es retrabajo
IsRework
|
Indicador booleano que señala si una actividad forma parte de un ciclo de retrabajo. | ||
|
Descripción
Este atributo calculado marca las actividades que representan un retroceso en el proceso, como volver al desarrollo después de que hayan comenzado las pruebas. Por lo general, la lógica del indicador detecta secuencias específicas de actividades; por ejemplo, un evento «Desarrollo iniciado» que ocurre después de «Canalización fallida» o «Pruebas de control de calidad iniciadas» en el mismo caso. Este atributo alimenta directamente el Dashboard «Análisis de retrabajo y nuevas ejecuciones» y el KPI «Tasa de retrabajo después de las pruebas». Permite filtrar y cuantificar fácilmente el retrabajo para que los equipos comprendan su frecuencia, sus causas y su impacto en los plazos de los proyectos.
Por qué es importante
Marca y cuantifica directamente el retrabajo, lo que facilita el análisis de las causas y el impacto de las ineficiencias del proceso y los problemas de calidad.
Dónde obtenerlo
La herramienta de Process Mining lo calcula analizando la secuencia de actividades de cada caso e identificando patrones que indican retrabajo.
Ejemplos
truefalse
|
|||
|
Estado de la canalización
PipelineStatus
|
Estado de la ejecución de la canalización de CI/CD, como «correcta», «fallida» o «en ejecución». | ||
|
Descripción
Este atributo indica el resultado de una ejecución de canalización de CI/CD asociada a una confirmación o una solicitud de fusión. Entre los estados habituales de GitLab se encuentran «running», «pending», «success», «failed», «canceled» y «skipped». Estos datos son esenciales para el Dashboard «Análisis de retrabajo y nuevas ejecuciones». Los fallos frecuentes de las canalizaciones pueden generar mucho retrabajo y demoras. Analizar su frecuencia, ubicación e impacto es clave para mejorar la eficiencia del desarrollo y la calidad del código.
Por qué es importante
Registra los resultados correctos y fallidos de las compilaciones y pruebas automatizadas, y permite detectar ciclos de retrabajo y problemas de calidad del código o de automatización de pruebas.
Dónde obtenerlo
Se obtiene del campo «status» de la respuesta de la API de GitLab CI/CD Pipelines.
Ejemplos
correctafallidaen ejecucióncancelada
|
|||
|
Estado de la solicitud de fusión
MergeRequestStatus
|
Estado de la solicitud de fusión asociada al evento, como «abierta», «fusionada» o «cerrada». | ||
|
Descripción
Este atributo registra el estado de una solicitud de fusión (MR) en el momento del evento. Las MR de GitLab pueden tener distintos estados: «opened», «closed», «merged» o «locked». Este dato es independiente del estado general del elemento de desarrollo. El seguimiento del estado de las MR es fundamental para analizar la fase de integración de código del SDLC. Permite crear Dashboards como «Tiempo de ciclo y rendimiento de la revisión de código» y ayuda a detectar demoras entre la creación, la revisión, la aprobación y la fusión de una MR.
Por qué es importante
Permite ver el proceso de revisión y fusión de código, que suele ser un cuello de botella crítico en el SDLC.
Dónde obtenerlo
Se obtiene del campo «state» de la respuesta de la API de GitLab Merge Requests.
Ejemplos
abiertofusionadacerradobloqueada
|
|||
|
Estado del elemento de desarrollo
DevelopmentItemStatus
|
Estado del elemento de desarrollo en el momento del evento, como 'Abierto', 'En curso' o 'Cerrado'. | ||
|
Descripción
Este atributo refleja el estado del elemento de trabajo principal, que suele ser una incidencia de GitLab. Las incidencias de GitLab tienen un campo Registrar los cambios de estado es fundamental para entender el ciclo de vida del caso. Permite identificar cuánto tiempo permanece cada elemento en cada estado y filtrar el trabajo activo o completado en Dashboards como 'Tiempo de ciclo integral del SDLC'.
Por qué es importante
Ofrece una instantánea del estado del caso, permite analizar el tiempo dedicado a cada etapa y filtrar el trabajo en curso y el completado.
Dónde obtenerlo
El estado principal se obtiene del campo 'state' de una incidencia de GitLab ('opened' o 'closed'). Los estados más detallados suelen derivarse de las etiquetas.
Ejemplos
abiertocerradoEn cursoEn revisión
|
|||
|
Nombre del equipo
TeamName
|
Equipo de desarrollo asociado al proyecto o al responsable. | ||
|
Descripción
Nombre del equipo identifica al grupo responsable del elemento de desarrollo. Por lo general, no es un campo estándar de GitLab y suele derivarse de las convenciones de nombres de los proyectos, la estructura de grupos o una tabla de referencia externa que relaciona a los responsables con sus equipos. Este atributo permite analizar el rendimiento del proceso por equipo. Ayuda a comparar la eficiencia, la carga de trabajo y el cumplimiento del proceso entre distintos equipos, y facilita el análisis desde la perspectiva de cada equipo en Dashboards como 'Análisis de Bottleneck por etapa'.
Por qué es importante
Permite analizar el rendimiento y comparar los procesos de distintos equipos, lo que ayuda a identificar cuellos de botella específicos de cada equipo y buenas prácticas.
Dónde obtenerlo
A menudo se obtiene relacionando el nombre del proyecto o el responsable con una estructura de equipos definida fuera de GitLab, o se infiere a partir de la jerarquía de grupos de GitLab.
Ejemplos
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
Rama de destino
TargetBranch
|
Nombre de la rama de destino a la que se fusionará una solicitud. | ||
|
Descripción
La rama de destino es aquella en la que se integrarán los cambios, por ejemplo, «main», «develop» o una rama de lanzamiento como «release/1.5». Es un dato fundamental de cualquier solicitud de fusión. Analizar los datos por rama de destino puede revelar diferencias en el proceso según el destino de la integración. Por ejemplo, las fusiones en «main» pueden requerir un proceso de aprobación más riguroso y tener tiempos de ciclo más largos que las fusiones en una rama de funcionalidades. También permite distinguir las implementaciones en producción de otros tipos de integración de código.
Por qué es importante
Permite distinguir entre distintos flujos de trabajo de desarrollo y lanzamiento, ya que los procesos pueden variar considerablemente según la rama de destino.
Dónde obtenerlo
Se obtiene del campo «target_branch» de la respuesta de la API de GitLab Merge Requests.
Ejemplos
principaldesarrollolanzamiento/v2.1.0corrección urgente/error de autenticación de usuario
|
|||
|
Sistema de origen
SourceSystem
|
Identifica el sistema del que proceden los datos. | ||
|
Descripción
Este atributo especifica el origen de los datos del proceso. En este modelo de datos, su valor será siempre 'GitLab'. Incluir este atributo es fundamental en entornos donde se combinan datos de procesos de varios sistemas, como Jira para la planificación y GitLab para la ejecución. Permite filtrar y segmentar los datos, y ayuda a mantener su trazabilidad.
Por qué es importante
Aclara el origen de los datos, algo fundamental para la gobernanza de datos y la integración de información procedente de varios sistemas empresariales.
Dónde obtenerlo
Es un valor estático, 'GitLab', que se añade durante la transformación de los datos.
Ejemplos
GitLab
|
|||
|
Tiempo de ciclo
CycleTime
|
Tiempo total transcurrido entre la primera y la última actividad de un elemento de desarrollo. | ||
|
Descripción
El tiempo de ciclo es una métrica calculada que mide la duración total de un caso. Por lo general, se calcula como la diferencia entre el primer evento (por ejemplo, «Incidencia creada») y el último (por ejemplo, «Implementado en producción») de un elemento de desarrollo. Es un KPI fundamental para medir la eficiencia general del proceso. Es la métrica principal de Dashboards como «Tiempo de ciclo integral del SDLC» y permite hacer un seguimiento de las mejoras e identificar casos de larga duración que podrían indicar problemas sistémicos.
Por qué es importante
Es un KPI fundamental de Process Mining que mide la eficiencia integral del ciclo de vida del desarrollo.
Dónde obtenerlo
La herramienta de Process Mining lo calcula restando el StartTime mínimo del StartTime máximo de cada CaseId único.
Ejemplos
10 días y 4 horas23 horas y 15 minutos35 días
|
|||
|
Tiempo de espera en el traspaso
HandoffWaitTime
|
Tiempo de inactividad calculado entre dos actividades consecutivas realizadas por distintos responsables asignados. | ||
|
Descripción
Esta métrica calcula el tiempo transcurrido entre la finalización de una actividad y el inicio de la siguiente, cuando cambia la persona responsable. Por ejemplo, mide el tiempo desde que un desarrollador termina su trabajo hasta que una persona revisora comienza la revisión del código. Es la métrica clave del KPI «Tiempo medio de espera en el traspaso». Ayuda a descubrir ineficiencias ocultas en la asignación de recursos y la comunicación entre equipos o personas, y pone de manifiesto las demoras que no corresponden a trabajo activo.
Por qué es importante
Cuantifica el tiempo de inactividad durante los traspasos entre personas o equipos y revela demoras ocultas y cuellos de botella en la comunicación.
Dónde obtenerlo
La herramienta de Process Mining lo calcula analizando eventos consecutivos de un caso, comprobando si cambia el campo «Assignee» y calculando la diferencia de tiempo.
Ejemplos
1 día y 2 horas15 minutos8 horas
|
|||
|
Título del hito
MilestoneTitle
|
Título del hito o sprint al que está asignado el elemento de desarrollo. | ||
|
Descripción
En GitLab, los hitos permiten hacer un seguimiento del trabajo en función de un objetivo o un periodo definido, como un sprint o una versión de lanzamiento. Este atributo registra el nombre o título del hito. Permite analizar el rendimiento del proceso en el contexto de sprints o periodos de planificación específicos. Puede utilizarse para comprobar si el tiempo de ciclo mejora de un sprint al siguiente o para filtrar la vista del proceso y mostrar solo el trabajo relacionado con un próximo lanzamiento.
Por qué es importante
Relaciona el trabajo de desarrollo con ciclos de planificación, como sprints o lanzamientos, y permite analizar el rendimiento respecto a los periodos previstos.
Dónde obtenerlo
Se obtiene del campo «milestone.title» de las respuestas de la API de GitLab Issues o Merge Requests.
Ejemplos
Lanzamiento del cuarto trimestre de 2023Sprint 23.11Fase 1: producto mínimo viable
|
|||
|
Última actualización de los datos
LastDataUpdate
|
Marca de tiempo que indica cuándo se actualizaron por última vez en el sistema de origen los datos de este evento. | ||
|
Descripción
Este atributo registra la fecha y hora en que se extrajeron o actualizaron por última vez los datos del evento en el conjunto de datos de Process Mining. No indica cuándo ocurrió el evento, sino cuándo se sincronizó por última vez su registro. Esta información es esencial para conocer la actualidad de los datos y comprobar que el análisis del proceso se basa en información reciente. Ayuda a confiar en que los Dashboards y los KPI utilizan datos actualizados y permite conocer el posible desfase entre el sistema de origen y el análisis.
Por qué es importante
Aporta transparencia sobre la actualidad de los datos y permite saber hasta qué fecha está actualizado el análisis del proceso.
Dónde obtenerlo
La herramienta de extracción de datos o el proceso ETL genera y registra esta marca de tiempo al actualizar los datos.
Ejemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Versión de lanzamiento
ReleaseVersion
|
Etiqueta de la versión de software prevista o real asociada a la implementación. | ||
|
Descripción
Este atributo identifica la versión de software específica a la que pertenece un elemento de desarrollo. En GitLab, puede asociarse mediante un hito, una etiqueta protegida o una entrada en la función Releases. Es esencial para el Dashboard «Seguimiento del cumplimiento del calendario de lanzamientos». Al comparar la fecha real de implementación con la fecha prevista para la versión, las organizaciones pueden medir su capacidad para cumplir el calendario y determinar las causas de las demoras en los lanzamientos.
Por qué es importante
Vincula los elementos de desarrollo con una versión de software específica, algo fundamental para seguir el avance de los lanzamientos y el cumplimiento del calendario.
Dónde obtenerlo
Puede obtenerse de GitLab Releases, del nombre de una etiqueta de git o del título de un hito utilizado para planificar el lanzamiento.
Ejemplos
v1.2.0v3.0.0-beta2023.4.1
|
|||
Actividades del ciclo de vida del desarrollo de software
| Actividad | Descripción | ||
|---|---|---|---|
|
Implementado en producción
|
Esta actividad marca la implementación correcta del código en el entorno de producción, donde queda disponible para los usuarios finales. Se registra cuando finaliza correctamente un trabajo específico de 'deploy to production' en un pipeline de CI/CD de GitLab. | ||
|
Por qué es importante
Este es el evento de fin principal del proceso e indica que se ha entregado valor. Es esencial para medir el tiempo de ciclo total del SDLC de principio a fin y la frecuencia de publicación.
Dónde obtenerlo
Se obtiene de la marca de tiempo 'finished_at' de un trabajo de CI/CD completado correctamente y designado específicamente para la implementación en producción. La funcionalidad Environments de GitLab registra este evento de forma explícita.
Capturar
Utilice la marca de tiempo 'finished_at' del trabajo de CI completado correctamente para la implementación en producción.
Tipo de evento
explicit
|
|||
|
Incidencia creada
|
Esta actividad marca el inicio del ciclo de vida del desarrollo y corresponde a la creación de un nuevo elemento de trabajo, como una funcionalidad, un error o una tarea. GitLab la registra explícitamente cuando un usuario crea una incidencia y guarda la fecha y hora de creación. | ||
|
Por qué es importante
Este es el evento de inicio principal del proceso integral. Analizar el tiempo transcurrido desde la creación de la incidencia hasta la implementación permite obtener una visión completa del tiempo de ciclo del SDLC.
Dónde obtenerlo
Este evento se registra explícitamente a partir de la marca de tiempo 'created_at' de la tabla 'issues' o mediante la API de Issues. Las notas del sistema también registran la creación.
Capturar
Utilice la marca de tiempo 'created_at' de la incidencia.
Tipo de evento
explicit
|
|||
|
Solicitud de fusión creada
|
Indica que el trabajo inicial de desarrollo ha terminado y que el código está listo para su revisión e integración. Es un evento explícito y fundamental del flujo de trabajo de GitLab, que se registra cuando un desarrollador abre una nueva solicitud de fusión (MR). | ||
|
Por qué es importante
Este hito crítico marca el traspaso del desarrollo a la revisión y las pruebas. Es el punto de partida para analizar todo el ciclo de revisión de código y del pipeline de CI/CD.
Dónde obtenerlo
Este evento se registra explícitamente a partir de la marca de tiempo 'created_at' de la tabla 'merge_requests' o mediante la API de Merge Requests.
Capturar
Utilice la marca de tiempo 'created_at' de la solicitud de fusión.
Tipo de evento
explicit
|
|||
|
Solicitud de fusión integrada
|
Esta actividad señala que el proceso de revisión e integración del código ha finalizado correctamente. Es un evento explícito que se produce cuando un usuario integra la rama de la solicitud de fusión en la rama de destino. | ||
|
Por qué es importante
Este hito importante indica que el desarrollo y la revisión han terminado. Marca el final del tiempo de ciclo de desarrollo y el inicio del tiempo de entrega de la implementación.
Dónde obtenerlo
Este evento se registra explícitamente a partir de la marca de tiempo 'merged_at' de la tabla 'merge_requests'. Al integrar la solicitud, también se genera una nota del sistema.
Capturar
Utilice la marca de tiempo 'merged_at' de la solicitud de fusión.
Tipo de evento
explicit
|
|||
|
Aprobación añadida
|
Representa la aprobación formal de los cambios de código de una solicitud de fusión por parte de un revisor. GitLab registra explícitamente este evento cuando un usuario hace clic en el botón 'Aprobar'. | ||
|
Por qué es importante
Las aprobaciones son controles de calidad clave. Registrarlas ayuda a analizar cuánto se tarda en obtener las aprobaciones necesarias y a garantizar el cumplimiento de las políticas de revisión.
Dónde obtenerlo
Se obtiene de los eventos de aprobación de las solicitudes de fusión. Están disponibles mediante la API de Approvals y también pueden consultarse en el historial de la MR.
Capturar
Utilice la marca de tiempo del registro de eventos de aprobación de la solicitud de fusión.
Tipo de evento
explicit
|
|||
|
Desarrollo iniciado
|
Esta actividad señala el inicio del trabajo activo de programación en la incidencia. Por lo general, se infiere a partir del primer commit de código enviado a una rama asociada con la incidencia, ya que GitLab no cuenta con un botón explícito para iniciar el desarrollo. | ||
|
Por qué es importante
Permite identificar el momento exacto en que comienza el trabajo de desarrollo que aporta valor, medir con precisión la fase de programación y distinguirla del tiempo dedicado a la planificación o a la espera en cola.
Dónde obtenerlo
Se infiere al localizar la marca de tiempo del primer commit en una rama de funcionalidad vinculada a la incidencia. Para ello, es necesario vincular las incidencias con las ramas, normalmente mediante convenciones de nombres o metadatos.
Capturar
Busque la marca de tiempo del primer commit en una rama asociada al ID de la incidencia.
Tipo de evento
inferred
|
|||
|
Implementación iniciada
|
Representa el inicio del proceso de publicación del código en un entorno específico, como el de pruebas o el de producción. En GitLab, corresponde al inicio de un trabajo 'deploy' dentro de un pipeline de CI/CD. | ||
|
Por qué es importante
Registrar el inicio de la implementación permite aislar la duración de esta fase. Es fundamental para medir y optimizar el tiempo de entrega de la implementación.
Dónde obtenerlo
Se obtiene de la marca de tiempo 'started_at' de un trabajo de CI/CD configurado como trabajo de implementación. Forma parte de la funcionalidad Environments and Deployments de GitLab.
Capturar
Utilice la marca de tiempo 'started_at' del registro del trabajo de CI para una tarea de implementación.
Tipo de evento
explicit
|
|||
|
Incidencia asignada
|
Representa la asignación de una incidencia a un desarrollador o equipo específico e indica que ya se ha definido quién se hará cargo del trabajo. GitLab registra explícitamente este evento cada vez que se completa o modifica el campo de responsable de una incidencia. | ||
|
Por qué es importante
Registrar las asignaciones es fundamental para analizar la distribución de recursos, la carga de trabajo de los equipos y los tiempos de transferencia. Ayuda a detectar demoras entre la creación del trabajo y el momento en que alguien se hace cargo.
Dónde obtenerlo
Se obtiene de las notas del sistema de GitLab para la incidencia, donde se registra cuándo se añade o modifica un 'assignee'. La nota incluye la marca de tiempo del evento.
Capturar
Extraiga los eventos 'assignee changed' de las notas del sistema de la incidencia.
Tipo de evento
explicit
|
|||
|
Incidencia cerrada
|
Representa el cierre administrativo final del elemento de trabajo, normalmente después de implementar y verificar los cambios. GitLab registra explícitamente este evento cuando un usuario cierra la incidencia. | ||
|
Por qué es importante
El cierre de una incidencia suele marcar el final de todo el trabajo relacionado. Comparar este momento con el de la implementación puede revelar demoras en la validación posterior o en los procesos administrativos.
Dónde obtenerlo
Este evento se registra explícitamente a partir de la marca de tiempo 'closed_at' de la tabla 'issues' o de la nota del sistema correspondiente.
Capturar
Utilice la marca de tiempo 'closed_at' de la incidencia.
Tipo de evento
explicit
|
|||
|
Pipeline fallido
|
Esta actividad se produce cuando falla una ejecución del pipeline de CI/CD en cualquier etapa, por ejemplo, por un error de compilación o una prueba fallida. GitLab registra explícitamente el estado final de cada pipeline, por lo que es fácil identificar los fallos. | ||
|
Por qué es importante
Los fallos de los pipelines son una de las principales causas de retrabajo. Analizar su frecuencia, duración y causa ayuda a detectar problemas de calidad, pruebas inestables y cuellos de botella en el ciclo de retroalimentación con los desarrolladores.
Dónde obtenerlo
Se identifica mediante el estado 'failed' de un registro del pipeline en la tabla 'ci_pipelines'. La marca de tiempo 'finished_at' indica cuándo se produjo el fallo.
Capturar
Filtre los registros de pipelines con el estado 'failed' y utilice la marca de tiempo 'finished_at'.
Tipo de evento
explicit
|
|||
|
Pipeline iniciado
|
Representa el inicio de un pipeline automatizado de CI/CD, que suele ejecutar compilaciones, pruebas y análisis de seguridad. GitLab crea explícitamente un registro del pipeline con una marca de tiempo de inicio cada vez que se activa, por ejemplo, al realizar un commit o crear una MR. | ||
|
Por qué es importante
Registrar las ejecuciones de los pipelines es esencial para supervisar el estado y la eficiencia de los procesos automatizados de pruebas e integración. Ayuda a identificar cuánto tiempo se dedica a la validación automatizada.
Dónde obtenerlo
Se obtiene de la marca de tiempo 'created_at' o 'started_at' del registro del pipeline en la tabla 'ci_pipelines' o mediante la API de Pipelines.
Capturar
Utilice la marca de tiempo del registro de ejecución del pipeline asociado a la rama de la MR.
Tipo de evento
explicit
|
|||
|
Revisión de código iniciada
|
Marca el inicio de la revisión por pares de una solicitud de fusión. Este evento se infiere a partir de la primera acción relacionada con la revisión, como el primer comentario o hilo publicado por alguien que no sea el autor. | ||
|
Por qué es importante
Medir el tiempo transcurrido desde la creación de la MR hasta el inicio de la revisión permite detectar demoras en la cola. Reducir esta espera es clave para acortar el ciclo total de revisión del código.
Dónde obtenerlo
Se infiere a partir de la marca de tiempo del primer comentario o hilo de revisión de la solicitud de fusión publicado por alguien que no sea su autor. Estos datos están disponibles en las notas del sistema o mediante la API de Notes.
Capturar
Busque la marca de tiempo del primer comentario de un usuario que no sea el autor en una MR.
Tipo de evento
inferred
|
|||
Guías de extracción
¿Listo para comenzar?
Utilice este Template para preparar sus datos y empezar a optimizar el ciclo de vida del desarrollo de software. ¡Empiece hoy mismo a transformar su proceso!
Mejore el ciclo de vida del desarrollo de software: empiece a optimizar ahora
Elimine los cuellos de botella del SDLC, reduzca el tiempo de ciclo un 30 % y mejore la calidad.
No se requiere tarjeta de crédito. Empiece a optimizar de inmediato.