Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software
Seu Template de Dados do Ciclo de Vida de Desenvolvimento de Software
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Guia de extração para o ServiceNow DevOps
Atributos do Ciclo de Vida de Desenvolvimento de Software
| Nome | Descrição | ||
|---|---|---|---|
| Hora de Início EventTime | O registro exato de data e hora que indica quando uma atividade ou evento específico ocorreu. | ||
| Descrição Data e hora em que cada atividade foi registrada. Essencial para ordem cronológica e análises temporais. No Process Mining, o início é usado para calcular durações entre etapas, identificar esperas e medir o ciclo total. É vital para dashboards de desempenho e cálculo de KPIs como o Lead Time de Code Review. Por que é importante Timestamp essencial para ordenar eventos e calcular métricas: tempos de ciclo, durações e esperas. Onde obter Geralmente encontrado em campos de sistema como 'sys_updated_on' ou 'sys_created_on'. Exemplos 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| Item de Desenvolvimento DevelopmentItem | O identificador exclusivo de uma unidade de trabalho, como funcionalidade ou bug, que avança pelo ciclo de desenvolvimento. | ||
| Descrição O Item de Desenvolvimento serve como o identificador principal do caso, representando uma unidade de trabalho distinta. Ele conecta todas as atividades, da concepção inicial ao deploy desse item específico. Na análise de Process Mining, este atributo é fundamental para reconstruir a jornada de ponta a ponta. Ele permite visualizar fluxos, calcular tempos de ciclo e identificar variantes de processo para cada funcionalidade ou correção. Todo evento deve estar associado a um Item de Desenvolvimento para formar um mapa de processo coerente. Por que é importante Identificador central que une todas as atividades em uma única instância, permitindo analisar o ciclo completo de cada item. Onde obter Identificador que costuma ser a chave primária das tabelas de stories, bugs ou tarefas (ex: 'rm_story', 'rm_bug' ou 'task') no ServiceNow. Exemplos STRY0010015BUG0034092TASK0050118 | |||
| Nome da Atividade ActivityName | O nome do evento específico do ciclo de vida que ocorreu, como 'Desenvolvimento Iniciado' ou 'Code Review Realizado'. | ||
| Descrição Registra o nome de cada marco ou tarefa no SDLC. Essas atividades formam os passos sequenciais, da criação ao deploy. Analisar a sequência e frequência delas é o cerne do Process Mining. Permite montar o mapa do processo, achar gargalos e apontar variações ineficientes. Inclui etapas como design, desenvolvimento, testes e deploy. Por que é importante Define as etapas no mapa do processo, permitindo a análise do fluxo, identificação de gargalos e descoberta de desvios em relação ao SDLC padrão. Onde obter Derivado mapeando mudanças de status ou auditoria para nomes de atividades padrão (ex: 'In Progress' vira 'Desenvolvimento Iniciado'). Exemplos Desenvolvimento IniciadoCódigo ComitadoTestes de QA ConcluídosImplantado em Produção | |||
| Sistema de Origem SourceSystem | Identifica o sistema de onde os dados foram extraídos, que neste caso é o ServiceNow DevOps. | ||
| Descrição Especifica o sistema de origem (neste caso, 'ServiceNow DevOps'). Pode parecer estático, mas incluir a fonte é crucial para governança de dados, especialmente se houver fusão com dados de Jira ou Azure DevOps. Garante clareza sobre a procedência e ajuda a diagnosticar problemas de qualidade ou extração. Por que é importante Garante a rastreabilidade dos dados e é essencial para manter a integridade das informações, especialmente ao integrar dados de várias ferramentas de desenvolvimento. Onde obter Este é um valor estático que deve ser adicionado durante o processo de extração e transformação de dados. Exemplos ServiceNow DevOps | |||
| Última Atualização de Dados LastDataUpdate | Timestamp da última atualização dos dados deste log a partir do sistema de origem. | ||
| Descrição Registra quando o dataset foi extraído ou atualizado. Vale para todo o conjunto de dados. Este timestamp é vital para saber o quão recente é a análise. Informa sobre a atualidade dos insights e ajuda a agendar atualizações. Exibir isso nos dashboards dá contexto às métricas, garantindo decisões baseadas em dados atualizados. Por que é importante Fornece um contexto crucial sobre a atualidade dos dados, garantindo que os usuários saibam o quão atualizada está a análise do processo. Onde obter Timestamp gerado durante a extração, marcando quando o processo foi executado. Exemplos 2023-11-15T08:00:00Z | |||
| Desenvolvedor Atribuído AssignedDeveloper | O nome ou ID do desenvolvedor ou usuário atribuído ao item no momento da atividade. | ||
| Descrição Identifica quem executa a tarefa. É dinâmico e muda conforme o item avança entre estágios e equipes. Crucial para analisar alocação, carga de trabalho e handoffs. Suporta dashboards de carga de trabalho e KPIs de volume por desenvolvedor. Ao rastrear mudanças aqui, mede-se tempos de handoff e identifica-se falhas de colaboração entre devs ou entre dev e QA. Por que é importante Essencial para análise de recursos, distribuição de carga, eficiência de handoff e padrões de performance por equipe. Onde obter Informação geralmente armazenada no campo 'assigned_to' das tabelas de tarefas do ServiceNow. Exemplos David MillerAnna WilliamsJames Brown | |||
| É Retrabalho IsRework | Um sinalizador booleano que é verdadeiro se a atividade for parte de um loop de retrabalho, como retornar ao desenvolvimento após o teste. | ||
| Descrição Atributo derivado que identifica voltas para estágios anteriores. Se o 'Desenvolvimento Iniciado' ocorre após o 'QA Concluído' no mesmo item, é marcado como retrabalho. Vital para quantificar e visualizar o retrabalho. Suporta o dashboard de 'Análise de Fluxo de Rejeição' e o KPI de 'Taxa de Retrabalho pós-Teste'. Permite filtrar e analisar causas e impactos do retrabalho no ciclo total. Por que é importante Esta flag facilita a quantificação e análise do retrabalho, ajudando a medir a qualidade do processo e identificar causas de tarefas repetidas. Onde obter Este atributo é calculado na ferramenta de Process Mining analisando a sequência de atividades para detectar movimentos de retorno no fluxo. Exemplos verdadeirofalse | |||
| Estado do Item de Desenvolvimento DevelopmentItemState | O status ou estado do item no momento do evento, como 'Open', 'In Progress' ou 'Closed'. | ||
| Descrição Reflete o status oficial do item no ServiceNow. Enquanto atividades são passos derivados, o estado é a etapa formal no workflow. O estado costuma ser a fonte para as atividades. Serve para validação e visões de alto nível. Analisar o tempo em cada estado pode mostrar gargalos diferentes da análise entre atividades, além de identificar itens parados ou resolvidos. Por que é importante Fornece o status oficial de um item de trabalho no sistema, que serve como base para derivar atividades e pode ser usado para validação e análise de status de alto nível. Onde obter Campo padrão, normalmente chamado 'state' ou 'stage', no ServiceNow. Exemplos PendenteTrabalho em AndamentoPronto para TesteFechado Concluído | |||
| Grupo de atribuição AssignmentGroup | A equipe ou grupo responsável pelo item no momento da atividade. | ||
| Descrição Identifica a equipe atribuída (ex: 'Frontend', 'Backend' ou 'QA'). Conforme o item avança, ele passa por diferentes grupos. Rastrear o grupo é essencial para entender a colaboração cross-funcional. Ajuda a achar atrasos sistêmicos na transição entre times. Suporta a análise de desempenho por equipe e carga de trabalho, identificando quais times são gargalos no fluxo geral. Por que é importante Rastreia a equipe responsável, permitindo analisar performance, balanceamento de carga e eficiência nos handoffs. Onde obter Informação armazenada no campo 'assignment_group', padrão em tabelas de tarefas no ServiceNow. Exemplos Engenharia de PlataformaEquipe de App MobileGarantia de QualidadeDevOps | |||
| Módulo/Componente Afetado ModuleComponentAffected | O módulo, aplicação ou componente específico ao qual o item de desenvolvimento se refere. | ||
| Descrição Categoriza o trabalho pela parte do sistema impactada (ex: microserviço, componente de UI ou backend). Segmentar por módulo é crucial para achar gargalos locais. Dashboards de insights por componente e KPIs de duração média usam este atributo para identificar se certas áreas do código têm ciclos mais longos, mais retrabalho ou falhas de deploy, direcionando melhor as melhorias. Por que é importante Permite que a análise seja segmentada por aplicação ou componente, ajudando a isolar gargalos ou problemas de qualidade específicos de certas partes do sistema. Onde obter Geralmente um campo customizado ou referência ao CMDB. Veja a documentação do ServiceNow DevOps. Exemplos Serviço de FaturamentoUI de Autenticação de UsuárioBanco de Dados de RelatóriosAPI Gateway | |||
| Prioridade DevelopmentItemPriority | O nível de prioridade do item, como 'Alta', 'Média' ou 'Baixa'. | ||
| Descrição Categoriza itens pela urgência de negócio. Níveis de prioridade focam as equipes no essencial e gerenciam SLAs e expectativas. No Process Mining, a prioridade é vital para análise comparativa. Permite filtrar o mapa para ver se itens urgentes seguem caminhos mais rápidos. É essencial para dashboards de tempo de entrega de alta prioridade, validando se itens críticos estão sendo agilizados. Por que é importante Permite filtrar e comparar processos para diferentes níveis de prioridade, ajudando a verificar se itens de alta prioridade são processados com mais rapidez e eficiência. Onde obter Campo padrão, geralmente chamado 'priority', nas tabelas de tarefas do ServiceNow. Exemplos 1 - Crítico2 - Alto3 - Moderada4 - Baixo | |||
| Tempo de Ciclo do Item de Desenvolvimento DevelopmentItemCycleTime | O tempo total decorrido desde a criação do item até o seu fechamento final ou deploy. | ||
| Descrição Métrica calculada que representa a duração total de um item, da primeira à última atividade. É um KPI primário para o SDLC total, suportando o indicador de 'Tempo Médio de Ciclo'. Oferece uma medida de alto nível da velocidade e eficiência. Analisar isso ao longo do tempo por prioridade ou equipe ajuda a medir o impacto das melhorias de processo. Por que é importante Representa a duração total de ponta a ponta de um item, métrica fundamental para medir a eficiência e velocidade geral do processo. Onde obter Não é um campo nativo. Calculado subtraindo o StartTime inicial do final para cada CaseId. Exemplos 15 dias e 4 horas3 dias e 12 horas32 dias 8 horas | |||
| Tipo de Item de Desenvolvimento DevelopmentItemType | A classificação do item de trabalho, como 'Feature', 'Bug', 'Technical Debt' ou 'Task'. | ||
| Descrição Distingue os tipos de trabalho no SDLC. Corrigir um bug crítico pode ser bem mais rápido que desenvolver uma nova funcionalidade. Analisar por tipo de item permite entender o desempenho de forma granular. Ajuda a responder se bugs têm mais retrabalho ou se o tempo de redução de dívida técnica está aceitável, oferecendo insights mais profundos do que uma visão genérica. Por que é importante Distingue entre diferentes tipos de trabalho, como funcionalidades e bugs, que podem ter diferentes caminhos de processo, prioridades e durações esperadas. Onde obter Pode ser determinado pela tabela de origem do registro (ex: 'rm_story' vs 'rm_bug') ou por um campo de tipo em uma tabela de tarefas genérica. Exemplos FuncionalidadeBugTarefaSpike | |||
| End Time EventEndTime | O timestamp exato que indica quando uma atividade foi concluída. Para eventos instantâneos, é igual ao Horário de Início. | ||
| Descrição Data e hora de conclusão de cada atividade. Útil para medir durações como 'Code Review' ou 'Testes de QA'. Ter horários de início e fim permite calcular tempos exatos de processamento, separando-os do tempo de espera. Isso ajuda a saber se o atraso vem de tarefas longas ou falta de recursos. Para eventos instantâneos como 'Build disparado', o fim é igual ao início. Por que é importante Permite o cálculo preciso do tempo de processamento da atividade, o que ajuda a diferenciar entre o tempo gasto trabalhando versus o tempo gasto esperando. Onde obter Pode ser derivado do início da próxima atividade ou de um campo de 'data final' no sistema de origem. Exemplos 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z | |||
| ID do Commit CommitId | O identificador exclusivo do commit de código-fonte associado ao trabalho de desenvolvimento. | ||
| Descrição Link direto do item para a mudança de código no repositório (ex: Git), capturado no evento de 'Code Committed'. No Process Mining, o ID do Commit enriquece a análise unindo dados de processo e engenharia. Permite rastrear deploys problemáticos até o código exato ou correlacionar complexidade de código com tempos de ciclo, oferecendo uma análise de causa raiz técnica e profunda. Por que é importante Vincula o evento do processo a uma alteração de código específica, permitindo uma análise de causa raiz mais profunda ao correlacionar métricas de processo com detalhes do código. Onde obter Capturado via integrações com SCM (Git, SVN). Os dados ficam em tabelas relacionadas vinculadas ao item. Exemplos a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| Motivo do retrabalho ReworkReason | Uma classificação ou descrição do porquê um item de desenvolvimento precisou de retrabalho após o teste. | ||
| Descrição Captura o motivo da falha no QA ou UAT (ex: categoria de bug, erro de requisito ou ambiente). Dá contexto crítico para análise de retrabalho. Em vez de apenas saber que houve erro, entende-se o porquê. Isso permite melhorias focadas em definição de requisitos, testes unitários ou estabilidade de ambientes para baixar a taxa de retrabalho. Por que é importante Oferece insights qualitativos sobre o porquê do retrabalho, permitindo melhorias focadas para elevar a qualidade e reduzir loops de correção. Onde obter Pode estar em 'close_notes' ou campos dedicados como 'rework_reason'. Consulte a documentação do ServiceNow. Exemplos Requisito Mal InterpretadoBug de RegressãoTeste de Performance FalhouProblema de UI/UX | |||
| Status da Implantação DeploymentStatus | Indica o resultado de uma atividade de implantação, normalmente 'Success' ou 'Failure'. | ||
| Descrição Registra o resultado do deploy em um ambiente. Vital para entender a confiabilidade da release. Essencial para dashboards de tendências de sucesso/falha e o KPI de Taxa de Falha de Deploy. Analisando esses padrões, as empresas acham problemas em testes, infraestrutura ou coordenação, focando esforços para garantir entregas mais estáveis. Por que é importante Mede diretamente o sucesso das atividades de implantação, o que é fundamental para calcular a taxa de falha de implantação e analisar a estabilidade da release. Onde obter Status registrado em tarefas de deploy ou execuções de pipeline integradas ao ServiceNow DevOps. Exemplos SucessoFalhaConcluído com avisos | |||
| Versão de Release Planejada PlannedReleaseVersion | A versão ou release de software em que a entrega do item está planejada. | ||
| Descrição Vincula o item a uma release planejada (ex: 'v2.3' ou 'Release Q4'). Vital para gestão de projetos. No Process Mining, é crucial para dashboards de aderência ao plano de release. Comparando datas reais com o planejado, as equipes medem o cumprimento do cronograma e analisam causas de atrasos, ligando o desenvolvimento operacional aos objetivos de negócio. Por que é importante Conecta o trabalho de desenvolvimento a releases específicas, permitindo a análise da adesão ao cronograma e o impacto dos atrasos de processo nos prazos de lançamento. Onde obter Informação geralmente guardada nos campos 'release' ou 'planned_release'. Consulte a documentação do ServiceNow DevOps. Exemplos v3.4.1Lançamento Q1 2024Go-Live do Projeto Phoenix | |||
Atividades do Ciclo de Vida de Desenvolvimento de Software
| Atividade | Descrição | ||
|---|---|---|---|
| Desenvolvimento Iniciado | Marca o ponto em que o desenvolvedor começa a codificar. Geralmente inferido pela mudança de status para 'In Progress', 'Development' ou 'Coding'. | ||
| Por que é importante Marco crucial que sinaliza o início da fase de construção. Essencial para medir o lead time do desenvolvedor e ciclos de code review. Onde obter Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento (ex: Story [rm_story]) é atualizado para 'In Progress' ou status equivalente. Captura Baseado no timestamp de uma mudança de estado para 'In Progress' ou valor similar. Tipo de evento inferred | |||
| Implantação Falhou | Indica que a tentativa de implantar o item de desenvolvimento em produção não teve sucesso. Isso é capturado explicitamente pelo ServiceNow DevOps quando o pipeline de CI/CD reporta uma falha. | ||
| Por que é importante Ponto final crítico de falha. Analisar sua frequência e causas é a chave para estabilizar releases e reduzir taxas de erro no deploy. Onde obter Capturado do 'completion_status' de um registro de Pipeline Execution [sn_devops_pipeline_execution]. Um status 'Failed' no horário de término marca este evento. Captura Registrado quando o pipeline de deploy em produção reporta um status de falha. Tipo de evento explicit | |||
| Implantado em Produção | Marca a conclusão bem-sucedida do deploy em produção. Capturado quando a ferramenta de CI/CD reporta que o pipeline terminou com sucesso. | ||
| Por que é importante Ponto final de sucesso do processo SDLC. Conclui o fluxo de valor e é vital para o cálculo do ciclo total. Onde obter Capturado do 'completion_status' de um registro de Pipeline Execution [sn_devops_pipeline_execution] ou de seu Stage Execution Run associado. Um status 'Success' no horário de término marca este evento. Captura Registrado quando o pipeline de deploy em produção é concluído com sucesso. Tipo de evento explicit | |||
| Item de Desenvolvimento Criado | Marca a criação de um novo item (story, bug, epic) no ServiceNow. Geralmente capturado quando um novo registro é inserido em tabelas como Story [rm_story]. | ||
| Por que é importante Evento inicial do processo SDLC. Permite medir o tempo total de ciclo e rastrear a entrada da demanda. Onde obter Registrado nas tabelas sys_audit ou sys_history_line na criação de um registro em uma tabela de desenvolvimento, como Story [rm_story], Epic [rm_epic] ou Defect [rm_defect]. O timestamp de criação geralmente está no próprio registro. Captura Capturado a partir do timestamp de criação do registro do item de desenvolvimento. Tipo de evento explicit | |||
| Revisão de Código Realizada | Indica a conclusão de um code review por pares, geralmente associado a um pull ou merge request. Pode ser capturado por integrações DevOps ou inferido por mudanças de status. | ||
| Por que é importante Barreira de qualidade crítica. Analisar sua duração ajuda a achar gargalos no review, causa comum de atrasos no SDLC. Onde obter Pode ser capturado a partir do evento 'Merged' ou 'Completed' de um registro de Pull Request na integração Git do ServiceNow, ou inferido a partir de uma mudança de status no item de desenvolvimento para 'Code Review Complete'. Captura Registrado quando um Pull Request vinculado ao item de trabalho é mesclado. Tipo de evento explicit | |||
| Testes de QA Concluídos | Indica que a equipe de Garantia de Qualidade concluiu os testes com sucesso. Geralmente inferido quando o estado do item sai da fase de testes para status como 'Ready for UAT' ou 'Done'. | ||
| Por que é importante Conclusão de uma etapa de qualidade importante. Pré-requisito para UAT ou preparação de release. Onde obter Inferido a partir do timestamp de uma mudança de estado de um status de teste (ex: 'In QA') para um status pós-teste (ex: 'Ready for UAT' ou 'Resolved'). Captura Baseado no timestamp de uma mudança de estado de 'Testing' para um estado subsequente. Tipo de evento inferred | |||
| UAT Aprovado | Indica que as partes interessadas do negócio aprovaram formalmente o item de desenvolvimento após o Teste de Aceitação do Usuário. Este é um marco importante inferido de uma mudança de status, como a transição de 'Em UAT' para 'Pronto para Release' ou 'Aprovado'. | ||
| Por que é importante Aprovação final de negócio antes do deploy em produção. Checkpoint crítico de qualidade e governança. Onde obter Inferido de uma transição de estado no registro do item de desenvolvimento que significa a conclusão bem-sucedida do UAT. Isso é registrado no histórico de atividades do item. Captura Inferido de uma mudança de estado de 'UAT' para um estado aprovado ou pronto para release. Tipo de evento inferred | |||
| Build Acionado | Sinaliza o início do build no pipeline CI/CD, geralmente disparado por um commit. O ServiceNow DevOps registra isso como uma execução de pipeline vinculada aos itens de origem. | ||
| Por que é importante Atividade que une o desenvolvimento aos testes automatizados ou deploy. Analisar o tempo entre commit e o início do build revela atrasos no processo de CI/CD. Onde obter Registrado explicitamente na tabela Pipeline Execution [sn_devops_pipeline_execution] quando um build inicia na ferramenta CI/CD integrada (ex: Jenkins, Azure DevOps). Captura Capturado a partir do horário de início de um registro na tabela Pipeline Execution. Tipo de evento explicit | |||
| Código Comitado | Representa um desenvolvedor fazendo o commit de código em um repositório vinculado ao item de desenvolvimento. O ServiceNow DevOps captura esses eventos de ferramentas SCM integradas, como Git ou GitHub. | ||
| Por que é importante Rastrear commits dá visibilidade granular do progresso e frequência, correlacionando mudanças de código ao item pai. Onde obter Capturado como um evento explícito na tabela ServiceNow DevOps Commits [sn_devops_commit], que é alimentada por webhooks do sistema de gerenciamento de código-fonte integrado. Captura Registrado quando um webhook de commit é recebido da ferramenta SCM. Tipo de evento explicit | |||
| Design Iniciado | Representa a fase de criação do design técnico ou arquitetura da solução. Geralmente inferido por uma mudança no campo de status ou estado do item para valores como 'Design' ou 'Solutioning'. | ||
| Por que é importante Analisar a duração da fase de design ajuda a identificar gargalos na tradução de requisitos e no planejamento da solução antes do início do desenvolvimento. Onde obter Inferido a partir das transições de estado no registro do item de desenvolvimento (ex: Story [rm_story]). Procure por mudanças no campo 'State' ou em um campo personalizado 'Stage' para um valor relacionado ao design. Captura Inferido de uma mudança de status para 'Design' ou estado similar. Tipo de evento inferred | |||
| Implantação em Produção Iniciada | Marca o início do pipeline de deploy para o ambiente de produção. O ServiceNow DevOps captura isso quando o estágio de produção de um pipeline CI/CD começa a ser executado. | ||
| Por que é importante Início da fase final e crítica. Rastrear isso ajuda a analisar durações de deploy e achar chances de automação. Onde obter Registrado explicitamente na tabela Stage Execution Run [sn_devops_stage_execution], filtrado para estágios relacionados ao ambiente de produção. Captura Capturado a partir do horário de início de uma etapa de implantação em produção em um Pipeline Execution. Tipo de evento explicit | |||
| Item de Desenvolvimento Cancelado | Representa o encerramento de um item antes da conclusão. É um estado final alternativo, geralmente inferido quando o estado do item é definido como 'Cancelled' ou 'Closed Incomplete'. | ||
| Por que é importante Rastrear cancelamentos ajuda a ver esforços perdidos e entender mudanças de escopo, dando uma visão completa dos desfechos do processo. Onde obter Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento é atualizado para um status terminal e não concluído, como 'Cancelled'. Captura Inferido de uma mudança de estado para 'Cancelado' ou estado terminal equivalente. Tipo de evento inferred | |||
| Preparado para Lançamento | Indica que o item passou por todos os critérios de qualidade e está em uma release específica. Inferido ao associar o item a um registro de Release ou mudança para 'Ready for Deployment'. | ||
| Por que é importante Indica que o item está pronto técnica e funcionalmente. O tempo aqui pode ser fila aguardando a janela de deploy. Onde obter Inferido quando o campo 'State' muda para 'Ready for Release' ou ao rastrear quando o campo 'Release' no registro do item de desenvolvimento é preenchido ou atualizado. Captura Inferido de uma mudança de status ou associação com um registro de Release. Tipo de evento inferred | |||
| Retrabalho Identificado | Indica que um problema foi encontrado durante o teste, exigindo que o item retorne ao desenvolvimento. Este evento é inferido ao observar um movimento de retrocesso no fluxo do processo, como uma mudança de status de 'Em QA' de volta para 'Em Andamento'. | ||
| Por que é importante Rastrear o retrabalho é vital para achar falhas de qualidade. Alta frequência indica problemas no desenvolvimento ou nos requisitos. Onde obter Inferido a partir da análise do histórico do campo 'State' nas tabelas sys_audit ou sys_history_line. Uma mudança de um status de estágio avançado (ex: 'Testing') para um anterior (ex: 'In Progress') indica retrabalho. Captura Inferido de uma transição de status de retrocesso, ex: 'Testing' -> 'In Progress'. Tipo de evento inferred | |||
| Testes de QA Iniciados | Marca o início da fase formal de testes de Garantia de Qualidade. Isso quase sempre é inferido pela mudança do estado do item de desenvolvimento para valores como 'In QA', 'Testing' ou 'Ready for Test'. | ||
| Por que é importante Sinaliza o handoff do desenvolvimento para a equipe de QA. Permite medir a duração da fase de testes e identificar gargalos de capacidade. Onde obter Inferido a partir do timestamp de quando o campo 'State' no registro do item de desenvolvimento (ex: Story, Defect) é atualizado para um status específico de QA. Captura Baseado no timestamp de uma mudança de estado para 'Testing' ou equivalente. Tipo de evento inferred | |||
| UAT Iniciado | Representa o início do Teste de Aceitação do Usuário (UAT), onde stakeholders validam a funcionalidade. Capturado ao inferir uma mudança de status para 'UAT', 'In UAT' ou 'User Acceptance Testing'. | ||
| Por que é importante Fase crítica para garantir que a feature atende ao negócio. Analisar sua duração revela falhas de engajamento ou de requisitos. Onde obter Inferido de uma transição de estado no registro do item de desenvolvimento. Isso depende do modelo de estados do cliente, que deve incluir um status distinto para UAT. Captura Inferido de uma mudança de estado para status 'UAT'. Tipo de evento inferred | |||
Guias de Extração
Etapas
- Entenda seu Modelo de Estados: Antes de criar os relatórios, documente os valores específicos no campo de estado do seu item de desenvolvimento (ex: na tabela de Story
[rm_story]ou Defect[rm_defect]) que correspondem às atividades necessárias. Por exemplo, um valor de estado 'Em Andamento' pode mapear para a atividade 'Development Started'. - Navegue até a Criação de Relatórios: Faça login na sua instância do ServiceNow. No navegador de Filtros, vá para
Reports > View / Rune clique no botãoCreate a report. - Crie o Relatório de Mudanças de Estado: Crie o primeiro relatório para capturar atividades baseadas em status. Configure-o da seguinte forma:
- Nome do Relatório:
ProcessMind - State Change Events - Tipo de Origem:
Table - Tabela:
Audit [sys_audit] - Tipo:
List - Configurar Colunas: Adicione
Document key,Created on,Table name,Field name,Old valueeNew value. - Filtro: Defina
Table namepara ser uma das suas tabelas de itens de desenvolvimento (ex:Story) eField namepara ser o seu campo de estado (ex:State). Adicione um filtro de data no campoCreated onpara o período desejado.
- Nome do Relatório:
- Crie o Relatório de Criação de Itens: Crie um novo relatório para o evento de criação inicial.
- Nome do Relatório:
ProcessMind - Item Creation Events - Tipo de Origem:
Table - Tabela:
Story [rm_story](ou sua tabela principal de itens de desenvolvimento) - Tipo:
List - Configurar Colunas: Adicione colunas para os atributos necessários como
Number,Created on,Assigned to,Priority,State, etc. - Filtro: Aplique um filtro de data no campo
Created on.
- Nome do Relatório:
- Crie o Relatório de Commits de Código: Crie um relatório para eventos explícitos de DevOps relacionados a commits.
- Nome do Relatório:
ProcessMind - Commit Events - Tipo de Origem:
Table - Tabela:
Commit [sn_devops_commit] - Tipo:
List - Configurar Colunas: Adicione colunas como
Work item,Commit time,Author, etc. - Filtro: Aplique um filtro de data no campo
Commit time.
- Nome do Relatório:
- Crie Relatórios de Builds e Implantações: Repita o processo da etapa anterior para as tabelas
Build [sn_devops_build]eDeployment [sn_devops_deployment]. Estas tabelas contêm registros para atividades comoBuild Triggered,Deployment to Production Started,Deployed to ProductioneDeployment Failed. - Exporte Todos os Relatórios: Execute cada um dos relatórios criados individualmente. Para cada relatório, clique no ícone do menu de contexto (três pontos ou seta para baixo) e selecione
Export > CSVouExport > Excel. Salve todos os arquivos. - Combine e Transforme os Dados: Abra os arquivos exportados em um programa de planilha ou use uma ferramenta de preparação de dados. Combine manualmente os dados de todos os arquivos em uma única planilha. Crie as colunas de event log necessárias (
DevelopmentItem,ActivityName,EventTime, etc.) e mapeie os dados das colunas de origem. Por exemplo, mapeie aDocument keydo relatório de auditoria e oNumberdo relatório de story para a colunaDevelopmentItem. - Mapeie os Nomes das Atividades: Crie a coluna
ActivityNametraduzindo os dados de origem. Para o relatório de mudança de estado, use seu modelo de estados documentado para mapear as entradas deNew valuepara nomes de atividades (ex: mapear o estado 'Testing' para 'QA Testing Started'). Para os outros relatórios, atribua um nome de atividade fixo para cada linha (ex: todas as linhas da exportação de commits tornam-se 'Code Committed'). - Finalize e Salve: Adicione as colunas
SourceSystemeLastDataUpdatecom valores estáticos para todas as linhas. Certifique-se de que todos os timestamps estejam em um formato consistente. Salve o arquivo combinado final como um único CSV, que agora está pronto para ser carregado no ProcessMind.
Configuração
- Tabelas Necessárias: As principais tabelas para esta extração são
Audit [sys_audit]para eventos inferidos, suas tabelas específicas de itens de desenvolvimento (ex:Story [rm_story],Defect [rm_defect]) e as tabelas centrais do ServiceNow DevOps:Commit [sn_devops_commit],Build [sn_devops_build]eDeployment [sn_devops_deployment]. - Filtros Principais: O filtro mais importante é o intervalo de datas, que deve ser aplicado de forma consistente em todos os relatórios em um campo de timestamp como
Created on,Commit timeouStart time. Para o relatóriosys_audit, é crítico filtrar peloTable name(ex:rm_story) eField name(ex:state) para limitar os dados apenas às mudanças de estado relevantes. - Recomendação de Período: Recomendamos extrair dados de um período de 3 a 6 meses para garantir um conjunto de dados representativo sem causar problemas de performance. Para sistemas maiores, considere extrair os dados em lotes mensais.
- Definição do Modelo de Estados: Você precisa ter uma compreensão clara do modelo de estados dos itens de trabalho da sua organização. Isso é necessário para mapear corretamente os valores de estado capturados na tabela
sys_auditpara as atividades de negócio correspondentes, como 'QA Testing Started' ou 'UAT Approved'. - Pré-requisitos: Os usuários que realizarem a extração precisam do papel
report_userou permissões equivalentes para criar e executar relatórios. Também precisam de acesso de leitura às tabelas de DevOps e de desenvolvimento de aplicações mencionadas acima. O plugin ServiceNow DevOps deve estar instalado e integrado ativamente com suas ferramentas de SCM e CI/CD.
a Consulta de Exemplo 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.
--- Etapas
- Pré-requisitos: Certifique-se de que você tem acesso de rede à sua instância do ServiceNow e recebeu uma conta de serviço dedicada com permissões de leitura (os papéis
itilesn_devops.viewersão um bom ponto de partida). Este usuário precisará de acesso a tabelas comorm_story,sys_audite ao esquemasn_devops_*. - Instale o Driver ODBC do ServiceNow: Baixe o driver ODBC adequado para o seu sistema operacional no portal de suporte do ServiceNow. Siga as instruções de instalação fornecidas.
- Configure o DSN: Configure um novo System DSN (Data Source Name) na máquina onde você executará a consulta. No Administrador de Fonte de Dados ODBC, adicione o driver do ServiceNow e configure-o com a URL da sua instância (ex:
suainstancia.service-now.com), usuário e senha. - Conecte-se com um Cliente SQL: Use uma ferramenta de cliente SQL como DBeaver, Microsoft SQL Server Management Studio (usando um linked server) ou uma linguagem de script como Python com uma biblioteca ODBC para se conectar ao ServiceNow usando o DSN configurado.
- Identifique o Modelo de Estados: Antes de executar a consulta, você deve identificar os valores exatos que sua organização usa para o campo
statenas tabelas de itens de desenvolvimento (ex:rm_story,rm_defect). A consulta fornecida usa exemplos comuns como 'In Progress' ou 'In QA', que você precisará substituir pelos seus valores específicos. - Personalize a Consulta SQL: Copie a consulta SQL fornecida para o seu cliente. Modifique os placeholders no topo da consulta, incluindo a data de início para a extração e os valores de estado específicos que correspondem às atividades do seu ciclo de vida de desenvolvimento.
- Execute a Consulta: Execute a consulta SQL completa no banco de dados do ServiceNow através da conexão ODBC. Isso pode levar um tempo considerável, dependendo do intervalo de datas e do volume de dados.
- Revise os Dados: Assim que a consulta for concluída, faça uma breve revisão do conjunto de dados retornado. Verifique se há uma variedade de atividades e garanta que colunas essenciais como
DevelopmentItem,ActivityNameeEventTimeestejam preenchidas como esperado. - Exporte para CSV: Exporte todo o resultado para um arquivo CSV. Certifique-se de que o arquivo esteja codificado em UTF-8 e que os cabeçalhos das colunas correspondam aos nomes de atributos exigidos pelo ProcessMind, por exemplo:
DevelopmentItem,ActivityName,EventTime. - Prepare para o Upload: Verifique se o arquivo CSV final não contém linhas vazias ao final e se o formato de data para
EventTimeeLastDataUpdateé consistente e suportado pelo ProcessMind (ex:YYYY-MM-DD HH:MM:SS).
Configuração
- Pré-requisitos: Acesso a uma instância do ServiceNow com o módulo DevOps ativado. É necessária uma conta de usuário dedicada com permissões de leitura para as tabelas exigidas. O driver ODBC do ServiceNow deve estar instalado e configurado na máquina cliente.
- Configuração do Driver ODBC: A conexão requer a URL da instância, um usuário e uma senha ou token OAuth. É fundamental testar a conexão DSN antes de tentar executar consultas complexas.
- Filtragem por Intervalo de Datas: A consulta fornecida inclui um placeholder
s.sys_created_on >= '2023-01-01'para limitar o volume de dados extraídos. Recomendamos fortemente extrair dados de um período definido, como os últimos 6 a 12 meses, para garantir tempos de execução de consulta gerenciáveis. - Customização do Modelo de Estados: A precisão da consulta para eventos inferidos depende inteiramente do modelo de estados. Você deve substituir os valores de estado de exemplo (ex:
[Your 'In Progress' State Value],[Your 'In QA' State Value]) pelos valores exatos usados na sua configuração do ServiceNow. Eles diferenciam maiúsculas de minúsculas. - Tabelas de Itens de Trabalho: A consulta foi escrita para a tabela de Story (
rm_story). Se sua organização também utiliza Defeitos (rm_defect), Melhorias (rm_enhancement) ou outros tipos de tarefas, você deve adicioná-los à Expressão de Tabela Comum (CTE) inicialDevItemsusandoUNION ALL. - Performance: Consultas diretas em uma instância de produção do ServiceNow podem impactar o desempenho. Recomendamos executar grandes extrações em horários de pouco movimento. Para conjuntos de dados muito grandes, considere uma estratégia de extração incremental baseada no campo
sys_updated_on.
a Consulta de Exemplo 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 ***