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

GitLab
Su Template de datos del ciclo de vida del desarrollo de software

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

Esta Template completa le guía por los datos esenciales necesarios para analizar el proceso del ciclo de vida del desarrollo de software. Describe los atributos fundamentales que debe recopilar, las actividades clave que debe seguir y ofrece orientación práctica para extraer esta información directamente de GitLab. Con este recurso, podrá preparar sus datos con confianza para realizar un Process Mining útil.
  • Atributos recomendados para recopilar
  • Actividades clave que debe seguir
  • Guía de extracción
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos del ciclo de vida del desarrollo de software

Estos son los campos de datos recomendados para incluir en su registro de eventos y obtener 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
El nombre del paso o evento específico del proceso que se produjo, como 'Issue Created' o 'Merge Request Merged'.
Descripción

El atributo Actividad captura los eventos diferenciados que afectan a un elemento de desarrollo. No se almacenan en un único campo de GitLab, sino que se derivan de diversas acciones y campos de marca de tiempo de Issues, Merge Requests y pipelines de CI/CD. 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 Merge Request son actividades distintas.

Este atributo es fundamental para crear el mapa de procesos, visualizar el Workflow y analizar la secuencia y frecuencia de los eventos. Se utiliza para identificar desviaciones, cuellos de botella entre pasos y rutas habituales del proceso.

Por qué es importante

Define los pasos del mapa de procesos y permite visualizar y analizar el Workflow de desarrollo integral.

Dónde obtenerlo

Se deriva de los tipos de eventos y los cambios de estado del flujo de eventos de GitLab, o mediante la interpretación de campos de marca de tiempo como 'created_at', 'merged_at' y 'closed_at' en Issues y Merge Requests.

Ejemplos
Incidencia creadaDesarrollo iniciadoMerge Request integradaPipeline fallidoImplementado en producción
Elemento de desarrollo
DevelopmentItem
El identificador único de una unidad de trabajo, como una funcionalidad, una corrección de errores o una tarea, que actúa como identificador principal del caso.
Descripción

El elemento de desarrollo representa una unidad de trabajo individual y trazable que avanza por el ciclo de vida del desarrollo de software. Conecta todas las actividades relacionadas, desde la creación hasta la implementación final, en un caso coherente. En GitLab, normalmente se representa mediante el ID interno (IID) de la Issue, que es único dentro de un proyecto.

Analizar por elemento de desarrollo permite medir el tiempo de ciclo integral, identificar cuellos de botella y comprobar la conformidad del proceso. Constituye la base para comprender con qué eficiencia se entrega el trabajo desde el concepto hasta producción.

Por qué es importante

Este es el identificador de caso esencial que conecta todos los eventos del proceso y permite rastrear el ciclo de vida completo de cualquier elemento de trabajo.

Dónde obtenerlo

Normalmente es el ID interno (IID) de una Issue de GitLab. Puede encontrarse en la respuesta de la API de Issues, en el campo 'iid'.

Ejemplos
1024512PRJ-2345
Hora de inicio
StartTime
La 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 los eventos de GitLab, se captura en distintos campos de marca de tiempo. Por ejemplo, el StartTime de la actividad 'Issue Created' sería la marca de tiempo 'created_at' de la incidencia, mientras que el StartTime de la actividad 'Merge Request Merged' sería la marca de tiempo 'merged_at' de la Merge Request.

Esta marca de tiempo es el elemento temporal central 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

Proporciona la secuencia cronológica de los eventos, esencial para calcular todas las métricas basadas en el tiempo y comprender el flujo del proceso.

Dónde obtenerlo

Se extrae de varios campos de marca de tiempo de GitLab, como 'created_at', 'updated_at' y 'closed_at' en las incidencias, y 'merged_at' en las Merge Requests.

Ejemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Hora de finalización
EndTime
La marca de tiempo que indica cuándo se completó una actividad o un evento.
Descripción

EndTime indica la fecha y hora exactas en que finalizó una actividad. En muchos eventos atómicos de GitLab, como 'Issue Created', el EndTime coincide con el StartTime. En las actividades con duración, como 'Code Review', representa 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). Ayuda a realizar un análisis detallado de los cuellos de botella al distinguir entre el tiempo dedicado activamente a una tarea y el tiempo de espera entre tareas.

Por qué es importante

Permite calcular la duración precisa de las actividades (tiempos de procesamiento), un aspecto clave para identificar pasos ineficientes del proceso.

Dónde obtenerlo

En los eventos atómicos, coincide con StartTime. En las actividades con duración, debe derivarse identificando en los datos el evento de finalización correspondiente.

Ejemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Nombre del proyecto
ProjectName
El 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 en el que se realiza el trabajo. En GitLab, cada Issue y Merge Request se encuentra dentro de un proyecto.

Analizar por nombre del proyecto permite comparar el rendimiento entre distintos productos, componentes o servicios. También puede ayudar a identificar si determinados proyectos tienen procesos SDLC más saludables que otros y resulta útil para filtrar Dashboards a un área de interés específica.

Por qué es importante

Permite segmentar el análisis del proceso por producto, aplicación o componente, lo que facilita iniciativas de mejora 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
El usuario asignado a la incidencia o Merge Request en el momento del evento.
Descripción

El responsable es el desarrollador o usuario individual encargado del elemento de trabajo en un momento determinado del proceso. En GitLab, se captura en el campo assignee o assignees de una Issue o Merge Request.

Analizar por responsable es fundamental para el Dashboard de 'Developer Workload & Allocation'. Ayuda a comprender el uso de los recursos, identificar personas o equipos sobrecargados y analizar las transferencias entre distintas personas.

Por qué es importante

Registra quién realizó el trabajo, lo que permite analizar la carga de trabajo, la eficiencia de la asignación de recursos e identificar retrasos causados por transferencias.

Dónde obtenerlo

Se obtiene de los campos 'assignee.username' o 'assignees' de las respuestas de la API de GitLab para Issues y Merge Requests.

Ejemplos
jdoeasmithr.williams
Severidad
Severity
El nivel de severidad del elemento de desarrollo, normalmente en el caso de errores o incidencias.
Descripción

La severidad indica el impacto de un error o una incidencia, desde crítico hasta menor. GitLab no dispone de un campo de severidad nativo, por lo que casi siempre se implementa mediante etiquetas, como 'severity::1' o 'severity::2'.

Este atributo es esencial para el Dashboard de 'Severity Escalation Trends' y el KPI asociado. Analizar los cambios de severidad a lo largo del ciclo de vida puede poner de manifiesto incidencias inicialmente subestimadas o procesos que agravan los problemas.

Por qué es importante

Ayuda a priorizar el trabajo y a analizar si los elementos de alta severidad se gestionan más rápido. Registrar los cambios respalda el KPI 'Severity Escalation Frequency'.

Dónde obtenerlo

Se deriva de las 'labels' aplicadas a una Issue de GitLab. Es necesario establecer una asignación para interpretar etiquetas como 'S1' y 'S2' como niveles de severidad.

Ejemplos
1 - Crítico2 - Alto3 - Medio4 - Bajo
Tipo de elemento de desarrollo
DevelopmentItemType
La clasificación del elemento de desarrollo, como 'Feature', 'Bug', 'Task' o 'Maintenance'.
Descripción

Este atributo categoriza la naturaleza del trabajo realizado. En GitLab, normalmente se implementa mediante etiquetas en una incidencia. Los equipos utilizan etiquetas para distinguir entre nuevas funcionalidades, resolución de defectos, deuda técnica y otros tipos de trabajo.

Analizar por tipo de elemento de desarrollo permite comparar los flujos de proceso y los tiempos de ciclo de distintos tipos de trabajo. Por ejemplo, puede analizar 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 ciertos tipos de trabajo son más propensos a sufrir retrasos, retrabajo o desviaciones.

Dónde obtenerlo

Normalmente se deriva de las 'labels' aplicadas a una Issue 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 bucle de retrabajo.
Descripción

Este atributo calculado identifica las actividades que representan un retroceso en el proceso, como volver al desarrollo después de que ya haya comenzado la fase de pruebas. La lógica de este indicador suele consistir en detectar secuencias concretas de actividades, por ejemplo, un evento 'Development Started' que ocurre después de un evento 'Pipeline Failed' o 'QA Testing Started' para el mismo caso.

Este atributo alimenta directamente el Dashboard 'Análisis de retrabajo y ejecuciones repetidas' y el KPI 'Tasa de retrabajo después de las pruebas'. Permite filtrar y cuantificar fácilmente el retrabajo, ayudando a los equipos a comprender su frecuencia, sus causas y su impacto en los plazos del proyecto.

Por qué es importante

Identifica y cuantifica directamente el retrabajo, lo que facilita el análisis de las causas y el impacto de las ineficiencias del proceso y de 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 Merge Request
MergeRequestStatus
El estado de la Merge Request asociada al evento, como 'Opened', 'Merged' o 'Closed'.
Descripción

Este atributo registra el estado de una Merge Request (MR) en el momento de un evento. Las MR de GitLab tienen estados diferenciados: 'opened', 'closed', 'merged' o 'locked'. Este estado es independiente del estado general del elemento de desarrollo.

Registrar el estado de la MR es fundamental para analizar la fase de integración del código del SDLC. Es compatible directamente con Dashboards como "Tiempo de ciclo y rendimiento de la revisión de código" y ayuda a localizar demoras entre la creación, la revisión, la aprobación y la fusión de una MR.

Por qué es importante

Proporciona visibilidad sobre el proceso de revisión e integración del código, que a menudo constituye un cuello de botella crítico del SDLC.

Dónde obtenerlo

Se obtiene del campo 'state' de la respuesta de la API de GitLab para Merge Requests.

Ejemplos
abiertofusionadocerradobloqueado
Estado del elemento de desarrollo
DevelopmentItemStatus
El estado del elemento de desarrollo en el momento del evento, como 'Open', 'In Progress' o 'Closed'.
Descripción

Este atributo refleja el estado del elemento de trabajo principal, normalmente una Issue en GitLab. Las Issues de GitLab tienen un state que puede ser 'opened' o 'closed'. Los estados más detallados suelen gestionarse mediante etiquetas con ámbito, por ejemplo, 'Status::Triage', 'Status::In-Dev' y 'Status::In-Review'.

Registrar los cambios de estado es fundamental para comprender el ciclo de vida del caso. Permite identificar cuánto tiempo pasan los elementos en cada estado y filtrar el trabajo activo o completado en Dashboards como "Tiempo de ciclo de extremo a extremo del SDLC".

Por qué es importante

Proporciona una instantánea del estado del caso, permite analizar el tiempo dedicado a las distintas etapas y filtrar el trabajo en curso frente al completado.

Dónde obtenerlo

El estado principal procede del campo 'state' de una Issue de GitLab ('opened', 'closed'). Los estados más detallados suelen derivarse de las etiquetas.

Ejemplos
abiertocerradoEn progresoEn revisión
Estado del pipeline
PipelineStatus
El estado de la ejecución del pipeline de CI/CD, como 'Success', 'Failed' o 'Running'.
Descripción

Este atributo indica el resultado de la ejecución de un pipeline de CI/CD asociado a un commit o una Merge Request. Entre los estados habituales de GitLab se incluyen 'running', 'pending', 'success', 'failed', 'canceled' y 'skipped'.

Estos datos son esenciales para el Dashboard de 'Rework & Rerun Analysis'. Los fallos frecuentes de los pipelines pueden ser una fuente importante de retrabajo y retrasos, por lo que 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 el éxito y los fallos de las compilaciones y pruebas automatizadas, y pone de relieve los ciclos de retrabajo y los 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 para CI/CD Pipelines.

Ejemplos
éxitofallidoen ejecucióncancelado
Nombre del equipo
TeamName
El equipo de desarrollo asociado al proyecto o al responsable.
Descripción

Nombre del equipo representa el grupo o equipo responsable del elemento de desarrollo. Normalmente no es un campo estándar de GitLab y suele derivarse de las convenciones de nomenclatura de los proyectos, las estructuras de grupos o la asignación de responsables a sus equipos correspondientes mediante una tabla de referencia externa.

Este atributo se utiliza para analizar el rendimiento del proceso por equipo. Permite comparar la eficiencia, la carga de trabajo y el cumplimiento del proceso entre distintos equipos, y facilita Dashboards como "Análisis de Bottleneck por etapa" desde una perspectiva basada en equipos.

Por qué es importante

Permite analizar el rendimiento y comparar el proceso entre distintos equipos, lo que ayuda a identificar cuellos de botella o buenas prácticas específicos de cada equipo.

Dónde obtenerlo

A menudo se deriva de la asignación del nombre del proyecto o del responsable a una estructura de equipos definida fuera de GitLab, o se infiere a partir de las jerarquías de grupos de GitLab.

Ejemplos
Frontend-AlphaBackend-ServicesPlatform-Infra
Rama de destino
TargetBranch
El nombre de la rama de destino de una Merge Request.
Descripción

La rama de destino es la rama en la que se pretende integrar los cambios, por ejemplo, 'main', 'develop' o una rama de versión como 'release/1.5'. Es un dato esencial de cualquier Merge Request.

Analizar por rama de destino puede revelar comportamientos diferentes del proceso según el destino de la integración. Por ejemplo, las integraciones en 'main' pueden tener un proceso de aprobación más riguroso y tiempos de ciclo más largos que las integraciones en una rama de funcionalidad. También puede ayudar a distinguir las implementaciones en producción de otros tipos de integración de código.

Por qué es importante

Ayuda a diferenciar entre distintos Workflow de desarrollo y publicación, 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 para Merge Requests.

Ejemplos
maindeveloprelease/v2.1.0hotfix/user-auth-bug
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, el valor será siempre 'GitLab'.

Incluir este atributo es fundamental en entornos donde los datos del proceso pueden combinarse desde 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

Garantiza la claridad sobre 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 el proceso de transformación de datos.

Ejemplos
GitLab
Tiempo de ciclo
CycleTime
El 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. Normalmente se calcula como la diferencia de tiempo entre el primer evento, por ejemplo, 'Issue Created', y el último evento, por ejemplo, 'Deployed to Production', de un único elemento de desarrollo.

Es un KPI principal para medir la eficiencia general del proceso. Constituye la métrica clave de Dashboards como 'Tiempo de ciclo integral del SDLC' y se utiliza para realizar el seguimiento de las mejoras e identificar casos de larga duración que pueden 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 para cada CaseId único.

Ejemplos
10 días y 4 horas23 horas y 15 minutos35 días
Tiempo de espera en la transferencia
HandoffWaitTime
Tiempo de inactividad calculado entre dos actividades consecutivas realizadas por personas responsables diferentes.
Descripción

Esta métrica calcula la duración del intervalo entre la finalización de una actividad y el inicio de la siguiente, específicamente cuando cambia la persona responsable. Por ejemplo, mide el tiempo desde que un desarrollador termina su trabajo hasta que una persona revisora inicia la revisión del código.

Es la métrica clave del KPI 'Tiempo medio de espera en la transferencia'. Ayuda a descubrir ineficiencias ocultas en la asignación de recursos y la comunicación entre equipos o personas, y pone de manifiesto retrasos que no forman parte de ningún trabajo activo.

Por qué es importante

Cuantifica el tiempo de inactividad durante las transferencias entre distintas personas o equipos, y revela retrasos ocultos y cuellos de botella de comunicación.

Dónde obtenerlo

La herramienta de Process Mining lo calcula analizando eventos consecutivos dentro de un caso, comprobando si el 'Assignee' es diferente y calculando después la diferencia de tiempo.

Ejemplos
1 día y 2 horas15 minutos8 horas
Título del hito
MilestoneTitle
El título del hito o sprint al que está asignado el elemento de desarrollo.
Descripción

En GitLab, un hito se utiliza para realizar el seguimiento del trabajo respecto a un objetivo o periodo de tiempo concreto, como un sprint o una versión de lanzamiento. Este atributo recoge el nombre o título de ese hito.

Este atributo permite analizar el rendimiento del proceso en el contexto de sprints o periodos de planificación específicos. Puede utilizarse para comprobar si los tiempos de ciclo mejoran de un sprint al siguiente o para filtrar la vista del proceso y mostrar únicamente el trabajo relacionado con un próximo lanzamiento.

Por qué es importante

Vincula el trabajo de desarrollo con ciclos de planificación, como sprints o lanzamientos, y permite analizar el rendimiento respecto a periodos planificados.

Dónde obtenerlo

Se obtiene del campo 'milestone.title' en las respuestas de la API de GitLab Issues o Merge Requests.

Ejemplos
Versión Q4 de 2023Sprint 23.11Fase 1: MVP
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este evento desde el sistema de origen.
Descripción

Este atributo registra la fecha y la hora en que los datos de eventos se extrajeron o actualizaron por última vez en el conjunto de datos de Process Mining. No representa cuándo ocurrió el evento, sino cuándo se sincronizó por última vez el registro del evento.

Esta información es fundamental para comprender la actualidad de los datos y validar la puntualidad del análisis del proceso. Ayuda a confiar en que los Dashboards y los KPI se basan en datos recientes, y muestra el posible desfase entre el sistema de origen y el análisis.

Por qué es importante

Proporciona transparencia sobre la actualidad de los datos y garantiza que los usuarios sepan hasta qué punto está actualizado el análisis del proceso.

Dónde obtenerlo

Esta marca de tiempo la genera y registra la herramienta de extracción de datos o el proceso ETL cuando se actualizan los datos.

Ejemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Versión de lanzamiento
ReleaseVersion
La etiqueta de versión de software planificada o real asociada con el despliegue.
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 de la función Releases.

Es esencial para el Dashboard 'Seguimiento del cumplimiento del calendario de lanzamientos'. Al comparar la fecha real de despliegue con la fecha planificada asociada a la versión de lanzamiento, las organizaciones pueden medir su capacidad para cumplir los plazos y diagnosticar las causas de los retrasos.

Por qué es importante

Conecta los elementos de desarrollo con una versión de software específica, algo fundamental para realizar el seguimiento del progreso y del cumplimiento del calendario de lanzamientos.

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 y los hitos del proceso que debe capturar en su 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 activo, donde queda disponible para los usuarios finales. Se captura cuando un job específico de 'deploy to production' de un pipeline de CI/CD de GitLab finaliza correctamente.
Por qué es importante

Este es el evento final principal del proceso e indica que se ha entregado valor. Es esencial para medir el tiempo de ciclo total e integral del SDLC y la frecuencia de las versiones.

Dónde obtenerlo

Se captura a partir de la marca de tiempo 'finished_at' de un job de CI/CD completado correctamente y designado específicamente para la implementación en producción. La funcionalidad Environments de GitLab lo registra de forma explícita.

Recopilar

Utilice la marca de tiempo 'finished_at' del job de CI de implementación en producción completado correctamente.

Tipo de evento explicit
Incidencia creada
Esta actividad marca el inicio del ciclo de vida del desarrollo y representa la creación de un nuevo elemento de trabajo, como una funcionalidad, un error o una tarea. Se registra explícitamente cuando un usuario crea una nueva incidencia en GitLab, que guarda la marca de tiempo 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 ofrece una visión completa del tiempo de ciclo del SDLC.

Dónde obtenerlo

Este es un evento explícito capturado 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 el evento de creación.

Recopilar

Utilice la marca de tiempo 'created_at' de la incidencia.

Tipo de evento explicit
Merge Request creada
Indica que el trabajo inicial de desarrollo ha terminado y que el código está listo para revisión e integración. Es un evento explícito y esencial del Workflow de GitLab, que se captura cuando un desarrollador abre una nueva Merge Request (MR).
Por qué es importante

Este es un hito crítico que marca la transición del desarrollo a la revisión y las pruebas. Es el punto de entrada para analizar todo el ciclo de revisión de código y CI/CD.

Dónde obtenerlo

Este es un evento explícito capturado a partir de la marca de tiempo 'created_at' de la tabla 'merge_requests' o mediante la API de Merge Requests.

Recopilar

Utilice la marca de tiempo 'created_at' de la Merge Request.

Tipo de evento explicit
Merge Request integrada
Esta actividad indica que el proceso de revisión e integración del código se ha completado correctamente. Es un evento explícito que se produce cuando un usuario integra la rama de la Merge Request en la rama de destino.
Por qué es importante

Este es un hito importante que indica que el desarrollo y la revisión han terminado. Sirve como punto final para medir el tiempo de ciclo del desarrollo y como punto inicial para medir el plazo de entrega a producción.

Dónde obtenerlo

Este es un evento explícito capturado a partir de la marca de tiempo 'merged_at' de la tabla 'merge_requests'. Al integrar la MR también se genera una nota del sistema.

Recopilar

Utilice la marca de tiempo 'merged_at' de la Merge Request.

Tipo de evento explicit
Aprobación añadida
Representa la aprobación formal de los cambios de código de una Merge Request por parte de un revisor. Es un evento explícito que GitLab captura cuando un usuario hace clic en el botón 'Approve'.
Por qué es importante

Las aprobaciones son controles de calidad clave. Registrarlas ayuda a analizar cuánto tiempo se necesita para obtener las aprobaciones requeridas y garantiza el cumplimiento de las políticas de revisión.

Dónde obtenerlo

Se captura a partir de los eventos de aprobación de la Merge Request. Estos datos están disponibles mediante la API de Approvals o pueden consultarse en el historial de la MR.

Recopilar

Utilice la marca de tiempo del registro de eventos de aprobación de la Merge Request.

Tipo de evento explicit
Desarrollo iniciado
Esta actividad indica el inicio del trabajo activo de programación sobre la incidencia. Normalmente se infiere a partir del primer commit de código enviado a una rama asociada a la incidencia, ya que GitLab no dispone de un botón explícito de 'inicio del desarrollo'.
Por qué es importante

Identifica el inicio exacto del trabajo de desarrollo que aporta valor, lo que permite medir con precisión la fase de programación y separarla del tiempo de planificación o de espera en cola.

Dónde obtenerlo

Se infiere a partir de la marca de tiempo del primer commit en una rama de funcionalidad vinculada a la incidencia. Para ello es necesario relacionar las incidencias con las ramas, normalmente mediante convenciones de nombres o metadatos.

Recopilar

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 para publicar código en un entorno específico, como staging o producción. En GitLab, corresponde al inicio de un job 'deploy' dentro de un pipeline de CI/CD.
Por qué es importante

Registrar el inicio de la implementación ayuda a aislar la duración de esta fase. Es fundamental para medir y optimizar el plazo de entrega a producción.

Dónde obtenerlo

Se captura a partir de la marca de tiempo 'started_at' de un job de CI/CD configurado como job de implementación. Forma parte de la funcionalidad Environments and Deployments de GitLab.

Recopilar

Utilice la marca de tiempo 'started_at' del registro del job de CI correspondiente a 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 se ha establecido la responsabilidad sobre el 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 del equipo y los tiempos de transferencia. Ayuda a identificar retrasos entre la creación del trabajo y el momento en que alguien lo asume.

Dónde obtenerlo

Se captura a partir de las notas del sistema de GitLab de la incidencia, que registran cuándo se añade o modifica un 'assignee'. La marca de tiempo del evento queda registrada en la nota.

Recopilar

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 sus cambios. Es un evento explícito que se captura cuando un usuario cierra la incidencia en GitLab.
Por qué es importante

Cerrar una incidencia suele indicar el final de todo el trabajo relacionado. Comparar este momento con el de la implementación puede revelar retrasos en la validación posterior a la implementación o en los procesos administrativos.

Dónde obtenerlo

Este es un evento explícito capturado a partir de la marca de tiempo 'closed_at' de la tabla 'issues' o de la nota del sistema correspondiente.

Recopilar

Utilice la marca de tiempo 'closed_at' de la incidencia.

Tipo de evento explicit
Pipeline fallido
Esta actividad se produce cuando una ejecución de CI/CD falla en cualquier etapa, por ejemplo, debido a un error de compilación o a una prueba fallida. GitLab registra explícitamente el estado final de cada pipeline, por lo que los fallos son fáciles de identificar.
Por qué es importante

Los fallos de los pipelines son una de las principales causas del retrabajo. Analizar su frecuencia, duración y causa ayuda a identificar problemas de calidad, pruebas inestables y cuellos de botella en el ciclo de feedback para los desarrolladores.

Dónde obtenerlo

Se identifica mediante un estado 'failed' en el registro de un pipeline de la tabla 'ci_pipelines'. La marca de tiempo 'finished_at' indica cuándo se produjo el fallo.

Recopilar

Filtre los registros de pipelines con 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 normalmente ejecuta 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 un pipeline, por ejemplo, mediante un commit o la creación de 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 captura a partir de la marca de tiempo 'created_at' o 'started_at' del registro de un pipeline en la tabla 'ci_pipelines' o mediante la API de Pipelines.

Recopilar

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 del proceso de revisión por pares de una Merge Request. 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 distinto del autor.
Por qué es importante

Medir el tiempo desde la creación de la MR hasta el inicio de la revisión pone de manifiesto los retrasos en cola. Reducir este tiempo de espera es clave para acortar el ciclo general de revisión de código.

Dónde obtenerlo

Se infiere a partir de la marca de tiempo del primer comentario o hilo de revisión de la Merge Request que no procede del autor de la MR. Estos datos están disponibles mediante las notas del sistema o la API de Notes.

Recopilar

Busque la marca de tiempo del primer comentario de usuario en una MR realizado por alguien distinto del autor.

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de GitLab

¿Listo para empezar?

Utilice esta Template para preparar sus datos y comenzar a optimizar su ciclo de vida del desarrollo de software. ¡Empiece hoy mismo a transformar su proceso!

Impulse su ciclo de vida del desarrollo de software: empiece a optimizarlo ahora

Elimine los cuellos de botella del SDLC, reduzca el tiempo de ciclo un 30 % y mejore la calidad.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Empiece a optimizar de inmediato.