Su Template de datos para el ciclo de vida del desarrollo de software

GitLab
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

Este Template completo le guía por los datos esenciales para analizar el proceso del ciclo de vida del desarrollo de software. Describe los atributos clave que debe recopilar y las actividades que debe seguir, y ofrece indicaciones prácticas para extraer esta información directamente de GitLab. Con este recurso, podrá preparar sus datos para obtener información útil mediante Process Mining.
  • Atributos recomendados para recopilar
  • Actividades clave que debe seguir
  • Guía para extraer los datos
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos del ciclo de vida del desarrollo de software

Estos son los campos de datos recomendados para incluir en el Registro de eventos y realizar un análisis y una optimización completos del ciclo de vida del desarrollo de software.
3 Obligatorio 5 Recomendado 12 Opcional
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 created_at de la incidencia, mientras que la de 'Solicitud de fusión integrada' corresponde a la marca de tiempo merged_at de la solicitud de fusión.

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 assignee o assignees de una incidencia o solicitud de fusión.

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 state que puede ser 'opened' o 'closed'. Para indicar estados más detallados, suelen utilizarse etiquetas con ámbito, por ejemplo, 'Status::Triage', 'Status::In-Dev' y 'Status::In-Review'.

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
Obligatorio Recomendado Opcional

Actividades del ciclo de vida del desarrollo de software

Estos son los pasos clave del proceso y los hitos que debe registrar en el Registro de eventos para descubrir el proceso con precisión e identificar cuellos de botella.
4 Recomendado 8 Opcional
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
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de GitLab

¿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.

Comience su prueba gratuita

No se requiere tarjeta de crédito. Empiece a optimizar de inmediato.