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 coleta
- Principais atividades para acompanhar
- Orientações para extração
Atributos do ciclo de vida de desenvolvimento de software
| 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
|
|||
Atividades do ciclo de vida de desenvolvimento de software
| 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
|
|||
Guias de extração
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.
Não é necessário informar cartão de crédito. A configuração leva poucos minutos.