Il Suo template dei dati per il ciclo di vita dello sviluppo software

GitLab
Il Suo template dei dati per il ciclo di vita dello sviluppo software

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Questo template completo La guida nella raccolta dei dati essenziali per analizzare il processo di sviluppo software. Indica gli attributi fondamentali da raccogliere e le attività principali da monitorare, oltre a fornire indicazioni pratiche per estrarre queste informazioni direttamente da GitLab. Grazie a questa risorsa, potrà preparare i dati per un’analisi efficace con il Process Mining.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare e ottimizzare in modo completo il ciclo di vita dello sviluppo software.
3 Obbligatorio 5 Consigliato 12 Facoltativo
Nome Descrizione
Attività
Activity
Il nome della specifica fase o dell’evento del processo, ad esempio 'Issue creata' o 'Merge request unita'.
Descrizione

L’attributo Attività registra i singoli eventi che riguardano un elemento di sviluppo. In GitLab questi eventi non sono memorizzati in un unico campo, ma vengono ricavati da diverse azioni e campi timestamp relativi a Issues, Merge Requests e CI/CD Pipelines. La creazione di un’issue, l’invio di un commit, il mancato superamento di una pipeline o l’approvazione di una merge request sono esempi di attività distinte.

Questo attributo è fondamentale per creare la mappa del processo, visualizzare il flusso di lavoro e analizzare la sequenza e la frequenza degli eventi. Serve a individuare deviazioni, colli di bottiglia tra le fasi e percorsi ricorrenti del processo.

Perché è importante

Definisce le fasi della mappa del processo e consente di visualizzare e analizzare il flusso di lavoro dello sviluppo end-to-end.

Dove reperirli

Ricavato dai tipi di evento e dai cambiamenti di stato nel flusso di eventi di GitLab oppure interpretando campi timestamp come 'created_at', 'merged_at' e 'closed_at' di Issues e Merge Requests.

Esempi
Issue creataSviluppo iniziatoMerge request unitaPipeline non riuscitaDistribuito in produzione
Elemento di sviluppo
DevelopmentItem
Identificativo univoco di un’unità di lavoro, ad esempio una funzionalità, la correzione di un bug o un’attività; funge da identificativo principale del caso.
Descrizione

L’elemento di sviluppo rappresenta una singola unità di lavoro tracciabile che attraversa il ciclo di vita dello sviluppo software. Collega in un unico caso coerente tutte le attività correlate, dalla creazione alla distribuzione finale. In GitLab è in genere rappresentato dall’ID interno (IID) dell’issue, univoco all’interno del progetto.

L’analisi per elemento di sviluppo consente di misurare il tempo di ciclo end-to-end, individuare i colli di bottiglia e verificare la conformità del processo. È la base per capire con quale efficienza il lavoro viene portato dall’ideazione alla produzione.

Perché è importante

È l’identificativo essenziale del caso che collega tutti gli eventi del processo e consente di ricostruire l’intero ciclo di vita di qualsiasi elemento di lavoro.

Dove reperirli

In genere corrisponde all’ID interno (IID) di un’issue GitLab. È disponibile nella risposta dell’API Issues, nel campo 'iid'.

Esempi
1024512PRJ-2345
Ora di inizio
StartTime
Il timestamp che indica quando è iniziata un’attività o si è verificato un evento.
Descrizione

StartTime indica la data e l’ora esatte in cui si è verificata una specifica attività. In GitLab, questi dati sono registrati in diversi campi timestamp. Per esempio, per l’attività 'Issue creata', StartTime corrisponde al timestamp 'created_at' dell’issue; per l’attività 'Merge request unita', corrisponde al timestamp 'merged_at' della merge request.

Questo timestamp è l’elemento temporale fondamentale nel Process Mining. Serve a ordinare gli eventi cronologicamente, calcolare la durata tra le attività, misurare i tempi di ciclo e analizzare nel tempo le prestazioni del processo.

Perché è importante

Fornisce la sequenza cronologica degli eventi, indispensabile per calcolare tutte le metriche temporali e comprendere il flusso del processo.

Dove reperirli

Estratto da diversi campi timestamp di GitLab, come 'created_at', 'updated_at' e 'closed_at' delle issue e 'merged_at' delle merge request.

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

L’assegnatario è lo sviluppatore o l’utente responsabile dell’elemento di lavoro in una determinata fase del processo. In GitLab è indicato nel campo assignee o assignees di un’Issue o di una Merge Request.

L’analisi per assegnatario è fondamentale per la Dashboard 'Carico di lavoro e allocazione degli sviluppatori'. Aiuta a comprendere l’utilizzo delle risorse, individuare persone o team sovraccarichi e analizzare i passaggi di consegne.

Perché è importante

Registra chi ha svolto il lavoro e consente di analizzare il carico di lavoro e l’efficienza nell’allocazione delle risorse, oltre a individuare i ritardi causati dai passaggi di consegne.

Dove reperirli

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, in genere per bug o incidenti.
Descrizione

La gravità indica l’impatto di un bug o di un problema, da critico a lieve. GitLab non dispone di un campo nativo per la gravità, quindi questa informazione viene quasi sempre gestita tramite etichette, ad esempio 'severity::1' e 'severity::2'.

Questo attributo è essenziale per la Dashboard 'Andamento delle escalation di gravità' e per il relativo KPI. Analizzare i cambiamenti di gravità durante il ciclo di vita può mettere in luce problemi inizialmente sottovalutati o processi che aggravano le criticità.

Perché è importante

Aiuta a stabilire le priorità del lavoro e a verificare se gli elementi ad alta gravità vengono gestiti più rapidamente. Monitorare i cambiamenti consente di calcolare il KPI 'Frequenza delle escalation di gravità'.

Dove reperirli

Ricavato dalle 'labels' applicate a un’Issue GitLab. È necessario associare le etichette, ad esempio 'S1' e 'S2', ai rispettivi livelli di gravità.

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

Questo attributo identifica il repository di codice o il progetto specifico in cui viene svolto il lavoro. In GitLab, ogni issue e merge request appartiene a un progetto.

L’analisi per nome del progetto consente di confrontare le prestazioni di prodotti, componenti o servizi diversi. Può aiutare a individuare i progetti con processi SDLC più efficaci ed è utile per filtrare le Dashboard in base all’area di interesse.

Perché è importante

Consente di segmentare l’analisi del processo per prodotto, applicazione o componente e di indirizzare gli interventi di miglioramento.

Dove reperirli

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

Esempi
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Ora di fine
EndTime
Il timestamp che indica quando è stata completata un’attività o si è concluso un evento.
Descrizione

EndTime indica la data e l’ora esatte in cui è terminata un’attività. Per molti eventi atomici in GitLab, come 'Issue creata', EndTime coincide con StartTime. Per le attività che hanno una durata, come la 'Revisione del codice', indica il timestamp di completamento, ad esempio il momento in cui viene concessa l’approvazione finale.

Questo attributo è essenziale per calcolare con precisione la durata delle singole attività (tempo di elaborazione). Consente un’analisi dettagliata dei colli di bottiglia, distinguendo il tempo dedicato al lavoro effettivo su un’attività dall’attesa tra un’attività e l’altra.

Perché è importante

Consente di calcolare con precisione la durata delle attività (tempi di elaborazione), un dato fondamentale per individuare le fasi inefficienti del processo.

Dove reperirli

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

Esempi
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Tipo di elemento di sviluppo
DevelopmentItemType
La classificazione dell’elemento di sviluppo, ad esempio 'Funzionalità', 'Bug', 'Attività' o 'Manutenzione'.
Descrizione

Questo attributo classifica la natura del lavoro svolto. In GitLab viene comunemente implementato tramite le etichette applicate a un’issue. I team utilizzano le etichette per distinguere tra nuove funzionalità, correzione di difetti, debito tecnico e altri tipi di lavoro.

L’analisi per tipo di elemento di sviluppo consente di confrontare i flussi di processo e i tempi di ciclo delle diverse categorie di lavoro. Per esempio, è possibile verificare se i bug vengono risolti più rapidamente delle funzionalità o se le attività relative al debito tecnico seguono un processo di revisione diverso.

Perché è importante

Segmentare il processo per tipo di lavoro aiuta a individuare le categorie più soggette a ritardi, rilavorazioni o deviazioni.

Dove reperirli

In genere si ricava dalle 'labels' applicate a un’Issue GitLab. È necessaria una logica di associazione per convertire le etichette specifiche in tipi standardizzati.

Esempi
FunzionalitàBugAttivitàDebito tecnico
È una rilavorazione
IsRework
Indicatore booleano che segnala se un’attività fa parte di un ciclo di rilavorazione.
Descrizione

Questo attributo calcolato segnala le attività che rappresentano un passo indietro nel processo, ad esempio quando si torna allo sviluppo dopo l’inizio dei test. In genere, la logica dell’indicatore rileva sequenze specifiche di attività, come un evento «Sviluppo avviato» che si verifica dopo un evento «Pipeline non riuscita» o «Test QA avviati» per lo stesso caso.

Questo attributo alimenta direttamente la Dashboard «Analisi delle rilavorazioni e delle riesecuzioni» e il KPI «Tasso di rilavorazione dopo i test». Consente di filtrare e quantificare facilmente le rilavorazioni, aiutando i team a comprenderne frequenza, cause e impatto sulle tempistiche dei progetti.

Perché è importante

Segnala e quantifica direttamente le rilavorazioni, facilitando l’analisi delle cause e dell’impatto delle inefficienze di processo e dei problemi di qualità.

Dove reperirli

Calcolato dallo strumento di Process Mining, che analizza la sequenza delle attività di ogni caso e individua gli schemi che indicano una rilavorazione.

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

Il nome del team identifica il gruppo o la squadra responsabile dell’elemento di sviluppo. In genere non è un campo standard di GitLab e viene ricavato dalle convenzioni di denominazione dei progetti, dalla struttura dei gruppi oppure associando gli assegnatari ai rispettivi team tramite una tabella di riferimento esterna.

Questo attributo consente di analizzare le prestazioni del processo a livello di team. Aiuta a confrontare efficienza, carico di lavoro e rispetto del processo tra team diversi e supporta Dashboard come 'Analisi dei colli di bottiglia per fase' con una prospettiva basata sui team.

Perché è importante

Consente di analizzare le prestazioni e confrontare i processi tra team diversi, aiutando a individuare colli di bottiglia specifici o buone pratiche.

Dove reperirli

Spesso si ricava associando il nome del progetto o l’assegnatario a una struttura dei team definita al di fuori di GitLab, oppure si deduce dalla gerarchia dei gruppi GitLab.

Esempi
Frontend-AlphaBackend-ServicesPlatform-Infra
Ramo di destinazione
TargetBranch
Il nome del ramo di destinazione in cui è previsto l’inserimento delle modifiche di una Merge Request.
Descrizione

Il ramo di destinazione è quello in cui si intende integrare le modifiche, ad esempio «main», «develop» o un ramo di rilascio come «release/1.5». È un’informazione fondamentale per ogni Merge Request.

L’analisi per ramo di destinazione può rivelare differenze nel processo seguito per integrare il codice in destinazioni diverse. Per esempio, le modifiche dirette a «main» possono richiedere un processo di approvazione più rigoroso e tempi di ciclo più lunghi rispetto a quelle destinate a un ramo di funzionalità. Questo dato aiuta anche a distinguere i rilasci in produzione dagli altri tipi di integrazione del codice.

Perché è importante

Consente di distinguere i diversi flussi di lavoro di sviluppo e rilascio, poiché il processo può variare notevolmente in base al ramo di destinazione.

Dove reperirli

Ricavato dal campo «target_branch» della 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

Questo attributo specifica l’origine dei dati di processo. In questo modello di dati, il valore sarà sempre 'GitLab'.

Includere questo attributo è fondamentale negli ambienti in cui i dati di processo possono provenire da più sistemi, ad esempio Jira per la pianificazione e GitLab per l’esecuzione. Consente di applicare filtri e segmentare i dati, contribuendo inoltre a mantenerne la tracciabilità.

Perché è importante

Chiarisce l’origine dei dati, un aspetto fondamentale per la governance dei dati e per integrare informazioni provenienti da più sistemi aziendali.

Dove reperirli

È un valore statico, 'GitLab', aggiunto durante la trasformazione dei dati.

Esempi
GitLab
Stato dell’elemento di sviluppo
DevelopmentItemStatus
Lo stato dell’elemento di sviluppo al momento dell’evento, ad esempio 'Aperto', 'In corso' o 'Chiuso'.
Descrizione

Questo attributo riflette lo stato dell’elemento di lavoro principale, in genere un’Issue GitLab. Le Issue GitLab hanno un campo state che può essere 'opened' o 'closed'. Spesso gli stati più dettagliati vengono gestiti tramite etichette con ambito specifico, ad esempio 'Status::Triage', 'Status::In-Dev' e 'Status::In-Review'.

Monitorare i cambiamenti di stato è fondamentale per comprendere il ciclo di vita del caso. Aiuta a individuare quanto tempo gli elementi trascorrono in ciascuno stato e consente di filtrare il lavoro in corso o completato in Dashboard come 'Tempo di ciclo SDLC end-to-end'.

Perché è importante

Fornisce una fotografia dello stato del caso, consentendo di analizzare il tempo trascorso nelle diverse fasi e filtrare il lavoro in corso rispetto a quello completato.

Dove reperirli

Lo stato principale proviene dal campo 'state' di un’Issue GitLab ('opened', 'closed'). Gli stati più dettagliati vengono spesso ricavati dalle etichette.

Esempi
apertachiusaIn corsoIn revisione
Stato della Merge Request
MergeRequestStatus
Lo stato della Merge Request associata all’evento, ad esempio «Aperta», «Unita» o «Chiusa».
Descrizione

Questo attributo registra lo stato di una Merge Request (MR) al momento dell’evento. In GitLab, le MR possono trovarsi in stati distinti: «aperta», «chiusa», «unita» o «bloccata». Questo dato è distinto dallo stato complessivo dell’elemento di sviluppo.

Monitorare lo stato della MR è fondamentale per analizzare la fase di integrazione del codice nel ciclo di vita dello sviluppo software (SDLC). Il dato alimenta direttamente Dashboard come «Tempo di ciclo e throughput della revisione del codice» e aiuta a individuare i ritardi tra la creazione della MR, la revisione, l’approvazione e l’unione.

Perché è importante

Consente di monitorare il processo di revisione e unione del codice, che spesso rappresenta un collo di bottiglia critico nel ciclo SDLC.

Dove reperirli

Ricavato dal campo «state» della risposta dell’API GitLab Merge Requests.

Esempi
apertaunitachiusabloccata
Stato della pipeline
PipelineStatus
Lo stato di esecuzione della pipeline CI/CD, ad esempio «Riuscita», «Non riuscita» o «In esecuzione».
Descrizione

Questo attributo indica l’esito dell’esecuzione di una pipeline CI/CD associata a un commit o a una Merge Request. In GitLab, gli stati più comuni sono «in esecuzione», «in attesa», «riuscita», «non riuscita», «annullata» e «ignorata».

Questi dati sono essenziali per la Dashboard «Analisi delle rilavorazioni e delle riesecuzioni». I frequenti errori delle pipeline possono causare rilavorazioni e ritardi significativi; analizzarne frequenza, posizione e impatto è fondamentale per migliorare l’efficienza dello sviluppo e la qualità del codice.

Perché è importante

Registra gli esiti positivi e negativi delle build e dei test automatizzati, mettendo in evidenza i cicli di rilavorazione e i problemi di qualità del codice o di automazione dei test.

Dove reperirli

Ricavato dal campo «status» della risposta dell’API GitLab CI/CD Pipelines.

Esempi
riuscitanon riuscitain esecuzioneannullata
Tempo di attesa nel passaggio di consegne
HandoffWaitTime
Tempo di inattività calcolato tra due attività consecutive svolte da assegnatari diversi.
Descrizione

Questa metrica calcola la durata dell’intervallo tra il completamento di un’attività e l’inizio della successiva, quando cambia l’assegnatario. Per esempio, misura il tempo che intercorre tra la fine del lavoro di uno sviluppatore e l’inizio della revisione del codice da parte di un revisore.

È la metrica di riferimento per il KPI «Tempo medio di attesa nel passaggio di consegne». Aiuta a individuare inefficienze nascoste nell’assegnazione delle risorse e nella comunicazione tra team o persone, mettendo in luce ritardi che non corrispondono ad attività effettive.

Perché è importante

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

Dove reperirli

Calcolato dallo strumento di Process Mining analizzando gli eventi consecutivi di un caso, verificando se l’«Assegnatario» è diverso e calcolando quindi la differenza di tempo.

Esempi
1 giorno e 2 ore15 minuti8 ore
Tempo di ciclo
CycleTime
Il tempo totale trascorso tra la prima e l’ultima attività di un elemento di sviluppo.
Descrizione

Il tempo di ciclo è una metrica calcolata che misura la durata complessiva di un caso. In genere si calcola come differenza tra il primo evento (ad esempio «Issue creata») e l’ultimo (ad esempio «Distribuito in produzione») relativi a un singolo elemento di sviluppo.

È un KPI fondamentale per misurare l’efficienza complessiva del processo. È la metrica principale di Dashboard come «Tempo di ciclo end-to-end SDLC» e serve a monitorare i miglioramenti e a individuare i casi di lunga durata, che possono segnalare problemi sistemici.

Perché è importante

È un KPI fondamentale del Process Mining, che misura l’efficienza end-to-end del ciclo di vita dello sviluppo.

Dove reperirli

Calcolato dallo strumento di Process Mining sottraendo il valore minimo di StartTime dal valore massimo di StartTime per ogni CaseId univoco.

Esempi
10 giorni e 4 ore23 ore e 15 minuti35 giorni
Titolo della milestone
MilestoneTitle
Il titolo della milestone o dello sprint a cui è assegnato l’elemento di sviluppo.
Descrizione

In GitLab, una milestone consente di monitorare il lavoro rispetto a un obiettivo o a un periodo definito, ad esempio uno sprint o una versione di rilascio. Questo attributo registra il nome o il titolo della milestone.

Permette di analizzare l’andamento del processo nell’ambito di sprint o periodi di pianificazione specifici. Può essere usato per verificare se i tempi di ciclo migliorano da uno sprint al successivo oppure per filtrare la vista del processo e mostrare solo il lavoro relativo a un rilascio imminente.

Perché è importante

Collega il lavoro di sviluppo ai cicli di pianificazione, come sprint e rilasci, e consente di valutare i risultati rispetto ai periodi previsti.

Dove reperirli

Ricavato dal campo «milestone.title» delle risposte dell’API GitLab Issues o Merge Requests.

Esempi
Rilascio T4 2023Sprint 23.11Fase 1: MVP
Ultimo aggiornamento dei dati
LastDataUpdate
Il timestamp che indica quando i dati relativi a questo evento sono stati aggiornati per l’ultima volta dal sistema di origine.
Descrizione

Questo attributo registra la data e l’ora dell’ultima estrazione o dell’ultimo aggiornamento dei dati dell’evento nel set di dati di Process Mining. Non indica quando si è verificato l’evento, ma quando il relativo record è stato sincronizzato l’ultima volta.

Questa informazione è essenziale per conoscere l’aggiornamento dei dati e verificare la tempestività dell’analisi del processo. Aiuta gli utenti a fare affidamento su Dashboard e KPI basati su dati recenti e segnala l’eventuale ritardo tra il sistema di origine e l’analisi.

Perché è importante

Rende trasparente il livello di aggiornamento dei dati, così gli utenti sanno quanto è aggiornata l’analisi del processo.

Dove reperirli

Questo timestamp viene generato e registrato dallo strumento di estrazione dei dati o dal processo ETL al momento dell’aggiornamento.

Esempi
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Versione di rilascio
ReleaseVersion
Il tag della versione software pianificata o effettiva associata al rilascio.
Descrizione

Questo attributo identifica la versione software specifica a cui appartiene un elemento di sviluppo. In GitLab, la versione può essere associata a una milestone, a un tag protetto o a una voce della funzionalità Releases.

È un dato essenziale per la Dashboard «Monitoraggio del rispetto del calendario dei rilasci». Confrontando la data effettiva di distribuzione con quella pianificata per la versione, le organizzazioni possono misurare la capacità di rispettare le scadenze e individuare le cause dei ritardi nei rilasci.

Perché è importante

Collega gli elementi di sviluppo a una specifica versione software, un dato fondamentale per monitorare l’avanzamento dei rilasci e il rispetto delle scadenze.

Dove reperirli

Il dato 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 ciclo di vita dello sviluppo software

Questi sono i passaggi e le milestone principali da registrare nell’Event Log per individuare con precisione i processi e i colli di bottiglia.
4 Consigliato 8 Facoltativo
Attività Descrizione
Distribuito in produzione
Questa attività segna la distribuzione riuscita del codice nell’ambiente di produzione, rendendolo disponibile agli utenti finali. Viene registrata quando un job specifico 'deploy to production' in una pipeline CI/CD GitLab viene completato correttamente.
Perché è importante

È l’evento finale principale del processo e indica che il valore è stato consegnato. È essenziale per misurare il tempo di ciclo SDLC complessivo dall’inizio alla fine e la frequenza dei rilasci.

Dove reperirli

L’evento viene rilevato dal timestamp 'finished_at' di un job CI/CD completato correttamente e destinato specificamente alla distribuzione in produzione. La funzione Environments di GitLab lo registra esplicitamente.

Acquisizione

Utilizzi il timestamp 'finished_at' del job CI completato correttamente per la distribuzione in produzione.

Tipo di evento explicit
Issue creata
Questa attività segna l’inizio del ciclo di vita dello sviluppo e corrisponde alla creazione di un nuovo elemento di lavoro, ad esempio una funzionalità, un bug o un’attività. Viene registrata esplicitamente quando un utente crea una nuova issue in GitLab, che ne memorizza la data e l’ora di creazione.
Perché è importante

È l’evento di inizio principale del processo end-to-end. Analizzare il tempo che intercorre tra la creazione dell’issue e la distribuzione offre una visione completa del tempo di ciclo SDLC.

Dove reperirli

È un evento esplicito, rilevato dal timestamp 'created_at' nella tabella 'issues' o tramite l’API Issues. Anche le note di sistema registrano l’evento di creazione.

Acquisizione

Utilizzi il timestamp 'created_at' dell’issue.

Tipo di evento explicit
Merge request creata
Indica che il lavoro iniziale di sviluppo è terminato e che il codice è pronto per la revisione e l’integrazione. È un evento esplicito e fondamentale nel flusso di lavoro GitLab, registrato quando uno sviluppatore apre una nuova merge request (MR).
Perché è importante

È una tappa fondamentale che segna il passaggio dallo sviluppo alla revisione e ai test. Costituisce il punto di partenza per analizzare l’intero ciclo di revisione del codice e della pipeline CI/CD.

Dove reperirli

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

Acquisizione

Utilizzi il timestamp 'created_at' della merge request.

Tipo di evento explicit
Merge request unita
Questa attività segna il completamento della revisione e dell’integrazione del codice. È un evento esplicito che si verifica quando un utente unisce il branch della merge request al branch di destinazione.
Perché è importante

È una tappa importante che indica il completamento dello sviluppo e della revisione. Segna la fine del tempo di ciclo dello sviluppo e l’inizio della misurazione del tempo di attraversamento fino alla distribuzione.

Dove reperirli

È un evento esplicito, rilevato dal timestamp 'merged_at' nella tabella 'merge_requests'. Al momento dell’unione viene generata anche una nota di sistema.

Acquisizione

Utilizzi il timestamp 'merged_at' della merge request.

Tipo di evento explicit
Approvazione aggiunta
Indica l’approvazione formale delle modifiche al codice di una merge request da parte di un revisore. GitLab registra esplicitamente l’evento quando un utente fa clic sul pulsante 'Approve'.
Perché è importante

Le approvazioni sono passaggi fondamentali per il controllo della qualità. Monitorarle aiuta ad analizzare il tempo necessario per ottenere le approvazioni richieste e a garantire la conformità alle politiche di revisione.

Dove reperirli

L’evento viene rilevato dagli eventi di approvazione delle merge request, disponibili tramite l’API Approvals o consultabili nella cronologia della MR.

Acquisizione

Utilizzi il timestamp del registro degli eventi di approvazione della merge request.

Tipo di evento explicit
Distribuzione avviata
Indica l’inizio del processo di rilascio del codice in un ambiente specifico, ad esempio di staging o di produzione. In GitLab corrisponde all’avvio di un job 'deploy' all’interno di una pipeline CI/CD.
Perché è importante

Monitorare l’avvio della distribuzione aiuta a isolare la durata di questa fase. È fondamentale per misurare e ottimizzare il tempo di attraversamento della distribuzione.

Dove reperirli

L’evento viene rilevato dal timestamp 'started_at' di un job CI/CD configurato come job di distribuzione. Questa funzione fa parte di Environments and Deployments di GitLab.

Acquisizione

Utilizzi il timestamp 'started_at' del registro del job CI relativo a un’attività di distribuzione.

Tipo di evento explicit
Issue assegnata
Indica che un’issue è stata assegnata a uno sviluppatore o a un team specifico e che è stata quindi definita la responsabilità del lavoro. GitLab registra esplicitamente questo evento ogni volta che il campo dell’assegnatario di un’issue viene compilato o modificato.
Perché è importante

Monitorare le assegnazioni è fondamentale per analizzare l’allocazione delle risorse, il carico di lavoro dei team e i tempi di passaggio tra persone o gruppi. Aiuta a individuare i ritardi tra la creazione del lavoro e il momento in cui viene preso in carico.

Dove reperirli

L’evento viene rilevato dalle note di sistema di GitLab relative all’issue, che registrano quando viene aggiunto o modificato un 'assignee'. Il timestamp dell’evento è riportato nella nota.

Acquisizione

Estragga gli eventi 'assignee changed' dalle note di sistema dell’issue.

Tipo di evento explicit
Issue chiusa
Indica la chiusura amministrativa definitiva dell’elemento di lavoro, in genere dopo la distribuzione e la verifica delle modifiche. È un evento esplicito, registrato quando un utente chiude l’issue in GitLab.
Perché è importante

La chiusura di un’issue spesso segna la conclusione definitiva di tutto il lavoro correlato. Confrontare questo momento con quello della distribuzione può rivelare ritardi nella convalida successiva al rilascio o nelle procedure amministrative.

Dove reperirli

È un evento esplicito, rilevato dal timestamp 'closed_at' nella tabella 'issues' o dalla nota di sistema corrispondente.

Acquisizione

Utilizzi il timestamp 'closed_at' dell’issue.

Tipo di evento explicit
Pipeline avviata
Indica l’avvio di una pipeline CI/CD automatizzata, che in genere esegue compilazioni, test e scansioni di sicurezza. Quando viene attivata una pipeline, ad esempio da un commit o dalla creazione di una MR, GitLab crea esplicitamente un record con il timestamp di avvio.
Perché è importante

Monitorare le esecuzioni delle pipeline è essenziale per valutare lo stato e l’efficienza dei processi di test e integrazione automatizzati. Aiuta a capire quanto tempo viene dedicato alla convalida automatizzata.

Dove reperirli

L’evento viene rilevato dal timestamp 'created_at' o 'started_at' del record della pipeline nella tabella 'ci_pipelines' o tramite l’API Pipelines.

Acquisizione

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

Tipo di evento explicit
Pipeline non riuscita
Questa attività si verifica quando l’esecuzione di una pipeline CI/CD non va a buon fine in una qualsiasi fase, ad esempio per un errore di compilazione o un test non superato. GitLab registra esplicitamente lo stato finale di ogni pipeline, rendendo semplice individuare gli insuccessi.
Perché è importante

Gli insuccessi delle pipeline sono una delle principali cause di rilavorazione. Analizzarne frequenza, durata e cause aiuta a individuare problemi di qualità, test instabili e colli di bottiglia nel ciclo di feedback agli sviluppatori.

Dove reperirli

L’evento è identificato dallo stato 'failed' di un record della pipeline nella tabella 'ci_pipelines'. Il timestamp 'finished_at' indica quando si è verificato l’insuccesso.

Acquisizione

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

Tipo di evento explicit
Revisione del codice iniziata
Segna l’inizio della revisione tra pari di una merge request. L’evento viene dedotto dalla prima azione relativa alla revisione, ad esempio il primo commento o messaggio in una discussione pubblicato da una persona diversa dall’autore.
Perché è importante

Misurare il tempo che intercorre tra la creazione della MR e l’inizio della revisione mette in luce i ritardi in coda. Ridurre questa attesa è fondamentale per abbreviare il ciclo complessivo di revisione del codice.

Dove reperirli

Si deduce dal timestamp del primo commento o messaggio di revisione sulla merge request pubblicato da una persona diversa dall’autore della MR. Questi dati sono disponibili nelle note di sistema o tramite l’API Notes.

Acquisizione

Individui il timestamp del primo commento sulla MR pubblicato da un utente diverso dall’autore.

Tipo di evento inferred
Sviluppo iniziato
Questa attività indica l’inizio del lavoro di sviluppo attivo sull’issue. In genere viene dedotta dal primo commit di codice inviato a un branch associato all’issue, poiché GitLab non dispone di un pulsante esplicito per avviare lo sviluppo.
Perché è importante

Individua l’inizio esatto del lavoro di sviluppo che crea valore, consentendo di misurare con precisione la fase di programmazione vera e propria e di distinguerla dal tempo dedicato alla pianificazione o trascorso in coda.

Dove reperirli

Si deduce individuando il timestamp del primo commit su un branch di funzionalità collegato all’issue. È necessario associare le issue ai branch, spesso tramite convenzioni di denominazione o metadati.

Acquisizione

Individui il timestamp del primo commit su un branch associato all’ID dell’issue.

Tipo di evento inferred
Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da GitLab

È pronto a iniziare?

Utilizzi questo template per preparare i dati e iniziare a ottimizzare il ciclo di vita dello sviluppo software. Inizi oggi a migliorare il Suo processo.

Migliori il ciclo di vita dello sviluppo software: inizi subito a ottimizzarlo

Elimini i colli di bottiglia del ciclo SDLC, riduca del 30% il tempo di ciclo e migliori la qualità.

Inizi la prova gratuita

Non è richiesta la carta di credito. Inizi subito a ottimizzare.