Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

GitLab
Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

Questo template completo La guida tra i dati essenziali per analizzare il Suo processo SDLC. Elenca gli attributi da raccogliere, le attività da tracciare e offre consigli pratici per l'estrazione da GitLab. Grazie a questa risorsa, potrà preparare i Suoi dati con sicurezza per un'analisi di process mining efficace.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi del Software Development Lifecycle

Questi sono i campi dati consigliati da includere nel Suo event log per un'analisi e un'ottimizzazione completa del ciclo di vita dello sviluppo software.
3 Obbligatorio 5 Consigliato 13 Facoltativo
Nome Descrizione
Activity
Activity
Il nome della specifica fase di processo o dell'evento verificatosi, come 'Issue Created' o 'Merge Request Merged'.
Descrizione

L'attributo Attività registra i singoli eventi che interessano un elemento di sviluppo. Non sono in un unico campo di GitLab, ma derivano da azioni e timestamp di ticket, merge request e pipeline. Creare un ticket, pushare un commit o approvare una MR sono tutte attività distinte.

Questo attributo è la base per costruire la mappa, visualizzare il workflow e analizzare frequenza e sequenza degli eventi. Serve a trovare deviazioni, colli di bottiglia tra i passaggi e i percorsi di processo più comuni.

Perché è importante

Definisce le fasi nella mappa di processo, consentendo la visualizzazione e l'analisi del workflow di sviluppo end-to-end.

Dove trovare

Derivato dai tipi di evento e dai cambiamenti di stato nello stream di eventi di GitLab, o interpretando i campi timestamp come 'created_at', 'merged_at' e 'closed_at' su Issue e Merge Request.

Esempi
Problema CreatoSviluppo avviatoMerge Request unita (merged)Pipeline fallitaDistribuito in produzione (Deployed)
Elemento di sviluppo
DevelopmentItem
L'identificativo univoco di un'unità di lavoro (feature, bug fix, task), che funge da identificatore primario del caso.
Descrizione

L'Elemento di Sviluppo è la singola unità di lavoro tracciabile nell'SDLC. Unisce tutte le attività correlate, dalla creazione al rilascio, in un unico caso coerente. In GitLab, di solito corrisponde all'ID interno del ticket (IID).

Analizzare per Elemento di Sviluppo permette di misurare i tempi di ciclo end-to-end, trovare colli di bottiglia e verificare la conformità del processo. È fondamentale per capire quanto velocemente il lavoro passi dall'idea alla produzione.

Perché è importante

È l'identificatore del caso essenziale che collega tutti gli eventi, permettendo di ricostruire l'intero ciclo di vita di ogni elemento di lavoro.

Dove trovare

In genere è l'ID interno (IID) di un ticket GitLab. Si trova nel campo 'iid' della risposta dell'API Issues.

Esempi
1024512PRJ-2345
Ora di Inizio
StartTime
Il timestamp che indica quando è iniziata un'attività o un evento.
Descrizione

Lo StartTime indica la data e l'ora esatte in cui è avvenuta una specifica attività. Per GitLab, questo dato si trova in vari timestamp: ad esempio, per 'Issue Created' è il created_at del ticket, mentre per 'Merge Request Merged' è il merged_at della merge request.

Questo timestamp è l'elemento temporale cardine del process mining. Serve a ordinare gli eventi, calcolare le durate, misurare i tempi di ciclo e analizzare l'andamento delle prestazioni nel tempo.

Perché è importante

Questo attributo fornisce la sequenza cronologica degli eventi, essenziale per calcolare tutte le metriche temporali e comprendere il flusso del processo.

Dove trovare

Estratto da vari campi timestamp in GitLab, come 'created_at', 'updated_at', 'closed_at' sulle issue e 'merged_at' sulle merge request.

Esempi
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Assegnatario
Assignee
L'utente assegnato al ticket o alla merge request al momento dell'evento.
Descrizione

L'Assegnatario è lo sviluppatore o l'utente responsabile dell'attività in un dato momento. In GitLab, si trova nel campo assignee o assignees di ticket o MR.

L'analisi per assegnatario è vitale per la dashboard 'Developer Workload & Allocation'. Serve a capire come sono usate le risorse, individuare chi è sovraccarico e analizzare i passaggi di consegne (handoff) tra i membri del team.

Perché è importante

Traccia chi ha eseguito l'attività, consentendo l'analisi del carico di lavoro, l'efficienza nell'allocazione delle risorse e l'identificazione dei ritardi causati dai passaggi di consegna (handoff).

Dove trovare

Recuperato dai campi 'assignee.username' o 'assignees' nelle risposte delle API GitLab Issues e Merge Requests.

Esempi
jdoeasmithr.williams
Gravità
Severity
Il livello di gravità dell'elemento di sviluppo, solitamente usato per bug o incidenti.
Descrizione

La gravità indica l'impatto di un bug o di un ticket, da critico a minore. Dato che GitLab non ha un campo nativo, solitamente si utilizzano le etichette (es. 'severity::1').

Questo attributo è essenziale per la dashboard 'Severity Escalation Trends' e il relativo KPI. Analizzare i cambiamenti di gravità durante il ciclo di vita aiuta a evidenziare problemi inizialmente sottovalutati o processi che peggiorano le criticità.

Perché è importante

Aiuta a dare priorità al lavoro e ad analizzare se gli elementi ad alta gravità vengono gestiti più velocemente. Il tracciamento delle modifiche supporta il KPI 'Severity Escalation Frequency'.

Dove trovare

Derivato dalle etichette (labels) applicate a una Issue di GitLab. È necessaria una mappatura per interpretare etichette come 'S1', 'S2' come livelli di Severity (gravità).

Esempi
1 - Critico2 - Alto3 - Medio4 - Basso
Nome Progetto
ProjectName
Il nome del progetto GitLab a cui appartiene l'elemento di sviluppo.
Descrizione

Questo attributo indica il repository o il progetto specifico su cui si sta lavorando. In GitLab, ogni ticket o MR appartiene a un progetto.

L'analisi per Nome Progetto permette di confrontare le prestazioni tra diversi prodotti o servizi. Aiuta a capire se alcuni progetti hanno processi più sani di altri ed è utile per filtrare le dashboard su aree d'interesse specifiche.

Perché è importante

Consente di segmentare l'analisi del processo per prodotto, applicazione o componente, facilitando sforzi di miglioramento mirati.

Dove trovare

Recuperato dai campi 'name' o 'path_with_namespace' nell'API Project, collegati tramite il 'project_id' in Issues e Merge Requests.

Esempi
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Ora di Fine
EndTime
Il `timestamp` che indica quando un'attività o un `event` è stato completato.
Descrizione

L'EndTime segna la data e l'ora precise in cui un'attività è terminata. Per molti eventi atomici in GitLab, come 'Issue Created', l'EndTime coincide con lo StartTime. Per le attività che hanno una durata, come 'Code Review', rappresenta il timestamp di completamento, ad esempio quando viene data l'approvazione finale.

Questo attributo è essenziale per calcolare accuratamente la durata delle singole attività (Tempo di elaborazione). Aiuta in un'analisi dettagliata dei bottleneck distinguendo tra il tempo trascorso a lavorare attivamente su un task e il tempo di attesa tra un task e l'altro.

Perché è importante

Consente il calcolo di durate precise delle attività (tempi di elaborazione), elemento chiave per identificare passaggi inefficienti nel processo.

Dove trovare

Per gli eventi atomici, coincide con lo StartTime. Per le attività di durata, deve essere ricavato individuando il corrispondente evento di completamento nei dati.

Esempi
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Tipo elemento di sviluppo
DevelopmentItemType
La classificazione dell'elemento di sviluppo, come 'Feature', 'Bug', 'Task' o 'Maintenance'.
Descrizione

Questo attributo definisce la natura del lavoro. In GitLab si usano solitamente le etichette per distinguere tra nuove funzioni, bug, debito tecnico, ecc.

L'analisi per Tipo di Elemento permette di confrontare flussi e tempi di ciclo. Si può verificare, ad esempio, se i bug vengono risolti più velocemente delle nuove feature o se il debito tecnico segue un iter di revisione diverso.

Perché è importante

Segmentare il processo per tipo di lavoro aiuta a capire se certe categorie sono più soggette a ritardi, rielaborazioni o deviazioni.

Dove trovare

Solitamente deriva dalle 'label' applicate a una Issue di GitLab. È necessaria una logica di mappatura per convertire label specifiche in tipologie standardizzate.

Esempi
Funzionalità (Feature)BugTaskDebito tecnico
È una Rilavorazione
IsRework
Un flag booleano che indica se un'attività fa parte di un ciclo di rilavorazione.
Descrizione

Contrassegna le attività che indicano un passo indietro, come tornare allo sviluppo dopo l'inizio dei test. La logica rileva sequenze specifiche, come un nuovo avvio dello sviluppo dopo un errore nella pipeline.

Questo dato alimenta la dashboard 'Rework & Rerun Analysis' e il relativo KPI. Permette di quantificare facilmente i rifacimenti, aiutando i team a capirne cause e impatto sulle scadenze.

Perché è importante

Segnala e quantifica direttamente i rework, rendendo facile l'analisi delle cause e dell'impatto delle inefficienze di processo e dei problemi di qualità.

Dove trovare

Calcolato dallo strumento di Process Mining analizzando la sequenza di attività per ogni caso e identificando pattern che indicano rilavorazioni (rework).

Esempi
truefalse
Nome del team
TeamName
Il team di sviluppo associato al progetto o all'assegnatario.
Descrizione

Il Nome del Team rappresenta il gruppo responsabile dell'attività. Spesso non è un campo standard di GitLab e viene ricavato dalle convenzioni di nomi dei progetti, dai gruppi o mappando gli assegnatari tramite tabelle esterne.

Questo attributo serve ad analizzare le prestazioni a livello di team. Permette di confrontare efficienza, carico di lavoro e aderenza ai processi tra squadre diverse, alimentando dashboard come l'analisi dei colli di bottiglia specifica per fase.

Perché è importante

Consente l'analisi delle prestazioni e il confronto dei processi tra diversi team, aiutando a identificare bottleneck specifici del team o best practice.

Dove trovare

Spesso ottenuto mappando il Nome Progetto o l'Assegnatario su una struttura di team definita al di fuori di GitLab, o dedotto dalle gerarchie dei gruppi GitLab.

Esempi
Frontend-AlphaBackend-ServicesPlatform-Infra
Ramo (branch) di destinazione
TargetBranch
Il nome del ramo (branch) di destinazione per una merge request.
Descrizione

Il Target Branch è il ramo in cui si intendono unire le modifiche (es. 'main' o 'develop'). È un'informazione chiave per ogni MR.

L'analisi per Target Branch rivela comportamenti diversi a seconda della destinazione. Ad esempio, i merge in 'main' possono avere processi di approvazione più rigidi e tempi più lunghi rispetto a un ramo di funzionalità. Aiuta anche a distinguere i rilasci in produzione da altre integrazioni di codice.

Perché è importante

Aiuta a distinguere tra i vari workflow di sviluppo e rilascio, poiché i processi possono variare sensibilmente a seconda del ramo (branch) di destinazione.

Dove trovare

Recuperato dal campo 'target_branch' nella risposta dell'API GitLab Merge Requests.

Esempi
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Sistema di Origine
SourceSystem
Identifica il sistema da cui provengono i dati.
Descrizione

Specifica l'origine dei dati, che in questo modello sarà sempre 'GitLab'.

È un attributo fondamentale quando si uniscono dati da sistemi diversi (es. Jira e GitLab). Permette di filtrare e segmentare i dati, mantenendo traccia della loro provenienza.

Perché è importante

Garantisce chiarezza sull'origine dei dati, aspetto fondamentale per la data governance e per l'integrazione di dati provenienti da più sistemi aziendali.

Dove trovare

Si tratta di un valore statico, 'GitLab', aggiunto durante la trasformazione dei dati.

Esempi
GitLab
Stato della Merge Request
MergeRequestStatus
Lo stato della merge request associata all'evento, come 'Opened', 'Merged' o 'Closed'.
Descrizione

Questo attributo registra lo stato di una Merge Request (MR) al momento dell'evento. Le MR di GitLab possono essere 'opened', 'closed', 'merged' o 'locked'. È uno stato distinto da quello generale dell'elemento di sviluppo.

Monitorare lo stato della MR è vitale per analizzare l'integrazione del codice. Alimenta dashboard come 'Code Review Cycle Time & Throughput' e aiuta a individuare ritardi tra creazione, revisione, approvazione e merge della MR.

Perché è importante

Offre visibilità sul processo di revisione del codice e di unione (merging), che spesso rappresenta un collo di bottiglia critico nell'SDLC.

Dove trovare

Recuperato dal campo 'state' nella risposta dell'API GitLab Merge Requests.

Esempi
openedmergedclosedlocked
Stato della pipeline
PipelineStatus
Lo stato di esecuzione della pipeline CI/CD, come 'Success', 'Failed' o 'Running'.
Descrizione

Questo attributo indica il risultato di una pipeline CI/CD. Gli stati comuni sono 'success', 'failed', 'running', ecc.

Questi dati sono vitali per l'analisi di rielaborazioni e ripetizioni. I fallimenti frequenti causano ritardi; analizzarne frequenza e impatto è la chiave per migliorare l'efficienza e la qualità del codice.

Perché è importante

Monitora il successo e il fallimento di build e test automatizzati, evidenziando i cicli di rework e le criticità legate alla qualità del codice o all'automazione dei test.

Dove trovare

Recuperato dal campo 'status' nella risposta dell'API GitLab CI/CD Pipelines.

Esempi
successfailedrunningannullato
Stato elemento di sviluppo
DevelopmentItemStatus
Lo stato dell'elemento di sviluppo al momento dell'evento, come 'Open', 'In Progress' o 'Closed'.
Descrizione

Questo attributo indica lo stato del ticket in GitLab (solitamente 'opened' o 'closed'). Stati più precisi sono spesso gestiti con etichette dedicate (es. 'In Corso').

Monitorare i cambi di stato è cruciale per capire il ciclo di vita del caso. Aiuta a vedere quanto tempo ogni elemento trascorre in una fase e permette di filtrare i lavori in corso o conclusi.

Perché è importante

Fornisce un'istantanea dello stato del caso, consentendo l'analisi del tempo trascorso nelle varie fasi e il filtraggio tra lavori in corso e completati.

Dove trovare

Lo stato principale proviene dal campo 'state' di un ticket GitLab ('opened', 'closed'). Stati più dettagliati sono spesso ricavati dalle etichette.

Esempi
openedclosedIn CorsoIn Revisione
Tempo di attesa nel passaggio di consegne
HandoffWaitTime
Tempo di inattività calcolato tra due attività consecutive eseguite da assegnatari diversi.
Descrizione

Questa metrica calcola l'intervallo tra la fine di un'attività e l'inizio della successiva, specie quando cambia l'assegnatario (es. tra fine sviluppo e inizio revisione).

È il dato centrale per il KPI 'Average Handoff Wait Time'. Svela le inefficienze nell'allocazione delle risorse e i problemi di comunicazione, evidenziando i ritardi che si verificano tra le fasi di lavoro attivo.

Perché è importante

Quantifica i tempi di inattività durante i passaggi di consegne tra persone o team diversi, rivelando ritardi nascosti e colli di bottiglia nella comunicazione.

Dove trovare

Calcolato dallo strumento di Process Mining. Richiede l'analisi di eventi consecutivi all'interno di un caso, verificando se l' 'Assegnatario' è diverso e calcolando quindi la differenza di tempo.

Esempi
1 giorno 2 ore15 minuti8 ore
Tempo di Ciclo
CycleTime
Il tempo totale trascorso dalla prima all'ultima attività per un elemento di sviluppo.
Descrizione

Il Cycle Time è una metrica calcolata che misura la durata totale di un caso. In genere viene calcolato come differenza di tempo tra il primissimo evento (ad es. 'Issue Created') e l'ultimo evento (ad es. 'Deployed to Production') per un singolo elemento di sviluppo.

Questo è un KPI primario per misurare l'efficienza complessiva del processo. È la metrica chiave in dashboard come 'SDLC End-to-End Cycle Time' e viene utilizzata per monitorare i miglioramenti e identificare i casi a lunga durata che potrebbero indicare problemi sistemici.

Perché è importante

È un KPI fondamentale del process mining che misura l'efficienza end-to-end del ciclo di vita dello sviluppo.

Dove trovare

Calcolato dallo strumento di Process Mining sottraendo lo StartTime minimo dallo StartTime massimo per ogni CaseID univoco.

Esempi
10 giorni 4 ore23 ore 15 minuti35 giorni
Tempo di Elaborazione
ProcessingTime
La durata di una singola attività, calcolata come la differenza tra il suo tempo di fine e il suo tempo di inizio.
Descrizione

Il tempo di elaborazione misura il tempo di lavoro attivo per una specifica attività, distinguendolo dai tempi di attesa tra le fasi. Si calcola sottraendo lo StartTime dall'EndTime per ogni singolo record di evento. Per gli eventi istantanei, il tempo di elaborazione è pari a zero.

Questa metrica è essenziale per l'analisi dei colli di bottiglia nelle singole fasi. Aggregando i tempi di elaborazione all'interno di una fase, come la Code Review, è possibile determinare quanto tempo venga dedicato effettivamente al lavoro, individuando con precisione i passaggi inefficienti del processo.

Perché è importante

Misura la durata delle singole attività, aiutando a distinguere il tempo di lavoro attivo dal tempo di attesa per un'analisi precisa dei colli di bottiglia.

Dove trovare

Calcolato dallo strumento di Process Mining come differenza tra EndTime e StartTime di un'attività.

Esempi
2 ore e 30 minuti0 minuti3 giorni 8 ore
Titolo Milestone
MilestoneTitle
Il titolo della milestone o dello sprint a cui è assegnato l'elemento di sviluppo.
Descrizione

In GitLab, una Milestone viene utilizzata per monitorare le attività rispetto a un obiettivo specifico o a un intervallo di tempo (timebox), come uno sprint o una versione di rilascio. Questo attributo registra il nome o il titolo di tale milestone.

Questo attributo consente di analizzare le prestazioni del processo nel contesto di sprint o periodi di pianificazione specifici. Può essere utilizzato per verificare se i Cycle Time migliorano da uno sprint all'altro o per filtrare la vista del processo in modo da mostrare solo il lavoro relativo a un rilascio imminente.

Perché è importante

Collega il lavoro di sviluppo ai cicli di pianificazione come sprint o release, consentendo l'analisi delle prestazioni rispetto ai timebox pianificati.

Dove trovare

Recuperato dal campo 'milestone.title' nelle risposte delle API GitLab Issues o Merge Requests.

Esempi
Release Q4-2023Sprint 23.11Fase 1: MVP
Ultimo `Data Update`
LastDataUpdate
Il timestamp che indica quando i dati per questo evento sono stati aggiornati l'ultima volta dal sistema sorgente.
Descrizione

Questo attributo registra quando i dati sono stati estratti l'ultima volta. Non indica quando è avvenuto l'evento, ma l'ultimo aggiornamento del dataset.

È fondamentale per conoscere la freschezza dei dati. Aiuta gli utenti a fidarsi delle dashboard e dei KPI, informandoli del possibile ritardo tra il sistema originale e l'analisi.

Perché è importante

Garantisce trasparenza sull'aggiornamento dei dati, assicurando che gli utenti sappiano quanto sia recente l'analisi del processo.

Dove trovare

Questo timestamp viene generato e registrato dallo strumento di estrazione o dal processo ETL durante l'aggiornamento dei dati.

Esempi
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Versione della Release
ReleaseVersion
L'etichetta (tag) della versione software, pianificata o effettiva, associata al rilascio.
Descrizione

Questo attributo indica la specifica release software di cui fa parte l'elemento. In GitLab può essere associato tramite una Milestone, un tag o la funzione Releases.

È fondamentale per tracciare il rispetto del calendario dei rilasci. Confrontando la data reale di deploy con quella pianificata, l'azienda può misurare la puntualità e diagnosticare le cause dei ritardi nelle release.

Perché è importante

Collega gli elementi di sviluppo a una specifica release software, il che è fondamentale per monitorare l'avanzamento del rilascio e il rispetto dei tempi.

Dove trovare

Può provenire da GitLab Releases, dal nome di un tag git o dal titolo di una milestone usata per pianificare il rilascio.

Esempi
v1.2.0v3.0.0-beta2023.4.1
Obbligatorio Consigliato Facoltativo

Attività del Software Development Lifecycle

Queste sono le fasi chiave del processo e le milestone da registrare nel tuo event log per un'accurata scoperta dei processi e l'identificazione dei colli di bottiglia.
4 Consigliato 8 Facoltativo
Activity Descrizione
Distribuito in produzione (Deployed)
Questa attività indica il rilascio riuscito del codice nell'ambiente di produzione, rendendolo disponibile agli utenti finali. Viene registrata quando un job specifico di 'deploy to production' in una pipeline GitLab termina con successo.
Perché è importante

È l'evento finale principale, che indica la consegna del valore. È essenziale per misurare il tempo di ciclo totale dell'SDLC e la frequenza delle release.

Dove trovare

Acquisito dal timestamp 'finished_at' di un job CI/CD andato a buon fine, specificamente designato per il deployment in produzione. La funzione Environments di GitLab lo traccia esplicitamente.

Acquisisci

Utilizzi il timestamp 'finished_at' del job CI relativo al deployment in produzione andato a buon fine.

Tipo di evento explicit
Merge Request creata
Indica che il lavoro di sviluppo iniziale è completato e il codice è pronto per la revisione e l'integrazione. Si tratta di un evento principale esplicito nel workflow di GitLab, registrato quando uno sviluppatore apre una nuova merge request (MR).
Perché è importante

È un traguardo critico che segna il passaggio dallo sviluppo alla revisione e ai test. È il punto di partenza per analizzare l'intero ciclo di code review e della pipeline CI/CD.

Dove trovare

È un evento esplicito registrato dal timestamp 'created_at' nella tabella 'merge_requests' o tramite l'API Merge Requests.

Acquisisci

Utilizzi il timestamp 'created_at' della merge request.

Tipo di evento explicit
Merge Request unita (merged)
Questa attività indica il completamento con successo della code review e dell'integrazione. È un evento esplicito che accade quando un utente unisce (merge) il ramo della MR nel ramo di destinazione.
Perché è importante

È una tappa fondamentale che indica la fine di sviluppo e revisione. Serve come punto finale per misurare il tempo di ciclo dello sviluppo e come inizio per calcolare il lead time di rilascio.

Dove trovare

È un evento esplicito registrato dal timestamp 'merged_at' nella tabella 'merge_requests'. Viene creata anche una nota di sistema al momento del merge.

Acquisisci

Utilizzi il timestamp 'merged_at' della merge request.

Tipo di evento explicit
Problema Creato
Questa attività segna l'inizio del ciclo di vita dello sviluppo e rappresenta la creazione di un nuovo elemento di lavoro. Viene registrata esplicitamente quando un utente crea un ticket in GitLab, che ne salva il timestamp di creazione.
Perché è importante

È l'evento di inizio principale del processo. Analizzare il tempo dalla creazione del ticket al rilascio offre una visione completa del tempo di ciclo SDLC.

Dove trovare

È un evento esplicito registrato dal timestamp 'created_at' nella tabella degli issue o tramite l'API Issues.

Acquisisci

Utilizzi il timestamp 'created_at' della issue.

Tipo di evento explicit
Approvazione aggiunta
Rappresenta un'approvazione formale delle modifiche al codice in una merge request da parte di un revisore. È un evento esplicito registrato da GitLab quando un utente clicca sul pulsante 'Approve'.
Perché è importante

Le approvazioni sono quality gate fondamentali. Tracciarle aiuta ad analizzare il tempo necessario per ottenere le firme richieste e garantisce la conformità alle policy di revisione.

Dove trovare

Acquisito dagli eventi di approvazione delle merge request. Questi sono disponibili tramite l'API Approvals o possono essere visualizzati nella cronologia della MR.

Acquisisci

Utilizzi il timestamp dal log degli event di approvazione della merge request.

Tipo di evento explicit
Deployment Avviato
Rappresenta l'inizio del processo di rilascio del codice in un ambiente specifico, come staging o produzione. In GitLab, corrisponde all'avvio di un job di 'deploy' all'interno di una pipeline CI/CD.
Perché è importante

Tracciare l'inizio del rilascio permette di isolare la durata di questa fase. È vitale per misurare e ottimizzare il lead time di deploy.

Dove trovare

Acquisito dal timestamp 'started_at' di un job CI/CD configurato come job di deployment. Questo fa parte della funzione Environments and Deployments di GitLab.

Acquisisci

Utilizzi il timestamp 'started_at' presente nei log del job CI per un task di deployment.

Tipo di evento explicit
Pipeline fallita
Questa attività avviene quando l'esecuzione di una pipeline fallisce in una qualsiasi fase (errore di build, test fallito, ecc.). GitLab registra lo stato finale di ogni pipeline, rendendo gli errori facilmente identificabili.
Perché è importante

I fallimenti della pipeline sono uno dei principali motivi di rielaborazione. Analizzarne frequenza, durata e cause aiuta a identificare problemi di qualità, test instabili e colli di bottiglia nei feedback agli sviluppatori.

Dove trovare

Identificato da uno stato 'failed' su un record della pipeline nella tabella 'ci_pipelines'. Il timestamp 'finished_at' indica quando si è verificato l'errore.

Acquisisci

Filtri i record della pipeline con stato 'failed' e utilizzi il timestamp 'finished_at'.

Tipo di evento explicit
Pipeline iniziata
Rappresenta l'avvio di una pipeline CI/CD automatizzata, che solitamente esegue build, test e scansioni di sicurezza. GitLab crea esplicitamente un record di pipeline con un timestamp di inizio ogni volta che viene attivata, ad esempio tramite un commit o la creazione di una MR.
Perché è importante

Tracciare le esecuzioni della pipeline è essenziale per monitorare lo stato e l'efficienza dei test automatizzati. Aiuta a capire quanto tempo richieda la validazione automatica.

Dove trovare

Acquisito dal timestamp 'created_at' o 'started_at' di un record di pipeline nella tabella 'ci_pipelines' o tramite l'API Pipelines.

Acquisisci

Utilizzi il timestamp dal record di esecuzione della pipeline associata al branch della MR.

Tipo di evento explicit
Problema assegnato
Rappresenta l'assegnazione di un ticket a uno sviluppatore o a un team specifico, indicando che la responsabilità del lavoro è stata stabilita. Questo evento esplicito viene registrato da GitLab ogni volta che il campo dell'assegnatario viene compilato o modificato.
Perché è importante

Tracciare le assegnazioni è fondamentale per analizzare l'uso delle risorse, il carico dei team e i tempi di passaggio. Aiuta a vedere quanto tempo passa tra la creazione di un compito e la sua presa in carico.

Dove trovare

Acquisito dalle note di sistema di GitLab per la issue, che registrano quando un 'assegnatario' viene aggiunto o modificato. Il timestamp dell'evento è registrato nella nota.

Acquisisci

Estragga gli eventi 'assegnatario modificato' dalle note di sistema della issue.

Tipo di evento explicit
Problema chiuso
Rappresenta la chiusura amministrativa finale dell'elemento di lavoro, solitamente dopo che le modifiche sono state rilasciate e verificate. Si tratta di un evento esplicito registrato quando un utente chiude il ticket in GitLab.
Perché è importante

La chiusura di una issue spesso segna la fine definitiva di tutto il lavoro correlato. Confrontare questo momento con il tempo di deployment può rivelare ritardi nella validazione post-deployment o nei processi amministrativi.

Dove trovare

È un evento esplicito registrato dal timestamp 'closed_at' nella tabella degli issue o dalla relativa nota di sistema.

Acquisisci

Utilizzi il timestamp 'closed_at' della issue.

Tipo di evento explicit
Revisione del codice avviata
Segna l'inizio del processo di revisione paritaria (peer review) per una merge request. Questo evento è dedotto dalla prima azione relativa alla revisione, come il primo commento o thread pubblicato da un utente diverso dall'autore.
Perché è importante

Misurare il tempo dalla creazione della MR all'inizio della revisione mette in luce i ritardi nelle code. Ridurre questo tempo di attesa è fondamentale per abbreviare l'intero ciclo di code review.

Dove trovare

Deduciamo questo dato dal timestamp del primo commento o thread di revisione sulla merge request non inviato dall'autore della MR. Questi dati sono disponibili tramite le note di sistema o l'API Notes.

Acquisisci

Trovi il timestamp del primo commento utente su una MR inviato da un utente diverso dall'autore.

Tipo di evento inferred
Sviluppo avviato
Questa attività segna l'avvio del lavoro effettivo di codifica sul ticket. Di solito viene dedotta dal primo commit inviato a un ramo associato, poiché GitLab non ha un pulsante esplicito per 'iniziare lo sviluppo'.
Perché è importante

Individua l'inizio esatto del lavoro di sviluppo a valore aggiunto, consentendo una misurazione accurata della fase di pura codifica e separandola dai tempi di pianificazione o di coda.

Dove trovare

Deduciamo questo dato individuando il timestamp del primo commit su un branch di funzionalità collegato al ticket. Ciò richiede il collegamento dei ticket ai rami, spesso effettuato tramite convenzioni di denominazione o metadati.

Acquisisci

Individui il timestamp del primo commit su un ramo associato all'ID del ticket.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi dati da GitLab