Seu Template de dados do ciclo de vida de desenvolvimento de software

GitHub
Seu Template de dados do ciclo de vida de desenvolvimento de software

Seu Template de dados do ciclo de vida de desenvolvimento de software

Este Template traz orientações completas para coletar e preparar os dados do ciclo de vida de desenvolvimento de software no GitHub. Você encontra atributos recomendados, atividades essenciais para acompanhar e instruções práticas para extrair os dados. Use este material para criar um Event Log preciso e analisar e otimizar seus processos com eficiência.
  • Atributos recomendados para coleta
  • Principais atividades para acompanhar
  • Orientações para extração
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos do ciclo de vida de desenvolvimento de software

Estes são os campos de dados recomendados para incluir no Event Log e realizar uma análise abrangente e descobrir os processos do ciclo de vida de desenvolvimento de software.
3 Obrigatório 5 Recomendado 15 Opcional
Nome Descrição
Atividade
ActivityName
Nome de um evento ou tarefa específica que ocorreu durante o ciclo de vida do desenvolvimento de software.
Descrição

O nome da atividade descreve uma etapa do processo de desenvolvimento, como 'Issue criada', 'Código enviado à PR', 'Pull request aprovada' ou 'Implantação concluída com sucesso'. Esses eventos formam a sequência de etapas que compõem o processo de ponta a ponta de um item de desenvolvimento.

Este atributo é fundamental para o Process Mining, pois é usado para construir o mapa do processo. Analisar a sequência, a frequência e a duração dessas atividades revela o fluxo real do processo, identifica caminhos comuns, destaca desvios e localiza gargalos.

Por que isso importa

Este atributo é a base do mapa do processo e permite visualizar e analisar a sequência de eventos no ciclo de vida do desenvolvimento.

Onde encontrar

Derivado do campo 'action' dos conteúdos de eventos de webhook, por exemplo, 'opened' ou 'closed' para uma issue, ou do próprio tipo de evento, como 'PushEvent' ou 'PullRequestReviewEvent'.

Exemplos
Issue criadaPull request abertaCódigo enviado à PRRevisão solicitadaPull request integrada
Hora de início
EventTimestamp
Data e hora exatas em que uma atividade ou evento específico de desenvolvimento ocorreu.
Descrição

Este registro de data e hora marca o início de uma atividade. É essencial para ordenar os eventos cronologicamente e reconstruir o fluxo do processo de cada item de desenvolvimento. A sequência e a diferença de tempo entre esses registros são usadas para analisar a performance do processo.

Na análise, este atributo é essencial para calcular todas as métricas baseadas em tempo, incluindo tempos de ciclo, tempos de processamento e tempos de espera. Ele permite identificar atrasos entre etapas e fornece os dados necessários para a análise de gargalos e os Dashboards de monitoramento de performance.

Por que isso importa

Este registro de data e hora é essencial para ordenar corretamente os eventos e calcular métricas de performance, como tempos de ciclo e duração dos gargalos.

Onde encontrar

Geralmente encontrado nos campos 'created_at' ou 'updated_at' dos conteúdos JSON das APIs e dos webhooks do GitHub para objetos como issues, pull requests e commits.

Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Item de desenvolvimento
DevelopmentItemId
Identificador exclusivo de uma unidade de trabalho de desenvolvimento, como uma funcionalidade, correção de bug ou tarefa. Ele funciona como o identificador principal do caso.
Descrição

O ID do item de desenvolvimento acompanha um item de trabalho desde a criação até a implantação final. Ele reúne todas as atividades relacionadas, como criação de branches, commits, pull requests, revisões e implantações, em uma única instância de processo coesa.

Na análise, esse ID é usado para calcular o tempo de ciclo de ponta a ponta de uma tarefa de desenvolvimento. Ele permite reconstruir todo o percurso de uma funcionalidade ou correção de bug e analisar em detalhes gargalos, ciclos de retrabalho e variações do processo em cada item de trabalho.

Por que isso importa

É a chave essencial para o Process Mining, pois conecta todos os eventos de desenvolvimento relacionados em um único caso e permite visualizar e analisar com precisão todo o ciclo de vida do desenvolvimento de software.

Onde encontrar

Em geral, é o número da issue ou da pull request no GitHub. Ele pode ser extraído do campo 'number' no conteúdo de eventos de webhook ou nas respostas da API relacionados a issues ou pull requests.

Exemplos
101PR-2345TASK-812
Hora de término
EndTimestamp
Data e hora exatas em que uma atividade ou evento específico de desenvolvimento foi concluído.
Descrição

O registro de data e hora de término marca a conclusão de uma atividade. Embora muitos eventos no GitHub sejam instantâneos, como 'Issue criada', algumas atividades têm duração mensurável, como a execução de uma verificação de CI. A diferença entre a hora de término e a hora de início corresponde ao tempo de processamento da atividade.

Este atributo é usado para calcular a métrica 'ProcessingTime', essencial para entender quanto tempo de trabalho ativo é dedicado a tarefas como revisões de código ou verificações automatizadas. Analisar os tempos de processamento ajuda a identificar atividades ineficientes que consomem tempo demais.

Por que isso importa

Permite calcular com precisão os tempos de processamento das atividades e distinguir o tempo de trabalho ativo do tempo de espera.

Onde encontrar

Pode ser encontrado como 'completed_at' nos objetos de execução de verificação ou derivado do registro de data e hora de um evento posterior que conclua logicamente a atividade.

Exemplos
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Prioridade
Priority
Nível de prioridade atribuído a um item de desenvolvimento, como 'Alta', 'Média' ou 'Baixa'.
Descrição

A prioridade indica a urgência ou a importância de negócio de um item de trabalho. No GitHub, não há um campo nativo para prioridade; ela costuma ser gerenciada por meio de labels (por exemplo, 'P1-High', 'P2-Medium'). Para extrair essa informação de forma confiável, é preciso adotar um padrão consistente de labels.

Esse atributo é essencial para a 'Análise do fluxo por prioridade'. Ele permite que analistas verifiquem se os itens de alta prioridade são realmente processados mais rápido que os de baixa prioridade e meçam a variação do tempo de ciclo conforme a prioridade. Também ajuda a avaliar a eficácia do processo de priorização.

Por que isso importa

Permite analisar se os itens de alta prioridade são processados mais rápido que os de prioridade mais baixa, validando a eficácia da estratégia de priorização.

Onde encontrar

Derivado das labels do GitHub aplicadas a issues ou pull requests. Requer uma convenção padronizada para as labels de prioridade.

Exemplos
AltaMédiaBaixaCrítico
Repositório
RepositoryName
Nome do repositório de código em que a atividade de desenvolvimento ocorre.
Descrição

O repositório funciona como identificador de um projeto ou produto e contém todo o código, as issues e as pull requests de um aplicativo ou componente específico. Ele permite segmentar e comparar os processos de desenvolvimento de diferentes produtos ou equipes.

Na análise, este atributo permite filtrar e comparar a performance dos processos entre projetos. Ele ajuda a responder perguntas como 'Qual projeto tem o maior tempo de ciclo?' ou 'Como o processo de correção de bugs do Projeto A se compara ao do Projeto B?'. É essencial para o Dashboard 'Throughput por projeto e tipo'.

Por que isso importa

Permite segmentar e comparar processos de desenvolvimento entre projetos, produtos ou equipes, possibilitando análises mais direcionadas.

Onde encontrar

Disponível no objeto 'repository' em quase todos os conteúdos de webhooks e APIs do GitHub. O campo específico costuma ser 'repository.full_name' ou 'repository.name'.

Exemplos
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Tipo de item de desenvolvimento
DevelopmentItemType
Classificação do item de trabalho de desenvolvimento, como funcionalidade, bug, tarefa ou épico.
Descrição

Este atributo categoriza a natureza do trabalho realizado. Em geral, essas informações são gerenciadas por meio de labels ou modelos específicos de issue no GitHub. Entender o tipo de trabalho é essencial para definir expectativas de performance adequadas, já que o tempo de ciclo esperado para corrigir um bug pode ser bem menor do que para desenvolver uma nova funcionalidade.

Este atributo permite comparar diferentes tipos de trabalho. Ele ajuda a analisar se os bugs são corrigidos mais rapidamente do que as novas funcionalidades e a entender como os recursos são distribuídos entre a dívida técnica e o novo desenvolvimento. É uma dimensão importante do Dashboard 'Throughput por projeto e tipo'.

Por que isso importa

Categoriza os itens de trabalho e permite comparar a performance e analisar como diferentes tipos de trabalho, como bugs e funcionalidades, avançam pelo processo.

Onde encontrar

Em geral, derivado das labels aplicadas a issues ou pull requests no GitHub. Requer uma convenção consistente para as labels, como 'type:bug' e 'type:feature'.

Exemplos
BugFuncionalidadeTarefaDívida técnica
Usuário atribuído
Assignee
Usuário ou desenvolvedor responsável pelo item de desenvolvimento ou por uma tarefa específica, como revisar uma pull request.
Descrição

Este atributo identifica a pessoa responsável pelo trabalho em determinada etapa. Pode ser a pessoa atribuída a uma issue, o autor de uma pull request ou o revisor solicitado para uma revisão de código. Acompanhar a pessoa responsável é essencial para entender a alocação de recursos e a carga de trabalho.

Na análise, este atributo é usado para monitorar a carga de trabalho dos desenvolvedores, identificar gargalos de recursos e avaliar a eficiência das transferências entre integrantes da equipe. Os Dashboards podem ser filtrados por pessoa responsável para avaliar a performance individual ou da equipe e garantir uma distribuição equilibrada do trabalho.

Por que isso importa

Essencial para analisar a carga de trabalho dos desenvolvedores, a performance da equipe e a eficiência das transferências entre seus integrantes.

Onde encontrar

Disponível no objeto 'assignee' ou 'user' dos conteúdos JSON de issues, pull requests e eventos de revisão da API do GitHub.

Exemplos
john.doejane.smithdev-team-lead
Ambiente de implantação
DeploymentEnvironment
Ambiente de destino de uma implantação, como 'Staging' ou 'Production'.
Descrição

Esse atributo especifica onde o código está sendo implantado. Acompanhar implantações em diferentes ambientes é essencial para entender todo o ciclo de vida, do desenvolvimento à publicação em produção.

Com esse atributo, é possível analisar o subprocesso de implantação. Ele pode ser usado para medir quanto tempo o código leva para passar de staging para produção e acompanhar a taxa de sucesso das implantações em diferentes ambientes. É essencial para saber quando um item de desenvolvimento está realmente concluído e disponível para os usuários.

Por que isso importa

Diferencia as publicações em pré-produção das publicações em produção, o que é fundamental para medir o verdadeiro tempo de lançamento no mercado e analisar os padrões de implantação.

Onde encontrar

Essas informações são obtidas pela API GitHub Deployments, geralmente acionada por pipelines de CI/CD ou outras automações.

Exemplos
developmentstagingproduction
Autor
Author
A pessoa que criou a issue, o pull request ou o commit.
Descrição

O autor é quem criou um artefato específico no processo de desenvolvimento. Por exemplo, o autor de uma issue é a pessoa que relatou o bug ou solicitou o recurso. Já o autor de um pull request é o desenvolvedor que escreveu o código.

Na análise, o autor ajuda a entender de onde vem o trabalho. Analisar os autores de relatos de bugs, por exemplo, pode revelar padrões relacionados a equipes ou recursos específicos. Também é possível cruzar esse dado com o responsável para analisar padrões de handoff.

Por que isso importa

Identifica quem iniciou um item de trabalho ou uma alteração de código, o que pode ajudar a analisar as origens de retrabalho, relatos de bugs ou solicitações de recursos.

Onde encontrar

Disponível no objeto 'user' dentro do objeto principal das respostas da API para issues, pull requests e commits. O campo geralmente é 'user.login'.

Exemplos
sara.jonesmike.leeautomation-bot
É retrabalho
IsRework
Indicador booleano que assume o valor verdadeiro quando uma atividade representa um retorno a uma etapa anterior do processo.
Descrição

Esse indicador recebe o valor verdadeiro quando um item de desenvolvimento retrocede no processo, por exemplo, quando um pull request recebe uma revisão com 'Alterações solicitadas' ou quando uma issue é reaberta após ser encerrada. O valor é derivado da análise da sequência de atividades.

Esse atributo é essencial para quantificar desperdícios e ineficiências. Ele dá suporte direto ao Dashboard 'Ciclos de retrabalho e regressão' e ao KPI 'Taxa de retrabalho'. Ao filtrar por 'IsRework = true', os analistas podem isolar e investigar as causas do retrabalho.

Por que isso importa

Sinaliza explicitamente as atividades que representam retrabalho, facilitando a quantificação, a visualização e a análise das causas de ineficiência no processo.

Onde encontrar

Esse atributo é derivado. A lógica consiste em definir um fluxo de processo padrão e sinalizar qualquer atividade que se desvie dele ao retornar a uma etapa lógica anterior.

Exemplos
truefalse
Estado da revisão
ReviewState
Resultado da revisão de código de um pull request, como 'Aprovado' ou 'Alterações solicitadas'.
Descrição

Esse atributo registra a decisão do revisor. Entre os estados mais comuns estão 'APPROVED', que indica que o código está pronto para merge, e 'CHANGES_REQUESTED', que indica a necessidade de retrabalho. Outros estados possíveis são 'COMMENTED' e 'PENDING'.

Esse atributo é fundamental para analisar retrabalho e qualidade. Uma frequência alta de eventos 'CHANGES_REQUESTED' pode indicar problemas na qualidade inicial do código ou requisitos pouco claros. Ele contribui diretamente para o Dashboard 'Ciclos de retrabalho e regressão', identificando quando um item de desenvolvimento volta para ser alterado.

Por que isso importa

Indica diretamente os ciclos de retrabalho e os pontos de controle de qualidade no processo de revisão de código, ajudando a localizar as fontes de ineficiência e os problemas de qualidade.

Onde encontrar

Disponível no campo 'state' de um objeto de revisão de pull request na API do GitHub. Por exemplo, no payload de um 'PullRequestReviewEvent'.

Exemplos
APPROVEDCHANGES_REQUESTEDCOMMENTED
Estado do item
State
Status atual de uma issue ou pull request, como 'open', 'closed' ou 'merged'.
Descrição

Este atributo indica o status geral de um item de desenvolvimento. Para issues, os estados mais comuns são 'open' e 'closed'. Para pull requests, os estados incluem 'open', 'closed' e 'merged'. Isso oferece uma visão do andamento do item.

Na análise, o estado é usado para identificar o trabalho em andamento e o trabalho concluído. É essencial para Dashboards como 'Andamento do desenvolvimento ativo', que monitoram o trabalho em curso. Também é usado para definir o fim de um processo. Por exemplo, o estado 'merged' ou 'closed' pode indicar a conclusão de um caso.

Por que isso importa

Indica claramente se um item de trabalho está em andamento ou concluído, algo fundamental para analisar o ciclo de vida e monitorar o trabalho ativo.

Onde encontrar

Disponível diretamente no campo 'state' dos conteúdos JSON de issues e pull requests da API do GitHub.

Exemplos
openclosedmerged
Hash do commit
CommitHash
Identificador único (SHA) de um commit de código específico.
Descrição

O hash de um commit é um hash SHA-1 de 40 caracteres que identifica exclusivamente um commit no Git. Ele funciona como um ID permanente de uma versão específica do código. Os commits são as unidades atômicas de alteração no processo de desenvolvimento.

Embora seja bastante granular, o hash do commit oferece o nível máximo de rastreabilidade. Ele permite vincular um evento do processo diretamente à alteração exata de código realizada. Isso pode ser muito útil em auditorias, na conformidade ou na análise detalhada da causa raiz de incidentes em produção.

Por que isso importa

Faz a ligação mais granular entre uma etapa do processo e a alteração exata de código, permitindo rastreabilidade completa para auditorias e depuração.

Onde encontrar

Disponível nos payloads de eventos de push ('head_commit.id') ou pela API Commits para um pull request ou uma branch.

Exemplos
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Labels
Labels
Lista de tags ou labels aplicadas a uma issue ou a um pull request para categorização.
Descrição

No GitHub, as labels são uma forma flexível de adicionar metadados a issues e pull requests. Elas podem indicar prioridade, tipo de trabalho, componentes, equipes ou status. A lista completa de labels oferece um contexto rico e não estruturado.

Atributos específicos, como prioridade e tipo, podem ser derivados das labels, mas manter a lista completa também é útil para análises pontuais e para descobrir outros padrões do processo. Isso permite filtrar e segmentar casos com flexibilidade, usando qualquer combinação de labels.

Por que isso importa

Oferece uma fonte flexível e rica de metadados para categorizar itens de trabalho, permitindo análises dimensionais detalhadas e variadas.

Onde encontrar

Disponível no array 'labels' do payload JSON de issues e pull requests da API do GitHub. Cada item do array é um objeto com um campo 'name'.

Exemplos
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Nome da branch
BranchName
Nome da branch do Git em que foram feitas as alterações de código do item de desenvolvimento.
Descrição

Uma branch é uma linha independente de desenvolvimento, criada para trabalhar em um novo recurso ou corrigir um bug sem afetar a base de código principal. O nome da branch costuma trazer informações úteis, como o número da issue ou uma breve descrição do trabalho.

Analisar os nomes das branches ajuda a entender as estratégias de branching e a verificar se as convenções de desenvolvimento estão sendo seguidas. Também ajuda a vincular commits de código a um item de desenvolvimento, oferecendo uma visão completa das atividades de codificação.

Por que isso importa

Dá contexto sobre a linha específica de desenvolvimento e ajuda a definir e analisar estratégias de branching e convenções de nomenclatura.

Onde encontrar

Disponível no campo 'ref' dos eventos de push ou nos objetos 'head' e 'base' da resposta da API de um pull request.

Exemplos
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Número do pull request
PullRequestNumber
Identificador único de um pull request associado ao item de desenvolvimento.
Descrição

Um pull request (PR) é uma proposta para incorporar um conjunto de alterações de código a uma branch específica. O número do pull request vincula atividades de desenvolvimento, como envios de código e revisões, ao item de desenvolvimento ou à issue principal.

Esse ID é essencial para acompanhar a integração do código e o subprocesso de revisão dentro do ciclo de vida mais amplo do desenvolvimento. Ele permite analisar em detalhes o processo de revisão de código, incluindo os tempos de revisão, os ciclos de retrabalho identificados durante a revisão e as taxas de merge. Também conecta a etapa de planejamento (issue) à etapa de implementação (PR).

Por que isso importa

Vincula issues às alterações de código e aos processos de revisão correspondentes, permitindo analisar em detalhes o ciclo de revisão de código e seu impacto no tempo total de entrega.

Onde encontrar

Disponível no campo 'number' do objeto 'pull_request' em muitas respostas da API do GitHub ou como identificador principal na API de Pull Requests.

Exemplos
12345678910
Revisor
Reviewer
A pessoa solicitada para fazer a revisão de código de um pull request.
Descrição

Um revisor é um desenvolvedor ou membro da equipe designado para inspecionar as alterações de código em um pull request, verificando a qualidade, a correção e a conformidade com os padrões. Um pull request pode ter vários revisores.

Esse atributo é essencial para analisar o processo de revisão de código. Ele ajuda a identificar gargalos relacionados a revisores específicos, entender como a carga de trabalho de revisão está distribuída e medir o tempo de resposta às solicitações. Também é um componente importante para calcular o KPI 'Tempo médio do ciclo de revisão de código'.

Por que isso importa

Identifica as pessoas envolvidas no processo de garantia da qualidade, permitindo analisar a carga de trabalho das revisões, os atrasos e a eficiência geral das revisões de código.

Onde encontrar

Disponível no array 'requested_reviewers' ou no objeto 'user' de um evento de revisão de pull request na API do GitHub.

Exemplos
alex.chenmaria.garciasenior-dev-team
Sistema de origem
SourceSystem
Sistema do qual os dados do processo de desenvolvimento foram extraídos.
Descrição

Este atributo identifica a origem dos dados do evento. Neste processo, o valor seria sempre 'GitHub'. Em um ambiente mais complexo, no qual as atividades de desenvolvimento passam por vários sistemas, como Jira para planejamento, GitHub para código e Jenkins para implantação, este campo identifica a origem de cada evento.

Na análise, ele ajuda a rastrear os dados até a origem para validação e solução de problemas. Também permite analisar processos que passam por diferentes plataformas, fornecendo contexto claro para cada atividade.

Por que isso importa

Identifica a origem dos dados, algo essencial para validá-los e analisar processos que podem passar por vários sistemas integrados.

Onde encontrar

Em geral, é um valor estático adicionado durante o processo de extração, transformação e carregamento de dados (ETL) para identificar a origem dos registros.

Exemplos
GitHubGitHub Enterprise
Status da verificação de CI
CiCheckStatus
Status de uma verificação automatizada de Integração Contínua (CI), como 'aprovada' ou 'reprovada'.
Descrição

Esse atributo mostra o resultado de builds, testes e verificações automatizados executados nas alterações de código de um pull request. As verificações de CI são um ponto de controle de qualidade fundamental nos fluxos de trabalho de desenvolvimento atuais.

Analisar esse atributo ajuda a entender a eficácia dos testes automatizados. Uma taxa alta de falhas pode indicar problemas de estabilidade do código, da suíte de testes ou do ambiente de desenvolvimento. O atributo dá suporte às atividades 'Verificações de CI aprovadas' e 'Verificações de CI reprovadas' e ajuda a analisar atrasos causados por builds com falha.

Por que isso importa

Indica se os pontos de controle de qualidade automatizados foram aprovados ou reprovados, oferecendo insights sobre a qualidade do código e a eficácia do pipeline de CI.

Onde encontrar

Obtido no campo 'state' ou 'conclusion' dos objetos de execução de verificação ou de status, por meio da API GitHub Checks ou Statuses.

Exemplos
successfailurependingerror
Tempo de ciclo de desenvolvimento
DevelopmentCycleTime
Tempo total entre a criação de um item de desenvolvimento e sua implantação final ou seu encerramento.
Descrição

Essa métrica é calculada por caso, como a diferença entre o primeiro evento (por exemplo, 'Issue criada') e o evento final (por exemplo, 'Implantação aprovada' ou 'Issue encerrada') de um único item de desenvolvimento.

É um dos KPIs mais importantes para medir a eficiência geral do processo de desenvolvimento. A métrica dá suporte direto ao Dashboard 'Tempo total do ciclo de desenvolvimento' e ao KPI 'Tempo médio do ciclo de desenvolvimento'. Reduzi-la costuma ser um dos principais objetivos das iniciativas de melhoria de processos.

Por que isso importa

Representa o tempo total de lançamento no mercado de um item de desenvolvimento e é um KPI fundamental para medir a velocidade e a eficiência gerais do processo.

Onde encontrar

Calculado por caso, subtraindo o horário da primeira atividade do horário da última atividade.

Exemplos
P5DT6H30MP14DT12HP1DT2H
Tempo de espera no handoff
HandoffWaitingTime
Tempo ocioso calculado que um item de desenvolvimento passa aguardando entre atividades realizadas por pessoas diferentes.
Descrição

Essa métrica mede o intervalo entre a conclusão de uma atividade e o início da seguinte, mas somente quando muda a pessoa responsável. Por exemplo, o tempo entre um evento 'Revisão solicitada' e um evento 'Alterações solicitadas na revisão' realizado por outra pessoa.

Essa métrica é fundamental para identificar falhas de comunicação e problemas de coordenação. Ela dá suporte ao Dashboard 'Eficiência dos handoffs críticos' e ao KPI 'Tempo médio de espera no handoff'. Tempos de espera altos nos pontos de handoff costumam indicar limitações de recursos ou processos de notificação ineficientes.

Por que isso importa

Identifica atrasos causados por falhas de coordenação ou indisponibilidade de recursos durante handoffs entre equipes ou funções diferentes, que costumam ser grandes fontes de ineficiência.

Onde encontrar

Calculado pela identificação de atividades sequenciais em que o atributo 'Assignee' ou 'User' muda e pela medição do intervalo entre elas.

Exemplos
PT1H15MP2DT4HPT25M
Última atualização dos dados
LastDataUpdate
Registro de data e hora que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem.
Descrição

Este atributo registra a data e a hora da extração ou atualização mais recente dos dados. Ele fornece metadados sobre a atualidade dos dados analisados. É diferente do registro de data e hora do evento, que indica quando o evento de negócio ocorreu.

Na análise, este campo é essencial para entender a atualidade da visão do processo. Ele ajuda você a saber se está consultando dados em tempo real ou um instantâneo de um momento específico, algo importante para Dashboards operacionais e monitoramento.

Por que isso importa

Indica a atualidade dos dados, essencial para garantir que as análises e os Dashboards usem informações atualizadas.

Onde encontrar

Este registro de data e hora é gerado e adicionado durante o processo de extração, transformação e carregamento de dados (ETL).

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Obrigatório Recomendado Opcional

Atividades do ciclo de vida de desenvolvimento de software

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir os processos com precisão e identificar gargalos.
6 Recomendado 7 Opcional
Atividade Descrição
Issue criada
Marca o início do ciclo de vida de um item de desenvolvimento, formalizando a criação de uma tarefa, um bug ou uma solicitação de funcionalidade. Esse evento é registrado explicitamente quando alguém cria uma nova issue em um repositório do GitHub.
Por que isso importa

Esta é a principal atividade de início do processo, essencial para medir o tempo total do ciclo de desenvolvimento e entender as fontes iniciais de trabalho.

Onde encontrar

Este é um evento explícito capturado no fluxo de eventos da API do GitHub Issues. O tipo de evento costuma ser 'opened' para determinado número de issue.

Coleta

Monitore o evento 'opened' de uma issue por meio de webhooks ou consultas periódicas à API.

Tipo de evento explicit
Issue encerrada
O item de desenvolvimento é considerado concluído e a issue correspondente é encerrada formalmente. Isso pode acontecer automaticamente quando uma pull request vinculada é integrada ou manualmente por alguém da equipe.
Por que isso importa

Esta atividade marca o fim definitivo do processo para um item de desenvolvimento. É essencial para calcular os tempos de ciclo de ponta a ponta.

Onde encontrar

Este é um evento explícito capturado no fluxo de eventos da API do GitHub Issues. O tipo de evento é 'closed'.

Coleta

Monitore o evento 'closed' de uma issue por meio de webhooks ou consultas periódicas à API.

Tipo de evento explicit
Pull request aberta
Indica que um primeiro conjunto de código está pronto para revisão e integração. Um desenvolvedor cria uma pull request (PR) para propor alterações da branch de funcionalidade para uma branch principal. Este é um evento explícito no GitHub.
Por que isso importa

Este é um marco importante: encerra a fase inicial de desenvolvimento e dá início ao fluxo de revisão e integração. É essencial analisar separadamente os tempos dos ciclos de desenvolvimento e de revisão.

Onde encontrar

Capturado no fluxo de eventos da API do GitHub Pull Request ou por webhooks. A ação do evento é 'opened'.

Coleta

Monitore a ação 'opened' de uma pull request por meio de webhooks ou consultas periódicas à API.

Tipo de evento explicit
Pull request aprovada
Um revisor aprovou formalmente as alterações de uma pull request, indicando que elas atendem aos padrões de qualidade e funcionalidade. O evento é registrado quando o revisor envia a avaliação com o status 'approve'.
Por que isso importa

Esta é uma etapa essencial de controle de qualidade e um marco importante antes da integração. O tempo entre a criação da PR e a aprovação é um KPI fundamental para avaliar a eficiência do processo de revisão.

Onde encontrar

Capturado na API do GitHub Pull Request ou por webhooks quando uma revisão é enviada com o estado 'APPROVED'.

Coleta

Filtre os eventos de envio de revisão de pull requests pelo estado 'APPROVED'.

Tipo de evento explicit
Pull request integrada
As alterações aprovadas da pull request são integradas oficialmente à branch de destino, como main ou develop. Esta é a ação final explícita de uma pull request, que incorpora o novo código.
Por que isso importa

Este é um marco importante que representa a conclusão do desenvolvimento e da revisão. Para muitas equipes, é a última etapa antes da implantação automatizada.

Onde encontrar

Capturado no fluxo de eventos da API do GitHub Pull Request ou por webhooks. A ação do evento é 'closed' e o atributo 'merged' do conteúdo da pull request é true.

Coleta

Monitore a ação 'closed' de uma pull request e verifique se a flag 'merged' está como true.

Tipo de evento explicit
Verificações de CI aprovadas
Representa a conclusão bem-sucedida de verificações automatizadas, como compilações, testes unitários ou análise estática, executadas no código de uma pull request. Este evento é inferido com base no status das verificações informado por sistemas como o GitHub Actions.
Por que isso importa

Esta etapa automatizada de controle de qualidade é essencial para garantir a estabilidade do código. Falhas ou execuções demoradas podem se tornar gargalos importantes no fluxo de entrega.

Onde encontrar

Inferido pela API do GitHub Checks ou pela API Statuses. Uma execução de verificação ou atualização de status informa 'success' ou 'completed' com a conclusão 'success'.

Coleta

Monitore a API Checks para identificar a conclusão 'success' nos conjuntos de verificações relevantes.

Tipo de evento inferred
Alterações solicitadas na revisão
Um revisor concluiu a revisão do código e determinou que são necessárias alterações antes da aprovação da pull request. O revisor envia formalmente a avaliação com o status 'request_changes'.
Por que isso importa

Este evento sinaliza explicitamente um ciclo de retrabalho. Analisar sua frequência ajuda a identificar problemas de qualidade, requisitos pouco claros ou necessidades de treinamento dos desenvolvedores.

Onde encontrar

Capturado na API do GitHub Pull Request ou por webhooks quando uma revisão é enviada com o estado 'CHANGES_REQUESTED'.

Coleta

Filtre os eventos de envio de revisão de pull requests pelo estado 'CHANGES_REQUESTED'.

Tipo de evento explicit
Branch criada
Representa o início do trabalho ativo de desenvolvimento de uma issue, quando um desenvolvedor cria uma nova branch a partir da base de código principal. Este evento explícito é registrado quando uma nova branch é enviada ao repositório, muitas vezes com o número da issue no nome.
Por que isso importa

Indica a transição do planejamento para a programação ativa. Medir o tempo entre a criação da issue e este evento ajuda a analisar o tempo até um desenvolvedor começar a trabalhar e os atrasos iniciais no backlog.

Onde encontrar

Capturado pela API Git do GitHub ou por webhooks que monitoram eventos 'create' do tipo 'branch'. Muitas vezes, é necessário associar o nome da branch a uma issue usando convenções de nomenclatura, como 'feature/issue-123'.

Coleta

Analise os eventos de webhook 'create' de novas branches e associe-os a uma issue.

Tipo de evento explicit
Código enviado à PR
Representa uma atualização do código enviado para revisão, seja como parte da PR inicial ou em resposta ao feedback da revisão. Este evento é registrado sempre que um novo commit é enviado à branch associada a uma pull request aberta.
Por que isso importa

Acompanhar esses eventos é essencial para identificar ciclos de retrabalho. Vários envios após uma revisão indicam que foram necessárias alterações, afetando o tempo total do ciclo.

Onde encontrar

Este é um evento explícito na linha do tempo da pull request, muitas vezes identificado como a adição de um commit. Ele pode ser capturado pelo webhook 'push' ou pelo monitoramento dos commits associados a uma PR.

Coleta

Monitore eventos 'push' em uma branch associada a uma pull request aberta.

Tipo de evento explicit
Implantação concluída com sucesso
As alterações de código foram implantadas com sucesso em um ambiente específico, como homologação ou produção. Em geral, este evento é capturado pela API do GitHub Deployments, muitas vezes acionada por uma GitHub Action após a integração.
Por que isso importa

Marca a passagem do código do repositório para um ambiente ativo. Acompanhar este evento é essencial para medir o tempo total desde a ideia até a produção.

Onde encontrar

Capturado pela API Deployments. Um serviço externo ou uma GitHub Action cria uma implantação e, em seguida, atualiza seu status para 'success'.

Coleta

Monitore eventos de status da implantação por meio de webhooks para identificar o estado 'success'.

Tipo de evento inferred
Issue reaberta
Uma issue encerrada anteriormente é reativada, geralmente porque a correção foi insuficiente ou uma regressão foi identificada. Este evento explícito reinicia o ciclo de vida do item de desenvolvimento.
Por que isso importa

Este evento sinaliza um ciclo de retrabalho significativo e pode indicar um defeito que chegou à produção ou uma correção incompleta. Acompanhar sua frequência é uma medida importante da qualidade geral do software.

Onde encontrar

Este é um evento explícito capturado no fluxo de eventos da API do GitHub Issues. O tipo de evento é 'reopened'.

Coleta

Monitore o evento 'reopened' de uma issue por meio de webhooks ou consultas periódicas à API.

Tipo de evento explicit
Revisão solicitada
O autor de uma pull request solicita formalmente que pessoas ou equipes específicas revisem o código. Esta ação explícita na interface ou na API do GitHub envia notificações aos revisores solicitados.
Por que isso importa

Esta atividade marca o início oficial da transferência para o processo de revisão de código. O tempo entre este evento e o envio de uma revisão ajuda a medir a agilidade dos revisores e a identificar possíveis gargalos.

Onde encontrar

Capturado no fluxo de eventos da API do GitHub Pull Request ou por webhooks. A ação do evento é 'review_requested'.

Coleta

Monitore a ação 'review_requested' de uma pull request.

Tipo de evento explicit
Verificações de CI reprovadas
Representa a falha de uma verificação automatizada, como um erro de compilação ou um teste unitário reprovado, executada no código de uma pull request. O evento é inferido com base em um status de falha informado por um sistema como o GitHub Actions.
Por que isso importa

Esta atividade destaca problemas técnicos de qualidade que exigem a intervenção de um desenvolvedor e geram um ciclo de retrabalho. Analisar a frequência das falhas pode orientar melhorias nos testes locais ou na qualidade do código.

Onde encontrar

Inferido pela API do GitHub Checks ou pela API Statuses. Uma execução de verificação ou atualização de status informa 'failure' ou 'completed' com a conclusão 'failure'.

Coleta

Monitore a API Checks para identificar a conclusão 'failure' nos conjuntos de verificações relevantes.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do GitHub

Pronto para começar?

Use este Template para preparar seus dados e começar a otimizar o ciclo de vida de desenvolvimento de software. Identifique ineficiências e acelere os lançamentos, com menos atritos.

Aprimore seu SDLC: identifique ineficiências na hora

Reduza o tempo de ciclo em 30% e simplifique seu processo de desenvolvimento no GitHub.

Começar o teste grátis

Não é necessário informar cartão de crédito. A configuração leva poucos minutos.