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
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per ServiceNow DevOps
Attributi del ciclo di vita dello sviluppo software
| Nome | Descrizione | ||
|---|---|---|---|
| Elemento di sviluppo DevelopmentItem | L'identificatore univoco per una singola unità di lavoro (feature, bug o task) che attraversa il ciclo di vita dello sviluppo. | ||
| Descrizione L'elemento di sviluppo funge da identificatore principale (Case ID), rappresentando l'unità di lavoro tracciata. Collega tutte le attività, dall'ideazione iniziale al deployment finale per quell'elemento specifico. Nell'analisi di process mining, questo attributo è fondamentale per ricostruire il percorso end-to-end di ogni elemento. Consente la visualizzazione dei flussi, il calcolo dei tempi di ciclo totali e l'identificazione delle varianti di processo per feature o bug fix. Ogni evento deve essere associato a un elemento di sviluppo per costruire una mappa coerente. Perché è importante Identificatore principale che connette tutte le attività di sviluppo in un'unica istanza di processo per analizzare il ciclo completo. Dove trovare Identificatore che solitamente corrisponde alla primary key delle tabelle story, bug o task in ServiceNow. Esempi STRY0010015BUG0034092TASK0050118 | |||
| Nome attività ActivityName | Il nome dello specifico evento del ciclo di vita dello sviluppo, come 'Inizio sviluppo' o 'Code review eseguita'. | ||
| Descrizione Registra il nome di ogni milestone o task completato. Queste attività formano i passaggi sequenziali del processo. Analizzare la sequenza e la frequenza di queste attività è il cuore del process mining. Permette di costruire la mappa dei processi, identificare colli di bottiglia e varianti inefficienti. Include fasi chiave come design, sviluppo, test e deployment. Perché è importante Definisce le fasi nella mappa dei processi, consentendo l'analisi del flusso, l'identificazione dei colli di bottiglia e l'individuazione di deviazioni dallo standard SDLC. Dove trovare In genere si ottiene mappando i cambi di stato o l'audit trail a nomi di attività standard. Esempio: stato 'In corso' diventa 'Inizio sviluppo'. Esempi Sviluppo iniziatoCodice committatoTest QA completatiRilasciato in produzione | |||
| Ora di Inizio EventTime | Il timestamp esatto che indica quando si è verificata una specifica attività o evento. | ||
| Descrizione Fornisce data e ora di inizio di ogni attività. È essenziale per l'ordine cronologico e le analisi temporali. Nel process mining, serve a calcolare le durate tra le fasi, i tempi di attesa e il tempo di ciclo totale. È un componente critico per le dashboard di performance (Analisi ciclo di vita end-to-end) e per calcolare KPI come il Lead Time della code review. Perché è importante Timestamp essenziale per l'ordinamento degli eventi e il calcolo delle performance: tempi di ciclo, durate e attese. Dove trovare Solitamente reperibile nei campi timestamp di sistema come 'sys_updated_on' o 'sys_created_on'. Esempi 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| Sistema di Origine SourceSystem | Identifica il sistema da cui sono stati estratti i dati, che in questo caso è ServiceNow DevOps. | ||
| Descrizione Specifica il sistema di origine dei dati, che per questo processo sarà 'ServiceNow DevOps'. Anche se costante, includerlo è cruciale per la data governance in ambienti che uniscono dati da più sistemi (es. Jira o Azure DevOps). Garantisce chiarezza sulla provenienza dei dati e aiuta a diagnosticare problemi di qualità o estrazione. Perché è importante Garantisce la tracciabilità dei dati ed è essenziale per mantenere l'integrità delle informazioni, specialmente quando si integrano dati da più strumenti di sviluppo. Dove trovare Questo è un valore statico che dovrebbe essere aggiunto durante il processo di estrazione e trasformazione dei Esempi ServiceNow DevOps | |||
| Ultimo `Data Update` LastDataUpdate | Timestamp dell'ultimo aggiornamento dei dati dell'event log dal sistema sorgente. | ||
| Descrizione Indica l'ultima estrazione o aggiornamento del dataset da ServiceNow DevOps. È vitale per capire quanto siano attuali gli insight. Informa gli utenti sulla freschezza dei dati e aiuta a pianificare i refresh. Mostrare questo timestamp nelle dashboard garantisce che le decisioni siano basate su informazioni tempestive. Perché è importante Fornisce un contesto cruciale sulla tempestività dei dati, garantendo che gli utenti sappiano quanto sia aggiornata l'analisi del processo. Dove trovare Generato durante l'estrazione dati, registra il momento esatto dell'esecuzione. Esempi 2023-11-15T08:00:00Z | |||
| È una Rilavorazione IsRework | Un flag booleano impostato su vero se l'attività fa parte di un loop di rework, come il ritorno allo sviluppo dopo la fase di test. | ||
| Descrizione Attributo derivato che identifica attività avvenute dopo un loop all'indietro. Se 'Inizio Sviluppo' avviene dopo 'QA Completata', viene segnato come rework. È essenziale per quantificare il rework. Supporta la dashboard 'Analisi flussi di scarto e rework' e calcola il KPI 'Tasso di rework post-test'. Permette di filtrare e analizzare frequenza e cause del lavoro ripetuto sul tempo totale. Perché è importante Questo flag semplifica la quantificazione del rework, aiutando a misurare la qualità del processo e a trovare le cause dei lavori ripetuti. Dove trovare Attributo calcolato dallo strumento di process mining analizzando la sequenza di attività per rilevare movimenti retrogradi nel flusso (loop). Esempi truefalse | |||
| Gruppo di Assegnazione AssignmentGroup | Il team o il gruppo responsabile dell'elemento al momento dell'attività. | ||
| Descrizione Identifica il team assegnato (es. 'Frontend', 'QA'). Il tracciamento dell'assignment group è essenziale per comprendere la collaborazione interfunzionale e i passaggi di consegna. Aiuta a individuare i ritardi sistemici che avvengono quando il lavoro passa da un team all'altro, supportando l'analisi delle performance di squadra e identificando quali team rappresentano un collo di bottiglia nel flusso globale. Perché è importante Traccia il team responsabile, permettendo l'analisi delle performance, del bilanciamento dei carichi e dell'efficienza dei passaggi di consegna. Dove trovare Informazione memorizzata nel campo 'assignment_group', standard nelle tabelle task di ServiceNow. Esempi Platform EngineeringTeam Mobile AppAssicurazione QualitàDevOps | |||
| Modulo/Componente interessato ModuleComponentAffected | Lo specifico modulo, applicazione o componente software a cui si riferisce l'elemento di sviluppo. | ||
| Descrizione Questo attributo categorizza il lavoro in base alla parte di sistema interessata (microservizio, componente UI o backend). Segmentare il processo per modulo è cruciale per identificare colli di bottiglia localizzati. La dashboard 'Insight colli di bottiglia per componente' e il KPI 'Durata media fase per componente' usano questo dato per capire se certe aree del codice hanno cicli più lunghi o più errori, permettendo di concentrare i miglioramenti dove serve davvero. Perché è importante Consente di segmentare l'analisi per applicazione o componente, aiutando a isolare bottleneck o problemi di qualità specifici di determinate parti del sistema. Dove trovare Spesso è un campo personalizzato o un riferimento al CMDB ('cmdb_ci'). Consulti la documentazione di ServiceNow DevOps. Esempi Servizio di fatturazioneUI Autenticazione UtenteDatabase per la reportisticaAPI Gateway | |||
| Priorità DevelopmentItemPriority | Il livello di priorità assegnato all'elemento, come 'Alta', 'Media' o 'Bassa'. | ||
| Descrizione Questo attributo categorizza gli elementi in base all'urgenza aziendale. I livelli di priorità aiutano i team a concentrarsi sui task critici e sono usati per gestire SLA e aspettative. Nel process mining, la priorità è fondamentale per l'analisi comparativa. Permette di filtrare la mappa dei processi per verificare se gli elementi critici seguono percorsi più rapidi. È essenziale per la dashboard 'Tempo di consegna feature ad alta priorità', validando l'effettiva accelerazione dei task urgenti. Perché è importante Consente di filtrare e confrontare i processi per diversi livelli di priorità, aiutando a verificare se gli elementi urgenti siano gestiti in modo più rapido ed efficiente. Dove trovare Campo standard, solitamente denominato 'priority', sulle tabelle task di ServiceNow. Esempi 1 - Critico2 - Alto3 - Moderate4 - Basso | |||
| Stato dell'elemento di sviluppo DevelopmentItemState | Lo stato dell'elemento di sviluppo al momento dell'evento, come 'Aperto', 'In corso' o 'Chiuso'. | ||
| Descrizione Riflette lo stato ufficiale dell'elemento in ServiceNow. Mentre le attività sono passaggi derivati, lo 'State' rappresenta la fase formale nel workflow del sistema. Spesso è la fonte da cui si ricavano le attività. Può essere usato per validare i dati o creare viste di alto livello. Analizzare il tempo trascorso in ogni stato può offrire una prospettiva diversa sui colli di bottiglia rispetto al tempo tra le attività, ed è utile per identificare task bloccati. Perché è importante Fornisce lo stato ufficiale di sistema di un elemento di lavoro, che è spesso la fonte per ricavare le attività e può essere utilizzato per la validazione e l'analisi di stato ad alto livello. Dove trovare Campo standard, solitamente 'state' o 'stage', sulle tabelle task di ServiceNow. Esempi In SospesoLavoro in corsoPronto per il testChiuso Completato | |||
| Sviluppatore assegnato AssignedDeveloper | Il nome o l'ID dello sviluppatore o dell'utente assegnato all'elemento al momento dell'attività. | ||
| Descrizione Identifica la persona responsabile di un task. È un dato dinamico che cambia con il progredire dell'elemento tra team e fasi. È fondamentale per analizzare l'allocazione delle risorse e il carico di lavoro. Supporta la dashboard 'Carico di lavoro e passaggi di consegna' e il KPI 'Volume attività per sviluppatore'. Tracciare questo campo permette di misurare i tempi di consegna e individuare colli di bottiglia nella collaborazione tra developer o tra sviluppo e QA. Perché è importante Essenziale per l'analisi basata sulle risorse, inclusa la distribuzione del carico e l'efficienza dei passaggi tra team. Dove trovare Dato solitamente memorizzato nel campo 'assigned_to' nelle tabelle task di ServiceNow. Esempi David MillerAnna WilliamsJames Brown | |||
| Tempo di ciclo dell'elemento di sviluppo DevelopmentItemCycleTime | Il tempo totale trascorso dalla creazione dell'elemento alla sua chiusura finale o al deployment. | ||
| Descrizione Metrica calcolata che rappresenta la durata end-to-end di un elemento, misurando la differenza tra il timestamp della prima e dell'ultima attività. È il KPI principale dell'intero processo SDLC (Tempo di ciclo medio), fornendo una misura della velocità e dell'efficienza. Analizzare questa metrica nel tempo e per dimensioni (priorità, team) permette di monitorare l'impatto reale delle iniziative di miglioramento. Perché è importante Rappresenta la durata totale end-to-end di un elemento di lavoro, una metrica chiave per misurare l'efficienza e la velocità complessiva del processo. Dove trovare Non è un campo del sistema sorgente. È calcolato sottraendo lo StartTime minimo dal massimo per ogni CaseId. Esempi 15 giorni 4 ore3 giorni e 12 ore32 giorni 8 ore | |||
| Tipo elemento di sviluppo DevelopmentItemType | La classificazione dell'elemento di lavoro, come 'Feature', 'Bug', 'Debito tecnico' o 'Task'. | ||
| Descrizione Questo attributo distingue le diverse tipologie di lavoro nell'SDLC. Ad esempio, risolvere un bug critico può seguire un iter diverso e più rapido rispetto allo sviluppo di una feature. L'analisi per tipo di elemento offre una comprensione più sfumata delle performance. Aiuta a capire se i bug hanno tassi di rework più alti delle feature o se il tempo di ciclo per la riduzione del debito tecnico è accettabile, fornendo insight molto più granulari di una visione generica. Perché è importante Distingue tra diversi tipi di lavoro, come feature e bug, che potrebbero seguire percorsi di processo, priorità e durate previste differenti. Dove trovare Può essere determinato dalla tabella di origine (es. 'rm_story' vs 'rm_bug') o da un campo 'type' su una tabella task generica. Esempi FunzionalitàBugTaskSpike | |||
| ID Commit CommitId | L'identificatore univoco del commit del codice sorgente associato al lavoro di sviluppo. | ||
| Descrizione Fornisce un link diretto tra l'elemento e la modifica nel repository (es. Git). Viene acquisito durante il commit. Il Commit ID arricchisce l'analisi collegando i dati di processo a quelli di engineering. Permette di risalire dal deployment problematico alla riga di codice esatta o di correlare la complessità del codice ai tempi di sviluppo, offrendo un livello tecnico molto più profondo nell'analisi delle cause. Perché è importante Collega l'evento del processo a una specifica modifica del codice, consentendo un'analisi delle cause profonde più accurata grazie alla correlazione tra metriche di processo e dettagli a livello di codice. Dove trovare Dato acquisito tramite le integrazioni DevOps con SCM come Git o SVN. I dati si trovano nelle tabelle collegate all'elemento di sviluppo. Esempi a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| Motivo Rilavorazione ReworkReason | Una classificazione o descrizione del motivo per cui un elemento di sviluppo ha richiesto un rework dopo i test. | ||
| Descrizione Se un elemento fallisce QA o UAT, cattura il motivo dell'errore (bug, requisiti poco chiari, problemi di ambiente). Questo dato è cruciale per la dashboard 'Analisi flussi di scarto e rework'. Permette di capire il perché del rework e intervenire in modo mirato (es. test più stabili o requisiti migliori) per ridurre il tasso complessivo di rilavorazione. Perché è importante Fornisce insight qualitativi sul motivo per cui si verifica il rework, consentendo miglioramenti mirati del processo per aumentare la qualità e ridurre i cicli di rilavorazione. Dove trovare Può trovarsi nei 'close_notes' o in un campo 'rework_reason'. Consulti la documentazione ServiceNow DevOps. Esempi Requisito fraintesoBug di regressioneTest delle prestazioni fallitoProblema UI/UX | |||
| Ora di Fine EventEndTime | Il timestamp esatto del completamento di un'attività. Per gli eventi istantanei, coincide con l'ora di inizio. | ||
| Descrizione Fornisce data e ora di fine di ogni attività. È utile per fasi con durata misurabile come 'Code review' o 'QA'. Avere sia l'inizio che la fine permette di calcolare i tempi di elaborazione netti, distinguendoli dai tempi di attesa. Questo aiuta a capire se i ritardi sono dovuti a task complessi o a tempi morti in attesa di risorse. Per eventi istantanei (es. build avviata), i due timestamp coincidono. Perché è importante Consente il calcolo preciso del tempo di elaborazione dell'attività, aiutando a distinguere tra il tempo di lavoro effettivo e il tempo di attesa. Dove trovare Potrebbe essere derivato dal timestamp dell'inizio dell'attività successiva o da un campo 'end date' nel sistema sorgente. Esempi 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z | |||
| Stato del rilascio DeploymentStatus | Indica l'esito di un'attività di rilascio, solitamente 'Success' (successo) o 'Failure' (fallimento). | ||
| Descrizione Registra l'esito del deployment. È fondamentale per valutare l'affidabilità del processo di rilascio. Supporta la dashboard 'Trend successi e fallimenti deployment' e il KPI 'Tasso di errore deployment'. Analizzando questi trend, le aziende individuano problemi nei test, nell'infrastruttura o nel coordinamento, migliorando la stabilità della consegna software. Perché è importante Misura direttamente il successo delle attività di rilascio, il che è fondamentale per calcolare il tasso di errore dei rilasci e analizzare la stabilità delle release. Dove trovare Stato solitamente registrato nei task di deployment o nei record di esecuzione della pipeline integrata. Esempi SuccessoFallimentoCompletato con avvisi | |||
| Versione di rilascio pianificata PlannedReleaseVersion | La release o versione software di destinazione prevista per la consegna dell'elemento. | ||
| Descrizione Collega l'elemento a una release pianificata (es. 'Versione 2.3'). È un elemento chiave per il project management. Nel process mining, è fondamentale per la dashboard 'Monitoraggio aderenza piano di rilascio'. Confrontando le date di completamento reali con quelle pianificate, i team misurano il rispetto delle scadenze e analizzano le cause dei ritardi, collegando i dettagli tecnici agli obiettivi di business. Perché è importante Collega il lavoro di sviluppo a release specifiche, consentendo l'analisi del rispetto della pianificazione e dell'impatto dei ritardi del processo sulle tempistiche di rilascio. Dove trovare Dato solitamente memorizzato nei campi 'release' o 'planned_release', che puntano alla gestione release di ServiceNow. Consulti la documentazione specifica. Esempi v3.4.1Rilascio Q1 2024Go-Live Progetto Phoenix | |||
Attività del ciclo di vita dello sviluppo software
| Activity | Descrizione | ||
|---|---|---|---|
| Code Review eseguita | Questa attività indica il completamento di una peer review, solitamente associata a una pull o merge request. L'evento può essere acquisito tramite integrazioni DevOps o ricavato dai cambi di stato. | ||
| Perché è importante Rappresenta un quality gate fondamentale. Analizzarne la durata aiuta a trovare blocchi nel processo di revisione, causa comune di ritardi nell'SDLC. Dove trovare Può essere acquisito dall'evento 'Merged' o 'Completed' di un record di Pull Request nell'integrazione Git di ServiceNow, oppure dedotto da un cambio di stato dell'elemento di sviluppo in 'Revisione codice completata'. Acquisisci Registrato quando viene eseguito il merge di una Pull Request collegata all'elemento di lavoro. Tipo di evento explicit | |||
| Elemento di sviluppo creato | Questa attività segna la creazione di un nuovo elemento (story, bug o epic) in ServiceNow. L'evento viene solitamente acquisito quando un nuovo record viene inserito nella tabella Story [rm_story]. | ||
| Perché è importante Evento di inizio principale dell'SDLC. Permette di misurare il tempo di ciclo totale e tracciare l'ingresso iniziale delle richieste. Dove trovare Registrato nelle tabelle sys_audit o sys_history_line alla creazione di un record in una tabella relativa allo sviluppo, come Story [rm_story], Epic [rm_epic] o Defect [rm_defect]. Il timestamp di creazione si trova solitamente sul record stesso. Acquisisci Acquisito dal timestamp di creazione del record dell'elemento di sviluppo. Tipo di evento explicit | |||
| Rilasciato in produzione | Segna il completamento con successo del deployment in produzione. Viene acquisito esplicitamente quando lo strumento CI/CD conferma la riuscita della pipeline. | ||
| Perché è importante Punto finale di successo del processo SDLC. Completa il flusso di valore ed è fondamentale per il calcolo del tempo di ciclo totale. Dove trovare Acquisito dal campo 'completion_status' di un record Pipeline Execution [sn_devops_pipeline_execution] o della relativa esecuzione della fase (Stage Execution Run). Uno stato 'Success' al termine dell'operazione contrassegna questo evento. Acquisisci Registrato al completamento con successo della pipeline di deployment in produzione. Tipo di evento explicit | |||
| Rilascio fallito | Indica che il tentativo di rilascio dell'elemento di sviluppo in produzione non è andato a buon fine. Questo dato viene acquisito esplicitamente da ServiceNow DevOps quando la pipeline CI/CD segnala un errore. | ||
| Perché è importante Questo è un punto finale di errore critico. Analizzarne frequenza e cause è la chiave per migliorare la stabilità dei rilasci e ridurre i fallimenti. Dove trovare Acquisito dal campo 'completion_status' di un record Pipeline Execution [sn_devops_pipeline_execution]. Uno stato 'Failed' al termine dell'operazione contrassegna questo evento. Acquisisci Registrato quando la pipeline di deployment in produzione segnala uno stato di errore. Tipo di evento explicit | |||
| Sviluppo iniziato | Questa attività indica quando uno sviluppatore inizia effettivamente a programmare o implementare l'elemento. In genere viene ricavata dal cambio di stato in 'In corso' o 'Sviluppo'. | ||
| Perché è importante Milestone cruciale che segna l'inizio della fase di costruzione. Essenziale per misurare il lead time degli sviluppatori e i cicli di code review. Dove trovare Dedotto dal timestamp in cui il campo 'State' nel record dell'elemento di sviluppo (ad es. Story [rm_story]) viene aggiornato a uno stato 'In corso' o equivalente. Acquisisci Basato sul timestamp di un cambio di stato in 'In corso' o un valore simile. Tipo di evento inferred | |||
| Test QA completati | Indica che il team di QA ha completato con successo i test. Solitamente viene ricavato quando lo stato dell'elemento passa dalla fase di test a uno stato come 'Pronto per UAT' o 'Completato'. | ||
| Perché è importante Milestone che segna il superamento di un quality gate. È prerequisito per UAT o preparazione del rilascio. Dove trovare Dedotto dal timestamp di un cambio di stato da uno stato di test (ad es. 'In QA') a uno stato post-test (ad es. 'Pronto per UAT' o 'Risolto'). Acquisisci Basato sul timestamp di un cambio di stato da 'Testing' a uno stato successivo. Tipo di evento inferred | |||
| UAT Approvato | Indica che gli stakeholder aziendali hanno approvato formalmente l'elemento di sviluppo dopo lo User Acceptance Testing (UAT). Si tratta di una pietra miliare chiave dedotta da un cambio di stato, come il passaggio da 'In UAT' a 'Pronto per il rilascio' o 'Approvato'. | ||
| Perché è importante Approvazione aziendale finale prima della produzione. Rappresenta un checkpoint critico per qualità e governance. Dove trovare Dedotto da una transizione di stato nel record dell'elemento di sviluppo che indica il completamento con successo dell'UAT. Questo dato viene registrato nella cronologia delle attività dell'elemento. Acquisisci Dedotto da un cambio di stato da 'UAT' a uno stato di approvazione o di prontezza al rilascio. Tipo di evento inferred | |||
| Build avviata | Indica l'avvio della build in una pipeline CI/CD, spesso attivata da un commit. ServiceNow DevOps registra l'evento come esecuzione della pipeline, collegandolo agli elementi di sviluppo. | ||
| Perché è importante Questa attività fa da ponte tra lo sviluppo e il test o deployment automatizzato. Analizzare il tempo tra commit e avvio della build può rivelare ritardi nel processo CI/CD. Dove trovare Registrato esplicitamente nella tabella Pipeline Execution [sn_devops_pipeline_execution] quando viene avviata una build nello strumento CI/CD integrato (es. Jenkins, Azure DevOps). Acquisisci Acquisito dall'ora di inizio di un record nella tabella Pipeline Execution. Tipo di evento explicit | |||
| Codice committato | Rappresenta un commit di codice da parte di uno sviluppatore in un repository SCM collegato all'elemento di sviluppo. ServiceNow DevOps acquisisce esplicitamente questi eventi da strumenti integrati come Git o GitHub. | ||
| Perché è importante Il tracciamento dei commit offre visibilità granulare sui progressi e permette di correlare le modifiche al codice all'elemento di sviluppo padre. Dove trovare Acquisito come evento esplicito nella tabella ServiceNow DevOps Commits [sn_devops_commit], popolata tramite webhook dal sistema di gestione del codice sorgente integrato. Acquisisci Registrato quando viene ricevuto un webhook di commit dallo strumento SCM. Tipo di evento explicit | |||
| Design iniziato | Rappresenta la fase in cui viene creato il design tecnico o l'architettura della soluzione. Solitamente viene ricavata dal cambio di stato del record dell'elemento di sviluppo in valori come 'Design' o 'Solutioning'. | ||
| Perché è importante Analizzare la durata della fase di design aiuta a identificare i bottleneck nella traduzione dei requisiti e nella pianificazione della soluzione prima dell'inizio del lavoro di sviluppo. Dove trovare Dedotto dalle transizioni di stato nel record dell'elemento di sviluppo (ad es. Story [rm_story]). Si cercano modifiche al campo 'State' o a un campo personalizzato 'Stage' verso un valore relativo al design. Acquisisci Dedotto da un cambio di stato in 'Design' o uno stato simile. Tipo di evento inferred | |||
| Elemento di sviluppo annullato | Rappresenta l'interruzione di un elemento di sviluppo prima del completamento. È uno stato finale alternativo, solitamente ricavato quando lo stato dell'elemento è 'Annullato' o 'Chiuso incompleto'. | ||
| Perché è importante Tracciare gli annullamenti aiuta a individuare gli sforzi sprecati e a capire i motivi dei cambi di scope o priorità, offrendo un quadro completo del processo. Dove trovare Ricavato dal timestamp relativo all'aggiornamento del campo 'Stato' del record dell'elemento di sviluppo verso uno stato finale non completato, come 'Annullato'. Acquisisci Dedotto da un cambio di stato in 'Annullato' o uno stato terminale equivalente. Tipo di evento inferred | |||
| Inizio rilascio in produzione | Questa attività segna l'avvio della pipeline di deployment in produzione. ServiceNow DevOps la acquisisce come evento esplicito all'inizio dell'esecuzione della fase di produzione. | ||
| Perché è importante Segna l'inizio dell'ultima fase, spesso la più critica. Tracciarla aiuta ad analizzare la durata del deployment e a trovare opportunità di automazione. Dove trovare Registrato esplicitamente nella tabella Stage Execution Run [sn_devops_stage_execution], filtrata per le fasi relative all'ambiente di produzione. Acquisisci Acquisito dall'ora di inizio di una fase di rilascio in produzione in una Pipeline Execution. Tipo di evento explicit | |||
| Pronto per il rilascio | Questa attività indica che l'elemento ha superato tutti i quality gate ed è incluso in una release. Si ricava dall'associazione a un record di Release o dal cambio di stato in 'Pronto per il deployment'. | ||
| Perché è importante Indica che l'elemento è completo. Il tempo passato in questo stato rappresenta spesso la coda prima della finestra di deployment programmata. Dove trovare Dedotto dal cambio del campo 'State' in 'Pronto per il rilascio' o tracciando quando il campo 'Release' nel record dell'elemento di sviluppo viene popolato o aggiornato. Acquisisci Dedotto da un cambio di stato o dall'associazione con un record di release. Tipo di evento inferred | |||
| Rework identificato | Indica che è stato riscontrato un problema durante i test, rendendo necessario il rinvio dell'elemento allo sviluppo. Questo evento viene dedotto osservando un movimento a ritroso nel flusso del processo, come un cambio di stato da 'In QA' di nuovo a 'In corso'. | ||
| Perché è importante Tracciare il rework è vitale per capire problemi di qualità e inefficienze. Un'alta frequenza indica criticità nello sviluppo o poca chiarezza nei requisiti. Dove trovare Dedotto analizzando la cronologia del campo 'State' nelle tabelle sys_audit o sys_history_line. Un passaggio da uno stato di fase avanzata (ad es. 'Testing') a uno precedente (ad es. 'In corso') indica un rework. Acquisisci Dedotto da una transizione di stato all'indietro, ad es. 'Testing' -> 'In corso'. Tipo di evento inferred | |||
| Test QA iniziati | Segna l'inizio della fase formale di Quality Assurance. Questo dato viene quasi sempre ricavato dal cambio di stato dell'elemento di sviluppo in valori come 'In QA', 'Testing' o 'Ready for Test'. | ||
| Perché è importante Questa attività segnala il passaggio dallo sviluppo al team di QA. Permette di misurare la durata della fase di test e identificare eventuali limiti di capacità. Dove trovare Dedotto dal timestamp in cui il campo 'State' nel record dell'elemento di sviluppo (ad es. Story, Defect) viene aggiornato a uno stato specifico per la QA. Acquisisci Basato sul timestamp di un cambio di stato in 'Testing' o equivalente. Tipo di evento inferred | |||
| UAT Avviato | Rappresenta l'inizio dell'UAT, dove gli stakeholder aziendali validano la funzionalità. L'evento viene acquisito tramite il cambio di stato in 'UAT' o 'User Acceptance Testing'. | ||
| Perché è importante Fase critica per garantire che la feature soddisfi i requisiti. Analizzarne la durata rivela problemi di engagement o incongruenze nei requisiti. Dove trovare Dedotto da una transizione di stato nel record dell'elemento di sviluppo. Questo dipende dal modello degli stati del cliente, che deve includere uno stato distinto per l'UAT. Acquisisci Dedotto da un cambio di stato verso uno stato di 'UAT'. Tipo di evento inferred | |||
Guide all'Estrazione
Fasi
- Comprendere il modello degli stati: prima di creare i report, documenti i valori specifici nel campo di stato dell'elemento di sviluppo (ad es. nella tabella Story
[rm_story]o Defect[rm_defect]) che corrispondono alle attività richieste. Ad esempio, un valore di stato 'In Progress' potrebbe corrispondere all'attività 'Inizio sviluppo'. - Navigare alla creazione dei report: acceda alla sua istanza ServiceNow. Nel navigatore dei filtri, vada su
Reports > View / Rune clicchi sul pulsanteCreate a report. - Creare il report per i cambi di stato: crei il primo report per acquisire le attività basate sullo stato. Lo configuri come segue:
- Report Name:
ProcessMind - State Change Events - Source type:
Table - Table:
Audit [sys_audit] - Type:
List - Configure Columns: aggiunga
Document key,Created on,Table name,Field name,Old valueeNew value. - Filter: imposti
Table namesu una delle sue tabelle di elementi di sviluppo (ad es.Story) eField namesul suo campo di stato (ad es.State). Aggiunga un filtro data sul campoCreated onper il periodo desiderato.
- Report Name:
- Creare il report per la creazione dell'elemento: crei un nuovo report per l'evento di creazione iniziale.
- Report Name:
ProcessMind - Item Creation Events - Source type:
Table - Table:
Story [rm_story](o la sua tabella principale degli elementi di sviluppo) - Type:
List - Configure Columns: aggiunga colonne per gli attributi richiesti come
Number,Created on,Assigned to,Priority,State, ecc. - Filter: applichi un filtro data sul campo
Created on.
- Report Name:
- Creare il report per i commit del codice: crei un report per gli eventi DevOps espliciti relativi ai commit.
- Report Name:
ProcessMind - Commit Events - Source type:
Table - Table:
Commit [sn_devops_commit] - Type:
List - Configure Columns: aggiunga colonne come
Work item,Commit time,Author, ecc. - Filter: applichi un filtro data sul campo
Commit time.
- Report Name:
- Creare report per build e release: ripeta il processo del passaggio precedente per le tabelle
Build [sn_devops_build]eDeployment [sn_devops_deployment]. Queste tabelle contengono record per le attivitàBuild Triggered,Deployment to Production Started,Deployed to ProductioneDeployment Failed. - Esportare tutti i report: esegua singolarmente ciascuno dei report creati. Per ogni report, clicchi sull'icona del menu contestuale (tre punti o freccia verso il basso) e selezioni
Export > CSVoExport > Excel. Salvi tutti i file. - Combinare e trasformare i dati: apra i file esportati in un foglio di calcolo o utilizzi uno strumento di data preparation. Combini manualmente i dati di tutti i file in un unico foglio. Crei le colonne necessarie per l'Event Log (
DevelopmentItem,ActivityName,EventTime, ecc.) e mappi i dati dalle colonne sorgente. Ad esempio, mappi laDocument keydal report di audit e ilNumberdal report delle story nella colonnaDevelopmentItem. - Mappare i nomi delle attività: crei la colonna
ActivityNametraducendo i dati sorgente. Per il report sui cambi di stato, utilizzi il suo modello degli stati documentato per mappare le vociNew valueai nomi delle attività (ad es. mappi lo stato 'Testing' in 'Inizio test QA'). Per gli altri report, assegni un nome attività fisso per ogni riga (ad es. tutte le righe dall'esportazione dei commit diventano 'Codice committato'). - Finalizzare e salvare: aggiunga le colonne
SourceSystemeLastDataUpdatecon valori statici per tutte le righe. Si assicuri che tutti i timestamp siano in un formato coerente. Salvi il file finale combinato come un unico CSV, che è ora pronto per essere caricato su ProcessMind.
Configurazione
- Tabelle richieste: le tabelle principali necessarie per l'estrazione sono
Audit [sys_audit]per gli eventi dedotti, le tabelle specifiche per gli elementi di sviluppo (ad es.Story [rm_story],Defect [rm_defect]) e le tabelle core di ServiceNow DevOps:Commit [sn_devops_commit],Build [sn_devops_build]eDeployment [sn_devops_deployment]. - Filtri chiave: il filtro più importante è l'intervallo temporale, che deve essere applicato in modo coerente a tutti i report su un campo timestamp come
Created on,Commit timeoStart time. Per il reportsys_audit, è fondamentale filtrare perTable name(ad es.rm_story) eField name(ad es.state) per limitare i dati ai soli cambi di stato rilevanti. - Intervallo temporale consigliato: si raccomanda di estrarre dati per un periodo di 3-6 mesi per garantire un set di dati rappresentativo senza causare problemi di performance. Per i sistemi più grandi, valuti l'estrazione dei dati in batch mensili.
- Definizione del modello degli stati: è necessario avere una chiara comprensione del modello degli stati degli elementi di lavoro (work item) della propria organizzazione. Ciò è indispensabile per mappare correttamente i valori di stato acquisiti nella tabella
sys_auditcon le corrispondenti attività di business come "Inizio test QA" o "Approvazione UAT". - Prerequisiti: gli utenti che eseguono l'estrazione devono disporre del ruolo
report_usero di permessi equivalenti per creare ed eseguire report. È inoltre necessario l'accesso in lettura alle tabelle DevOps e di sviluppo applicativo sopra menzionate. Il plugin ServiceNow DevOps deve essere installato e integrato attivamente con i propri strumenti SCM e CI/CD.
a Query di Esempio config
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- Fasi
- Prerequisiti: si assicuri di avere accesso di rete alla sua istanza ServiceNow e di aver ricevuto un account di servizio dedicato con permessi di lettura (i ruoli
itilesn_devops.viewersono un buon punto di partenza). Questo utente dovrà accedere a tabelle qualirm_story,sys_audite allo schemasn_devops_*. - Installazione del driver ODBC di ServiceNow: scarichi il driver ODBC ServiceNow appropriato per il suo sistema operativo dal portale di supporto ServiceNow. Segua le istruzioni di installazione fornite.
- Configurazione DSN: configuri un nuovo System DSN (Data Source Name) sulla macchina in cui eseguirà la query. In Amministrazione origine dati ODBC, aggiunga il driver ServiceNow e lo configuri con l'URL della sua istanza (ad es.
yourinstance.service-now.com), nome utente e password. - Connessione con un client SQL: utilizzi uno strumento client SQL come DBeaver, Microsoft SQL Server Management Studio (utilizzando un linked server) o un linguaggio di scripting come Python con una libreria ODBC per connettersi a ServiceNow utilizzando il DSN configurato.
- Identificazione del modello degli stati: prima di eseguire la query, deve identificare i valori esatti che la sua organizzazione utilizza per il campo
statenelle tabelle degli elementi di sviluppo (ad es.rm_story,rm_defect). La query fornita utilizza esempi comuni come 'In Progress' o 'In QA', che dovrà sostituire con i suoi valori specifici. - Personalizzazione della query SQL: copi la query SQL fornita nel suo client. Modifichi i segnaposto all'inizio della query, inclusa la data di inizio per l'estrazione e i valori di stato specifici che corrispondono alle attività del suo ciclo di vita dello sviluppo.
- Esecuzione della query: esegua la query SQL completa sul database ServiceNow tramite la connessione ODBC. L'operazione potrebbe richiedere tempo a seconda dell'intervallo di date e del volume dei dati.
- Revisione dei dati: una volta completata la query, esegua una rapida revisione del set di dati restituito. Verifichi la varietà delle attività e si assicuri che le colonne chiave come
DevelopmentItem,ActivityNameeEventTimesiano popolate correttamente. - Esportazione in CSV: esporti l'intero set di risultati in un file CSV. Si assicuri che il file sia codificato in UTF-8 e che le intestazioni delle colonne corrispondano ai nomi degli attributi richiesti da ProcessMind, ad esempio
DevelopmentItem,ActivityName,EventTime. - Preparazione per l'upload: verifichi che il file CSV finale non contenga righe vuote alla fine e che il formato della data per
EventTimeeLastDataUpdatesia coerente e supportato da ProcessMind (ad es.YYYY-MM-DD HH:MM:SS).
Configurazione
- Prerequisiti: accesso a un'istanza ServiceNow con il modulo DevOps abilitato. È necessario un account utente dedicato con permessi di lettura per le tabelle richieste. Il driver ODBC di ServiceNow deve essere installato e configurato sulla macchina client.
- Configurazione del driver ODBC: la connessione richiede l'URL dell'istanza, un nome utente e una password o un token OAuth. È fondamentale testare la connessione DSN prima di tentare l'esecuzione di query complesse.
- Filtro intervallo temporale: la query fornita include un segnaposto
s.sys_created_on >= '2023-01-01'per limitare la quantità di dati estratti. Si raccomanda caldamente di estrarre dati per un periodo definito, ad esempio gli ultimi 6-12 mesi, per garantire tempi di esecuzione delle query gestibili. - Personalizzazione del modello degli stati: l'accuratezza della query per gli eventi dedotti dipende interamente dal modello degli stati. Deve sostituire i valori di stato segnaposto (ad es.
[Il valore del suo stato 'In corso'],[Il valore del suo stato 'In QA']) con i valori esatti utilizzati nella configurazione di ServiceNow. Tali valori sono sensibili alle maiuscole (case sensitive). - Tabelle degli elementi di lavoro: la query è scritta per la tabella Story (
rm_story). Se la sua organizzazione utilizza anche Defect (rm_defect), Enhancement (rm_enhancement) o altri tipi di attività, deve aggiungerli alla Common Table Expression (CTE)DevItemsiniziale utilizzandoUNION ALL. - Performance: le query dirette verso un'istanza di produzione ServiceNow possono influire sulle prestazioni. Si consiglia di eseguire le estrazioni di grandi dimensioni durante le ore non di punta. Per set di dati molto voluminosi, valuti una strategia di estrazione incrementale basata sul campo
sys_updated_on.
a Query di Esempio sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value ***