Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

GitLab
Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

Esta `template` integral le guía a través de los puntos de datos esenciales necesarios para analizar su proceso de Ciclo de Vida de Desarrollo de Software. Describe los atributos cruciales a recopilar, las actividades clave a seguir y proporciona orientación práctica para extraer esta información directamente de GitLab. Con este recurso, puede preparar con confianza sus datos para un `process mining` perspicaz.
  • Atributos recomendados para recopilar
  • Actividades clave para el seguimiento
  • Guía de Extracción
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos del Ciclo de Vida de Desarrollo de Software

Estos son los campos de datos recomendados para incluir en su registro de eventos (`event log`) para un análisis y optimización exhaustivos del ciclo de vida de desarrollo de software.
3 Requerido 5 Recomendado 13 Opcional
Nombre Descripción
Actividad
Activity
El nombre del paso de proceso o evento específico que ocurrió, como '`Issue` Creada' o '`Merge Request` Fusionado'.
Descripción

El atributo Actividad captura los eventos distintos que le ocurren a un Elemento de Desarrollo. Estos no se almacenan como un único campo en GitLab, sino que se derivan de varias acciones y campos de timestamp en Issues, Merge Requests y CI/CD Pipelines. Por ejemplo, la creación de una issue, un commit siendo enviado (pushed), un pipeline fallando o un merge request siendo aprobado son todas actividades distintas.

Este atributo es fundamental para construir 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 de proceso comunes.

Por qué es importante

Define los pasos en el mapa de procesos, permitiendo la visualización y el análisis del workflow de desarrollo de principio a fin.

Dónde obtener

Se deriva de los tipos de eventos y cambios de estado en el flujo de datos de GitLab, o interpretando campos de marca de tiempo como 'created_at', 'merged_at' y 'closed_at' en incidencias y merge requests.

Ejemplos
Incidencia CreadaDesarrollo Iniciado`Merge Request` Fusionado`Pipeline` FallidoDesplegado a Producción
Elemento de Desarrollo
DevelopmentItem
El identificador único para una unidad de trabajo, como una característica, corrección de `bug` o tarea, que sirve como identificador principal del caso.
Descripción

El Elemento de Desarrollo representa una pieza de trabajo única y rastreable que fluye a través del ciclo de vida de desarrollo de software. Conecta todas las actividades relacionadas, desde la creación hasta el despliegue final, en un caso coherente. En GitLab, esto se representa típicamente por el ID interno (IID) de la Issue, que es único dentro de un proyecto.

Analizar por Elemento de Desarrollo permite la medición del tiempo de ciclo de principio a fin, la identificación de cuellos de botella y la verificación de la conformidad del proceso. Constituye la base para comprender con qué eficiencia se entrega el trabajo desde el concepto hasta la producción.

Por qué es importante

Este es el identificador de caso esencial que vincula todos los eventos del proceso, haciendo posible trazar el ciclo de vida completo de cualquier elemento de trabajo dado.

Dónde obtener

Este es típicamente el ID interno (IID) de una Issue de GitLab. Se puede encontrar en la respuesta de la API de Issues como el campo 'iid'.

Ejemplos
1024512PRJ-2345
Hora de Inicio
StartTime
El timestamp que indica cuándo comenzó una *actividad* o un *evento*.
Descripción

StartTime marca la fecha y hora precisas en que ocurrió una actividad específica. Para los eventos en GitLab, esto se captura en varios campos de timestamp. Por ejemplo, el StartTime de la actividad 'Issue Creada' sería el timestamp created_at de la issue, mientras que el StartTime de la actividad 'Merge Request Fusionado' sería el timestamp merged_at del merge request.

Esta marca de tiempo es el elemento temporal central en el process mining. Se utiliza para ordenar los eventos cronológicamente, calcular las duraciones 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 eventos, que es esencial para calcular todas las métricas basadas en el tiempo y comprender el flujo del proceso.

Dónde obtener

Se extrae de varios campos de marca de tiempo en GitLab, como 'created_at', 'updated_at' o 'closed_at' en incidencias, y 'merged_at' en merge requests.

Ejemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Asignado
Assignee
El usuario asignado a la `issue` o `merge request` en el momento del evento.
Descripción

El Responsable (Assignee) es el desarrollador o usuario individual responsable del elemento de trabajo en un momento dado del proceso. En GitLab, esto se captura en el campo assignee o assignees de una Issue o Merge Request.

Analizar por Responsable es fundamental para el dashboard de 'Carga de Trabajo y Asignación de Desarrolladores'. Ayuda a comprender la utilización de recursos, identificar individuos o equipos sobrecargados y analizar los traspasos (handoffs) entre diferentes personas.

Por qué es importante

Rastrea quién realizó el trabajo, permitiendo el análisis de la carga de trabajo, la eficiencia en la asignación de recursos y la identificación de retrasos causados por los traspasos.

Dónde obtener

Obtenido de los campos 'assignee.username' o 'assignees' en las respuestas de la API de Issues y Merge Requests de GitLab.

Ejemplos
jdoeasmithr.williams
Hora de Finalización
EndTime
La marca de tiempo que indica cuándo se completó una actividad o evento.
Descripción

El EndTime indica la fecha y hora exactas en que finalizó una actividad. En eventos instantáneos de GitLab, como 'Issue Created', coincide con el StartTime. En actividades con duración propia, como 'Code Review', representa el momento de finalización (por ejemplo, cuando se da la última aprobación).

Este atributo es indispensable para calcular con precisión cuánto dura cada actividad (Processing Time). Además, facilita el análisis de cuellos de botella al permitir diferenciar el tiempo de trabajo activo del tiempo de espera entre tareas.

Por qué es importante

Permite el cálculo de duraciones precisas de actividad (tiempos de procesamiento), lo cual es clave para identificar pasos ineficientes en el proceso.

Dónde obtener

Para eventos atómicos, esto es lo mismo que StartTime. Para actividades con duración, debe derivarse encontrando un 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
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 donde se está realizando el trabajo. En GitLab, cada issue y merge request está contenido dentro de un proyecto.

Analizar por Nombre del Proyecto permite comparaciones de rendimiento entre diferentes productos, componentes o servicios. Puede ayudar a identificar si ciertos proyectos tienen procesos de SDLC más saludables que otros y es útil para filtrar dashboards a un área de interés específica.

Por qué es importante

Permite segmentar el análisis de procesos por producto, aplicación o componente, facilitando los esfuerzos de mejora dirigidos.

Dónde obtener

Obtenido de los campos 'name' o 'path_with_namespace' en la API del Proyecto, vinculado a través del 'project_id' en Issues y Merge Requests.

Ejemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Severidad
Severity
El nivel de severidad del elemento de desarrollo, típicamente para `bugs` o incidentes.
Descripción

La Severidad indica el impacto de un bug o issue, que va desde crítico hasta menor. GitLab no tiene un campo de severidad nativo, por lo que esto casi siempre se implementa usando labels (por ejemplo, 'severity::1', 'severity::2').

Este atributo es esencial para el dashboard de 'Tendencias de Escalada de Severidad' y el KPI asociado. Analizar los cambios en la severidad a lo largo del ciclo de vida puede resaltar issues que fueron inicialmente subestimadas o procesos que exacerban 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. El seguimiento de los cambios apoya el KPI de 'Frecuencia de Escalada de Severidad'.

Dónde obtener

Derivado de las 'etiquetas' aplicadas a un Issue de GitLab. Se requiere un mapeo para interpretar etiquetas como 'S1', 'S2' como niveles de severidad.

Ejemplos
1 - Crítico2 - Alta3 - Medio4 - Baja
Tipo de Elemento de Desarrollo
DevelopmentItemType
La clasificación del elemento de desarrollo, como 'Funcionalidad', 'Error' (`Bug`), 'Tarea' o 'Mantenimiento'.
Descripción

Este atributo categoriza la naturaleza del trabajo que se realiza. En GitLab, esto se implementa comúnmente usando labels en una issue. Los equipos usan labels para distinguir entre nueva funcionalidad, 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 para diferentes tipos de trabajo. Por ejemplo, se puede analizar si los bugs se resuelven más rápido que el desarrollo de nuevas características, 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 retrasos, retrabajos o desviaciones.

Dónde obtener

Normalmente se deriva de las 'etiquetas' aplicadas a una Incidencia de GitLab. Se requiere una lógica de asignación para traducir etiquetas específicas a tipos estandarizados.

Ejemplos
Característica`Bug`TaskDeuda Técnica
¿Es Retrabajo?
IsRework
Un indicador booleano que señala si una actividad forma parte de un ciclo de reelaboración.
Descripción

Este atributo calculado marca las actividades que representan un paso hacia atrás en el proceso, como volver al desarrollo después de que las pruebas ya hayan comenzado. La lógica para esta bandera típicamente implica detectar secuencias específicas de actividades, por ejemplo, un evento 'Development Started' ocurriendo después de un evento 'Pipeline Failed' o 'QA Testing Started' para el mismo caso.

Este atributo alimenta directamente el dashboard de 'Análisis de Retrabajo y Reejecución' y el KPI de 'Tasa de Retrabajo Después de las Pruebas'. Permite un fácil filtrado y cuantificación del retrabajo, ayudando a los equipos a comprender su frecuencia, causas e impacto en los cronogramas del proyecto.

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 obtener

Calculado por la herramienta de Process Mining mediante el análisis de la secuencia de actividades de cada caso e identificando patrones que indican reprocesos.

Ejemplos
truefalse
Estado del `Merge Request`
MergeRequestStatus
El estado del `merge request` asociado con el evento, como 'Opened', 'Merged' o 'Closed'.
Descripción

Este atributo captura el estado de un Merge Request (MR) en el momento de un evento. Los MR de GitLab tienen estados distintos: 'opened', 'closed', 'merged' o 'locked'. Esto es diferente del Estado General del Elemento de Desarrollo.

Seguir el estado del MR es crucial para analizar la fase de integración de código del SDLC. Apoya directamente dashboards como 'Tiempo de Ciclo y Rendimiento de la Revisión de Código' y ayuda a identificar retrasos entre la creación, revisión, aprobación y fusión del MR.

Por qué es importante

Proporciona visibilidad del proceso de revisión de código y fusión, que a menudo es un cuello de botella crítico en el SDLC.

Dónde obtener

Obtenido del campo 'state' en la respuesta de la API de Merge Requests de GitLab.

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

Este atributo indica el resultado de una ejecución de CI/CD pipeline asociada con un commit o merge request. Los estados comunes en GitLab incluyen 'running', 'pending', 'success', 'failed', 'canceled' y 'skipped'.

Estos datos son esenciales para el dashboard de 'Análisis de Retrabajo y Reejecución'. Los fallos frecuentes del pipeline pueden ser una fuente significativa de retrabajo y retraso, y 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 el fracaso de las compilaciones y pruebas automatizadas, revelando los ciclos de retrabajo y los problemas relacionados con la calidad del código o la automatización de pruebas.

Dónde obtener

Obtenido del campo 'status' en la respuesta de la API de CI/CD Pipelines de GitLab.

Ejemplos
successfallidorunningcancelado
Estado del Elemento de Desarrollo
DevelopmentItemStatus
El estado del elemento de desarrollo en el momento del evento, como 'Abierto', 'En Progreso' o 'Cerrado'.
Descripción

Este atributo refleja el estado del elemento de trabajo principal, típicamente una Issue en GitLab. Las Issues de GitLab tienen un state que puede ser 'opened' o 'closed'. Los estados más granulares a menudo se gestionan utilizando labels con ámbito (por ejemplo, 'Status::Triage', 'Status::In-Dev', 'Status::In-Review').

Seguir los cambios de estado es crucial para comprender el ciclo de vida del caso. Ayuda a identificar cuánto tiempo pasan los elementos en cada estado y puede usarse para filtrar el trabajo activo o completado en dashboards como 'Tiempo de Ciclo de SDLC de Principio a Fin'.

Por qué es importante

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

Dónde obtener

El estado principal proviene del campo 'state' de una Issue de GitLab ('opened', 'closed'). Los estados más detallados a menudo se derivan de labels.

Ejemplos
openedcerradoEn ProgresoEn Revisión
Nombre del Equipo
TeamName
El equipo de desarrollo asociado con el proyecto o el responsable (`assignee`).
Descripción

El Nombre del Equipo representa el grupo o escuadrón responsable del elemento de desarrollo. Esta información típicamente no es un campo estándar en GitLab y a menudo se deriva de las convenciones de nomenclatura del proyecto, las estructuras de grupo, o mapeando los responsables (assignees) a sus respectivos equipos usando una tabla de referencia externa.

Este atributo se utiliza para analizar el rendimiento del proceso a nivel de equipo. Ayuda a comparar la eficiencia, la carga de trabajo y la adhesión al proceso en diferentes equipos, apoyando dashboards como 'Análisis de Cuellos de Botella Específicos de la Etapa' desde una vista basada en el equipo.

Por qué es importante

Permite el análisis de rendimiento y la comparación de procesos entre diferentes equipos, ayudando a identificar cuellos de botella específicos del equipo o mejores prácticas.

Dónde obtener

A menudo se deriva mapeando el Nombre del Proyecto o el Responsable a una estructura de equipo definida fuera de GitLab, o se infiere de las jerarquías de grupos de GitLab.

Ejemplos
Frontend-AlphaServicios de BackendPlatform-Infra
Rama de Destino
TargetBranch
El nombre de la rama de destino para un `merge request`.
Descripción

La Rama de Destino (Target Branch) es la rama en la que se pretende fusionar los cambios, por ejemplo, 'main', 'develop', o una rama de lanzamiento como 'release/1.5'. Esta es una pieza de información central para cualquier Merge Request.

Analizar por Rama de Destino puede revelar diferentes comportamientos de proceso para el código que se fusiona en diferentes destinos. Por ejemplo, las fusiones en 'main' pueden tener un proceso de aprobación más riguroso y tiempos de ciclo más largos que las fusiones en una rama de características. También puede ayudar a distinguir los despliegues de producción de otros tipos de integración de código.

Por qué es importante

Ayuda a diferenciar entre varios workflows de desarrollo y lanzamiento, ya que los procesos pueden variar significativamente según la rama de destino.

Dónde obtener

Obtenido del campo 'target_branch' en la respuesta de la API de Merge Requests de GitLab.

Ejemplos
maindesarrollorelease/v2.1.0hotfix/user-auth-bug
Source System
SourceSystem
Identifica el sistema del cual se obtuvieron los datos.
Descripción

Este atributo especifica el origen de los datos del proceso. Para este modelo de datos, el valor será consistentemente 'GitLab'.

Incluir este atributo es crucial en entornos donde los datos del proceso pueden combinarse de múltiples sistemas, como Jira para la planificación y GitLab para la ejecución. Permite filtrar, segmentar y ayuda a mantener la trazabilidad de los datos.

Por qué es importante

Aporta total claridad sobre el origen de los datos, algo fundamental para la gobernanza y para la integración de información proveniente de múltiples sistemas corporativos.

Dónde obtener

Este es un valor estático, 'GitLab', añadido durante el proceso de transformación de datos.

Ejemplos
GitLab
Tiempo de Ciclo
CycleTime
El tiempo total transcurrido desde la primera actividad hasta la última actividad para un elemento de desarrollo.
Descripción

El Cycle Time (tiempo de ciclo) es una métrica 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 ('Deployed to Production') para un mismo ítem de desarrollo.

Es un KPI fundamental para medir la eficiencia global del proceso. Se utiliza como métrica principal en dashboards como 'SDLC End-to-End Cycle Time' para monitorizar mejoras y detectar casos excesivamente largos que puedan revelar fallos sistémicos.

Por qué es importante

Este es un KPI central de process mining que mide la eficiencia de principio a fin del ciclo de vida de desarrollo.

Dónde obtener

Calculado por la herramienta de Process Mining restando el StartTime mínimo al StartTime máximo para cada CaseId único.

Ejemplos
10 días 4 horas23 horas 15 minutos35 días
Tiempo de Espera en la Entrega
HandoffWaitTime
`Tiempo` de inactividad calculado entre dos actividades consecutivas realizadas por diferentes asignados.
Descripción

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

Esta es la métrica clave para el KPI de 'Tiempo Medio de Espera por Traspaso' (Handoff). Ayuda a descubrir ineficiencias ocultas en la asignación de recursos y la comunicación entre equipos o individuos, destacando los retrasos que no forman parte de ningún trabajo activo.

Por qué es importante

Cuantifica el tiempo de inactividad durante los traspasos entre diferentes personas o equipos, revelando retrasos ocultos y cuellos de botella en la comunicación.

Dónde obtener

Calculado por la herramienta de Process Mining. Requiere el análisis de eventos consecutivos dentro de un caso para verificar si el 'Assignee' ha cambiado y, posteriormente, calcular la diferencia de tiempo.

Ejemplos
1 día 2 horas15 minutos8 horas
Tiempo de Procesamiento
ProcessingTime
La duración de una sola actividad, calculada como la diferencia entre su hora de finalización y su hora de inicio.
Descripción

El tiempo de procesamiento mide el tiempo de trabajo activo para una actividad específica, distinto del tiempo de espera entre actividades. Se calcula como EndTime menos StartTime para un único registro de evento. Para eventos instantáneos, el tiempo de procesamiento es cero.

Esta métrica es crucial para el Análisis de Cuellos de Botella Específicos de la Etapa. Al agregar los tiempos de procesamiento de las actividades dentro de una etapa, como la Revisión de Código, los analistas pueden determinar exactamente cuánto tiempo se dedica activamente a realizar el trabajo, ayudando a identificar pasos de proceso ineficientes.

Por qué es importante

Mide la duración de las actividades individuales, ayudando a distinguir el tiempo de trabajo activo del tiempo de espera inactivo para un análisis preciso de los cuellos de botella.

Dónde obtener

Calculado por la herramienta de Process Mining como la diferencia entre el EndTime y el StartTime de una actividad.

Ejemplos
2 horas 30 minutos0 minutos3 días 8 horas
Título del Hito
MilestoneTitle
El título del `milestone` o `sprint` al que se asigna el elemento de desarrollo.
Descripción

Un Milestone en GitLab se utiliza para rastrear el trabajo frente a un objetivo o marco de tiempo específico, como un sprint o una versión de lanzamiento. Este atributo captura el nombre o título de ese milestone.

Este atributo permite analizar el rendimiento del proceso en el contexto de sprints o períodos de planificación específicos. Puede usarse para ver si los tiempos de ciclo están mejorando de un sprint a otro o para filtrar la vista del proceso y mostrar solo el trabajo relacionado con un próximo lanzamiento.

Por qué es importante

Vincula el trabajo de desarrollo a ciclos de planificación como sprints o lanzamientos, permitiendo el análisis del rendimiento frente a los timeboxes planificados.

Dónde obtener

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

Ejemplos
Lanzamiento Q4-2023`Sprint` 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 hora en que los datos del evento fueron extraídos o actualizados 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 vital para comprender la actualidad de los datos y validar la puntualidad del análisis del proceso. Ayuda a los usuarios a confiar en que los dashboards y KPI se basan en datos recientes y les informa del posible retraso entre el sistema de origen y el análisis.

Por qué es importante

Proporciona transparencia sobre la actualidad de los datos, asegurando que los usuarios sepan cuán actualizada está el análisis del proceso.

Dónde obtener

Esta marca de tiempo (timestamp) es generada y registrada por la herramienta de extracción de datos o el proceso ETL en el momento de una actualización de 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 el lanzamiento de software específico del que forma parte un elemento de desarrollo. En GitLab, esto se puede asociar a través de un Milestone, una etiqueta protegida (tag) o una entrada en la función de Lanzamientos.

Esto es esencial para el dashboard de 'Seguimiento de Adhesión al Cronograma de Lanzamientos'. Al comparar la fecha de despliegue real con una fecha planificada asociada a la versión de lanzamiento, las organizaciones pueden medir su capacidad para cumplir los cronogramas y diagnosticar las causas de los retrasos en los lanzamientos.

Por qué es importante

Conecta los elementos de desarrollo a un lanzamiento de software específico, lo cual es crucial para rastrear el progreso del lanzamiento y la adherencia al cronograma.

Dónde obtener

Esto se puede obtener de GitLab Releases, el nombre de una etiqueta git (tag), o el título de un milestone utilizado para la planificación de lanzamientos.

Ejemplos
v1.2.0v3.0.0-beta2023.4.1
Requerido Recomendado Opcional

Actividades del Ciclo de Vida de Desarrollo de Software

Estos son los pasos clave del proceso y los hitos a registrar en tu registro de eventos para un descubrimiento preciso del proceso y la identificación de cuellos de botella.
4 Recomendado 8 Opcional
Actividad Descripción
`Merge Request` Creado
Indica que el trabajo de desarrollo inicial está completo y el código está listo para revisión e integración. Este es un evento explícito y central en el `workflow` de GitLab, capturado cuando un desarrollador abre un nuevo `merge request` (`MR`).
Por qué es importante

Este es un milestone crítico que marca el traspaso (handoff) del desarrollo a la revisión y prueba. Es el punto de entrada para analizar todo el ciclo de revisión de código y CI/CD pipeline.

Dónde obtener

Este es un evento explícito capturado de la marca de tiempo created_at en la tabla merge_requests o a través de la API de Merge Requests.

Capturar

Utilice el timestamp 'created_at' de la merge request.

Tipo de evento explicit
`Merge Request` Fusionado
Esta actividad significa la finalización exitosa del proceso de revisión e integración de código. Es un evento explícito que ocurre cuando un usuario fusiona la rama del `merge request` en la rama de destino.
Por qué es importante

Este es un milestone importante que indica que el desarrollo y la revisión están completos. Sirve como punto final para medir el tiempo de ciclo de desarrollo y punto de partida para medir el lead time de despliegue.

Dónde obtener

Este es un evento explícito capturado de la marca de tiempo merged_at en la tabla merge_requests. También se genera una nota del sistema al fusionar.

Capturar

Utilice el timestamp 'merged_at' de la merge request.

Tipo de evento explicit
Desplegado a Producción
Esta actividad marca el despliegue exitoso del código al entorno de producción en vivo, haciéndolo disponible para los usuarios finales. Esto se captura cuando una tarea específica de 'deploy to production' en un `CI/CD pipeline` de GitLab se completa exitosamente.
Por qué es importante

Este es el evento final principal para el proceso, lo que significa que se ha entregado valor. Es esencial para medir el tiempo de ciclo SDLC total de principio a fin y la frecuencia de lanzamiento.

Dónde obtener

Capturado del timestamp 'finished_at' de un job de CI/CD exitoso específicamente designado para el despliegue a producción. La función de entornos de GitLab lo rastrea explícitamente.

Capturar

Utilice el timestamp 'finished_at' del trabajo de CI de despliegue a producción exitoso.

Tipo de evento explicit
Incidencia Creada
Esta actividad marca el comienzo del ciclo de vida de desarrollo, representando la creación de un nuevo elemento de trabajo, como una característica, `bug` o tarea. Se captura explícitamente cuando un usuario crea una nueva `issue` en GitLab, lo que registra la marca de tiempo de creación.
Por qué es importante

Este es el evento de inicio principal para el proceso de principio a fin. Analizar el tiempo desde la creación de la issue hasta el despliegue proporciona una imagen completa del tiempo de ciclo del SDLC.

Dónde obtener

Este es un evento explícito capturado de la marca de tiempo created_at en la tabla issues o a través de la API de Issues. Las notas del sistema también registran el evento de creación.

Capturar

Utilice el timestamp 'created_at' de la incidencia.

Tipo de evento explicit
`Pipeline` Fallido
Esta actividad ocurre cuando la ejecución de un `CI/CD pipeline` falla en cualquier etapa, como un error de `build` o una prueba fallida. GitLab registra explícitamente el estado final de cada `pipeline`, haciendo que los fallos sean fáciles de identificar.
Por qué es importante

Los fallos del pipeline son un motor principal del retrabajo. Analizar su frecuencia, duración y causa ayuda a identificar problemas de calidad, pruebas inestables y cuellos de botella en el bucle de retroalimentación a los desarrolladores.

Dónde obtener

Identificado por un estado 'fallido' en un registro de pipeline en la tabla ci_pipelines. La marca de tiempo finished_at indica cuándo ocurrió el fallo.

Capturar

Filtre los registros de pipeline con estado 'fallido' y utilice la marca de tiempo finished_at.

Tipo de evento explicit
`Pipeline` Iniciado
Representa la iniciación de un `CI/CD pipeline` automatizado, que típicamente ejecuta `builds`, pruebas y escaneos de seguridad. GitLab crea explícitamente un registro de `pipeline` con una marca de tiempo de inicio cada vez que se activa un `pipeline`, por ejemplo, por un `commit` o la creación de un `MR`.
Por qué es importante

El seguimiento de las ejecuciones de pipeline es esencial para monitorear la salud y eficiencia de los procesos automatizados de prueba e integración. Ayuda a identificar cuánto tiempo se dedica a la validación automatizada.

Dónde obtener

Se captura desde la marca de tiempo 'created_at' o 'started_at' de un registro de pipeline en la tabla 'ci_pipelines' o a través de la API de Pipelines.

Capturar

Utilice el timestamp del registro de ejecución de la pipeline asociado a la rama del MR.

Tipo de evento explicit
Aprobación Añadida
Representa una aprobación formal de los cambios de código en un `merge request` por parte de un revisor. Este es un evento explícito capturado por GitLab cuando un usuario hace clic en el botón 'Aprobar'.
Por qué es importante

Las aprobaciones son puertas de calidad clave. Su seguimiento ayuda a analizar el tiempo que se tarda en obtener las aprobaciones requeridas y garantiza el cumplimiento con las políticas de revisión.

Dónde obtener

Capturado de los eventos de aprobación de merge request. Estos están disponibles a través de la API de Aprobaciones o se pueden ver en el historial de MR.

Capturar

Utilice el timestamp del registro de eventos de aprobación de la merge request.

Tipo de evento explicit
Desarrollo Iniciado
Esta actividad significa el inicio del trabajo de codificación activo en la `issue`. Esto se infiere típicamente del primer `commit` de código enviado (`pushed`) a una rama asociada con la `issue`, ya que GitLab no tiene un botón explícito de 'start development'.
Por qué es importante

Identifica el inicio exacto del trabajo de desarrollo que agrega valor, lo que permite una medición precisa de la fase de codificación pura y la separa del tiempo de planificación o espera.

Dónde obtener

Se infiere al encontrar la marca de tiempo del primer commit en una rama de características vinculada a la issue. Esto requiere vincular issues a ramas, lo que a menudo se hace mediante convenciones de nomenclatura o metadatos.

Capturar

Encuentre la marca de tiempo del primer commit en una rama asociada con el ID de la issue.

Tipo de evento inferred
Despliegue Iniciado
Representa el inicio del proceso para liberar código a un entorno específico, como `staging` o `production`. En GitLab, esto corresponde al inicio de una tarea 'deploy' dentro de un `CI/CD pipeline`.
Por qué es importante

El seguimiento del inicio del despliegue ayuda a aislar la duración de la fase de despliegue. Es crucial para medir y optimizar el lead time de despliegue.

Dónde obtener

Capturado del timestamp 'started_at' de un job de CI/CD que está configurado como un job de despliegue. Esto forma parte de la característica de Entornos y Despliegues de GitLab.

Capturar

Utilice el timestamp 'started_at' del registro de eventos del trabajo de CI para una tarea de despliegue.

Tipo de evento explicit
Incidencia Asignada
Representa la asignación de una `issue` a un desarrollador o equipo específico, indicando que se ha establecido la propiedad del trabajo. Este es un evento explícito registrado por GitLab cada vez que se rellena o cambia el campo `assignee` de una `issue`.
Por qué es importante

El seguimiento de las asignaciones es crucial para analizar la asignación de recursos, la carga de trabajo del equipo y los tiempos de traspaso (handoff). Ayuda a identificar los retrasos entre el momento en que se crea el trabajo y el momento en que se retoma.

Dónde obtener

Se obtiene de las notas de sistema de la incidencia en GitLab, las cuales registran cuándo se añade o cambia un 'assignee'. La marca de tiempo del evento queda registrada en dicha nota.

Capturar

Extraiga los eventos de cambio de asignado ('assignee changed') de las notas de sistema de la incidencia.

Tipo de evento explicit
Incidencia Cerrada
Representa el cierre administrativo final del elemento de trabajo, típicamente después de que sus cambios han sido desplegados y verificados. Este es un evento explícito capturado cuando un usuario cierra la `issue` en GitLab.
Por qué es importante

Cerrar una incidencia suele marcar el fin definitivo de todo el trabajo relacionado. Al comparar este momento con el tiempo de despliegue, se pueden detectar retrasos en la validación posterior al despliegue o en trámites administrativos.

Dónde obtener

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

Capturar

Utilice el timestamp 'closed_at' de la incidencia.

Tipo de evento explicit
Revisión de Código Iniciada
Marca el inicio del proceso de revisión por pares para un `merge request`. Este evento se infiere 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 desde la creación del MR hasta el inicio de la revisión resalta los retrasos en la cola. Reducir este tiempo de espera es clave para acortar el ciclo general de revisión de código.

Dónde obtener

Se infiere de la marca de tiempo del primer comentario o hilo de revisión en el merge request que no proviene del autor del MR. Estos datos están disponibles a través de notas del sistema o la API de Notas.

Capturar

Encuentre la marca de tiempo del primer comentario de usuario en un MR de un no autor.

Tipo de evento inferred
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de GitLab