Seu Template de Dados para o Ciclo de Vida de Software
Seu Template de Dados para o Ciclo de Vida de Software
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientação para Extração
Atributos do Ciclo de Vida de Desenvolvimento
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome de um evento ou tarefa específica que ocorreu no ciclo de vida de desenvolvimento. | ||
|
Descrição
O Nome da Atividade descreve uma etapa única no processo, como 'Issue Criada' ou 'Deploy com Sucesso'. Esses eventos formam a sequência do processo de ponta a ponta. Este atributo é vital para o Process Mining, pois constrói o mapa do processo. Analisar a sequência e duração dessas atividades revela o fluxo real, identifica caminhos comuns, destaca desvios e aponta gargalos.
Por que é importante
Este atributo forma a base do mapa do processo, permitindo visualizar e analisar a sequência de eventos no ciclo de vida.
Onde obter
Derivado do campo 'action' dos payloads de eventos de webhook (ex: 'opened', 'closed' para uma issue) ou do próprio tipo de evento (ex: 'PushEvent', 'PullRequestReviewEvent').
Exemplos
Problema CriadoPull Request AbertoCódigo Enviado para PRRevisão SolicitadaPull Request Mesclado
|
|||
|
Hora de Início
EventTimestamp
|
A data e hora exatas em que uma atividade ou evento específico ocorreu. | ||
|
Descrição
Timestamp que marca o início de uma atividade. Vital para ordenar eventos cronologicamente e reconstruir o fluxo. Essencial para calcular todas as métricas temporais, como cycle times e esperas. Permite identificar atrasos entre etapas e fornece dados para análise de gargalos e dashboards de monitoramento.
Por que é importante
Este timestamp é crítico para ordenar os eventos corretamente e calcular métricas de desempenho, como cycle times e duração de gargalos.
Onde obter
Geralmente encontrado nos campos 'created_at' ou 'updated_at' nos payloads JSON das APIs do GitHub.
Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Item de Desenvolvimento
DevelopmentItemId
|
O identificador único de uma unidade de trabalho (feature, bug, tarefa). Serve como o identificador principal do caso (Case ID). | ||
|
Descrição
O ID do Item de Desenvolvimento rastreia um item da criação ao deploy final. Ele vincula todas as atividades, como commits e revisões, em uma única instância de processo. Na análise, este ID serve para calcular o cycle time total. Ele permite reconstruir a jornada completa de uma funcionalidade, possibilitando analisar gargalos e loops de retrabalho detalhadamente.
Por que é importante
É a chave essencial para o Process Mining, conectando todos os eventos de desenvolvimento relacionados em um único caso para visualizar e analisar com precisão o ciclo de vida de desenvolvimento de software de ponta a ponta.
Onde obter
Normalmente é o Número da Issue ou do Pull Request. Extraído do campo 'number' nas respostas da API ou payloads de webhook.
Exemplos
101PR-2345TASK-812
|
|||
|
End Time
EndTimestamp
|
A data e hora exatas em que uma atividade ou evento específico foi concluído. | ||
|
Descrição
O timestamp final marca a conclusão de uma atividade. Enquanto alguns eventos são instantâneos, outros têm duração mensurável (ex: execução de CI). A diferença entre início e fim gera o tempo de processamento. Este atributo calcula a métrica de 'Tempo de Processamento', vital para entender o esforço ativo em tarefas como code reviews. Analisá-lo ajuda a identificar atividades ineficientes que consomem tempo excessivo.
Por que é importante
Permite o cálculo preciso dos tempos de processamento das atividades, ajudando a distinguir entre o tempo de trabalho ativo e o tempo de espera ocioso.
Onde obter
Pode ser encontrado como 'completed_at' em objetos de execução de verificação ou derivado do timestamp de um evento subsequente logicamente conclusivo.
Exemplos
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Prioridade
Priority
|
O nível de prioridade atribuído a um item, como 'Alta', 'Média' ou 'Baixa'. | ||
|
Descrição
A Prioridade indica a urgência ou importância de negócio de um item de trabalho. No GitHub, a prioridade não é um campo nativo e costuma ser gerenciada por etiquetas (ex: 'P1-Alta', 'P2-Média'). É necessário um esquema consistente de etiquetas para extrair essa informação com precisão. Este atributo é essencial para a 'Análise de Fluxo Baseada em Prioridade'. Ele permite verificar se itens de alta prioridade são realmente processados mais rápido e medir a variação do cycle time conforme a prioridade, ajudando a avaliar a eficácia do processo de priorização.
Por que é importante
Permite analisar se itens de alta prioridade são processados mais rapidamente do que os de baixa prioridade, validando a eficácia da estratégia de priorização.
Onde obter
Derivado das etiquetas do GitHub aplicadas a issues ou pull requests. Requer uma convenção padronizada para as etiquetas de prioridade.
Exemplos
AltoMédioBaixoCrítico
|
|||
|
Repositório
RepositoryName
|
O nome do repositório onde a atividade de desenvolvimento está ocorrendo. | ||
|
Descrição
O repositório identifica o projeto ou produto. Ele permite segmentar e comparar processos entre diferentes times. Na análise, este atributo permite filtrar o desempenho por projeto. Ajuda a responder quais projetos têm maior cycle time ou como processos de correção de bug variam entre times, sendo essencial para o dashboard de 'Vazão (Throughput) por Projeto'.
Por que é importante
Permite a segmentação e comparação de processos de desenvolvimento entre diferentes projetos, produtos ou equipes, possibilitando uma análise mais direcionada.
Onde obter
Disponível no objeto 'repository' em quase todos os payloads de webhooks e da API do GitHub. O campo específico geralmente é 'repository.full_name' ou 'repository.name'.
Exemplos
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Tipo de Item de Desenvolvimento
DevelopmentItemType
|
A classificação do item de trabalho, como funcionalidade (feature), bug, tarefa ou épico. | ||
|
Descrição
Este atributo categoriza a natureza do trabalho (ex: bug, feature). Isso é gerido por etiquetas no GitHub. Entender o tipo de trabalho é crucial para definir expectativas de performance, já que um bug costuma ser resolvido mais rápido que uma nova funcionalidade. Ele permite comparar se correções são mais rápidas que novas features e analisar a alocação de recursos entre dívida técnica e novos desenvolvimentos.
Por que é importante
Categoriza itens de trabalho, permitindo comparações de desempenho e análise de como diferentes tipos de trabalho (ex: bugs vs. novos recursos) fluem pelo processo.
Onde obter
Geralmente derivado de etiquetas do GitHub. Requer uma convenção de nomenclatura consistente (ex: 'type:bug').
Exemplos
BugFeatureTarefaDívida Técnica
|
|||
|
Usuário Atribuído
Assignee
|
O usuário ou desenvolvedor designado para o item ou tarefa, como a revisão de um pull request. | ||
|
Descrição
Identifica o responsável pelo trabalho em cada etapa. Pode ser quem recebeu a issue, o autor do pull request ou o revisor. Rastrear o responsável é a chave para entender a carga de trabalho. Serve para monitorar o volume de tarefas por desenvolvedor e identificar gargalos de recursos ou falhas de coordenação entre membros do time.
Por que é importante
Crucial para analisar a carga de trabalho dos desenvolvedores, o desempenho da equipe e a eficiência das passagens de bastão (handoffs) entre diferentes membros do time.
Onde obter
Disponível no objeto 'assignee' ou 'user' dentro dos payloads JSON para issues, pull requests e eventos de revisão da API do GitHub.
Exemplos
john.doejane.smithdev-team-lead
|
|||
|
Ambiente de Implantação
DeploymentEnvironment
|
O ambiente de destino de um deploy, como 'Staging' ou 'Produção'. | ||
|
Descrição
Especifica para onde o código está sendo enviado. Rastrear o destino é a chave para entender o ciclo completo, do desenvolvimento ao lançamento. Permite analisar o sub-processo de deploy, medindo o tempo de promoção entre ambientes (ex: staging para produção) e identificando quando um item está realmente 'pronto' para o usuário.
Por que é importante
Distingue entre lançamentos de pré-produção e produção, o que é fundamental para medir o 'time-to-market' real e analisar padrões de implantação.
Onde obter
Esta informação é obtida via GitHub Deployments API, geralmente disparada por pipelines de CI/CD.
Exemplos
developmentstagingprodução
|
|||
|
Autor
Author
|
O usuário que criou a issue, pull request ou commit. | ||
|
Descrição
O autor é quem originou um artefato. Por exemplo, quem reportou o bug ou quem escreveu o código do pull request. Na análise, o autor ajuda a entender as fontes de demanda. Analisar autores de bugs pode revelar padrões em times específicos, e cruzar essa informação com o responsável (assignee) ajuda a analisar padrões de handoff.
Por que é importante
Identifica o criador de um item de trabalho ou alteração de código, o que pode ser útil para analisar origens de retrabalho, relatórios de bugs ou solicitações de recursos.
Onde obter
Disponível no objeto 'user' dentro do objeto principal das respostas da API para issues, pull requests e commits. O campo costuma ser 'user.login'.
Exemplos
sara.jonesmike.leeautomation-bot
|
|||
|
É Retrabalho
IsRework
|
Uma flag booleana que é verdadeira se uma atividade representar uma regressão a um estágio anterior do processo. | ||
|
Descrição
Esta flag é marcada como verdadeira quando um item volta etapas no processo (ex: um PR que recebe 'Changes Requested'). É essencial para quantificar desperdícios. Alimenta o dashboard de retrabalho e o KPI de 'Taxa de Retrabalho', permitindo investigar as causas raiz de ineficiências.
Por que é importante
Sinaliza explicitamente atividades que constituem retrabalho, facilitando a quantificação, visualização e análise das causas das ineficiências do processo.
Onde obter
Atributo derivado. A lógica envolve definir um fluxo padrão e sinalizar qualquer atividade que retroceda para uma etapa anterior.
Exemplos
verdadeirofalse
|
|||
|
Estado de Revisão
ReviewState
|
O resultado de um code review em um pull request, como 'Approved' ou 'Changes Requested'. | ||
|
Descrição
Este atributo captura a decisão do revisor. Estados comuns incluem 'APPROVED' (pronto para merge) e 'CHANGES_REQUESTED' (exige retrabalho). É vital para analisar qualidade. Uma alta frequência de pedidos de alteração pode indicar requisitos incertos ou baixa qualidade inicial do código, alimentando o dashboard de 'Loops de Retrabalho'.
Por que é importante
Indica diretamente loops de retrabalho e quality gates dentro do processo de revisão de código, ajudando a identificar fontes de ineficiência e problemas de qualidade.
Onde obter
Disponível como o campo 'state' dentro de um objeto de revisão de pull request da API do GitHub. Por exemplo, em um payload 'PullRequestReviewEvent'.
Exemplos
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Estado do Item
State
|
O status atual de uma issue ou pull request, como 'open', 'closed' ou 'merged'. | ||
|
Descrição
Indica o status macro do item (ex: 'open', 'merged'). Oferece um panorama do progresso. É usado para separar trabalho ativo de concluído. Essencial para dashboards de acompanhamento de progresso e para definir o ponto final do processo na análise.
Por que é importante
Indica claramente se um item de trabalho está em andamento ou concluído, o que é fundamental para a análise do ciclo de vida e monitoramento do trabalho ativo.
Onde obter
Disponível diretamente como o campo 'state' nos payloads JSON para issues e pull requests da API do GitHub.
Exemplos
openfechadomerged
|
|||
|
Etiquetas (Labels)
Labels
|
Uma lista de tags ou etiquetas aplicadas a uma issue ou pull request para categorização. | ||
|
Descrição
Labels no GitHub são uma forma flexível de adicionar metadados a issues e pull requests. Elas podem ser usadas para indicar prioridade, tipo de trabalho, componentes, equipes ou status. A lista bruta de etiquetas fornece um contexto rico e não estruturado. Embora atributos específicos como Prioridade e Tipo sejam derivados das etiquetas, manter a lista completa pode ser útil para análises ad-hoc e para descobrir outros padrões de processo. Isso permite filtragem flexível e segmentação de casos com base em qualquer combinação de labels.
Por que é importante
Oferece uma fonte flexível de metadados para categorizar itens de trabalho, permitindo análises dimensionais variadas e profundas.
Onde obter
Disponível como o array 'labels' no payload JSON para issues e pull requests da API do GitHub. Cada item no array é um objeto com um campo 'name'.
Exemplos
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Hash do Commit
CommitHash
|
O identificador único (SHA) de um commit de código específico. | ||
|
Descrição
Um hash de commit é um código SHA-1 de 40 caracteres que identifica exclusivamente um commit no Git. Ele funciona como um ID permanente para uma versão específica do código. Os commits são as unidades atômicas de mudança no processo de desenvolvimento. Embora seja altamente granular, o hash do commit oferece o nível máximo de rastreabilidade. Ele permite que analistas vinculem um evento do processo diretamente à alteração exata feita no código. Isso é inestimável para auditoria, conformidade ou análise detalhada de causa raiz em incidentes de produção.
Por que é importante
Oferece o link mais granular entre uma etapa do processo e a alteração exata no código, permitindo rastreabilidade total para auditorias e depuração.
Onde obter
Disponível em payloads de eventos de push ('head_commit.id') ou através da API de Commits para um pull request ou branch.
Exemplos
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Nome da Branch
BranchName
|
O nome da branch Git onde as alterações de código foram realizadas. | ||
|
Descrição
Uma branch é uma linha independente de desenvolvimento, criada para trabalhar em um novo recurso ou correção de bug sem afetar a base de código principal. O nome da branch geralmente contém 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 ramificação e a adesão às convenções de desenvolvimento. Também auxilia na vinculação de commits de código específicos a um item de desenvolvimento, fornecendo uma visão completa da atividade de codificação.
Por que é importante
Fornece contexto sobre a linha de desenvolvimento específica e ajuda a aplicar e analisar estratégias de branching e convenções de nomenclatura.
Onde obter
Disponível no campo 'ref' para eventos de push, ou nos objetos 'head' e 'base' dentro de uma resposta da API de pull request.
Exemplos
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Número do Pull Request
PullRequestNumber
|
O identificador único do pull request associado ao item de desenvolvimento. | ||
|
Descrição
Um Pull Request (PR) é uma proposta para mesclar um conjunto de alterações de código em uma branch específica. O Número do Pull Request vincula as atividades de desenvolvimento, como envios de código e revisões, de volta ao item de desenvolvimento primário ou à issue. Este ID é crucial para rastrear o subprocesso de integração e revisão de código dentro do ciclo de vida de desenvolvimento mais amplo. Ele permite uma análise detalhada do processo de revisão de código, incluindo tempos de revisão, ciclos de retrabalho identificados durante a revisão e taxas de mesclagem (merge). Ele conecta a fase de planejamento (issue) com a fase de implementação (PR).
Por que é importante
Vincula as issues às alterações de código específicas e aos processos de revisão, permitindo uma análise detalhada do ciclo de revisão de código e seu impacto no tempo total de entrega.
Onde obter
Disponível como o campo 'number' dentro do objeto 'pull_request' em muitas respostas da API do GitHub, ou como o identificador principal da API de Pull Requests.
Exemplos
12345678910
|
|||
|
Revisor
Reviewer
|
O usuário solicitado para realizar o code review no 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 quanto à qualidade, correção e adesão aos padrões. Um pull request pode ter vários revisores. Este atributo é essencial para analisar o processo de revisão de código. Ele ajuda a identificar gargalos relacionados a revisores específicos, entender a distribuição da carga de trabalho de revisão e medir o tempo que os revisores levam para responder às solicitações. É um componente fundamental para o cálculo do KPI 'Tempo Médio do Ciclo de Revisão de Código'.
Por que é importante
Identifica os indivíduos envolvidos no processo de garantia de qualidade (QA), permitindo a análise de cargas de trabalho de revisão, atrasos e a eficiência geral das revisões de código.
Onde obter
Disponível no array 'requested_reviewers' ou no objeto 'user' de um evento de revisão de pull request da API do GitHub.
Exemplos
alex.chenmaria.garciasenior-dev-team
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema do qual os dados do processo foram extraídos. | ||
|
Descrição
Identifica a origem dos dados (neste caso, 'GitHub'). Em ambientes que usam múltiplos sistemas (ex: Jira, Jenkins), este campo distingue a fonte de cada evento. Na análise, ajuda a rastrear a origem dos dados para validação e permite analisar processos que atravessam diferentes plataformas com clareza.
Por que é importante
Identifica a origem dos dados, o que é essencial para validação e para analisar processos que podem abranger múltiplos sistemas integrados.
Onde obter
Geralmente um valor estático adicionado durante o processo de ETL para identificar a fonte dos registros.
Exemplos
GitHubGitHub Enterprise
|
|||
|
Status da Verificação de CI
CiCheckStatus
|
O status de uma verificação automatizada de CI, como 'passed' ou 'failed'. | ||
|
Descrição
Reflete o resultado de builds e testes automatizados. Verificações de CI são etapas críticas de qualidade. Analisar este atributo ajuda a medir a eficácia dos testes. Muitas falhas podem indicar instabilidade no código ou no ambiente de testes, ajudando a explicar atrasos causados por builds quebradas.
Por que é importante
Indica o sucesso ou falha dos quality gates automatizados, fornecendo insights sobre a qualidade do código e a eficácia do pipeline de CI.
Onde obter
Obtido a partir do campo 'state' ou 'conclusion' de objetos de execução ou status de verificação via GitHub Checks ou Statuses API.
Exemplos
successfailurependingerror
|
|||
|
Tempo de Ciclo de Desenvolvimento
DevelopmentCycleTime
|
O tempo total decorrido desde a criação de um item até seu deploy final ou fechamento. | ||
|
Descrição
Esta métrica de caso é calculada como a diferença de tempo entre o primeiro evento (ex: 'Issue Criada') e o último (ex: 'Deploy com Sucesso'). É um dos KPIs mais importantes para medir a eficiência total do processo. Apoia o dashboard de 'Cycle Time Total', e reduzi-lo costuma ser o principal objetivo de melhorias de processo.
Por que é importante
Representa o time-to-market de ponta a ponta de um item, sendo um KPI crítico para medir a velocidade e eficiência geral do processo.
Onde obter
Calculado no nível do caso subtraindo o timestamp da primeira atividade do timestamp da última atividade.
Exemplos
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Tempo de Espera no Handoff
HandoffWaitingTime
|
O tempo de inatividade calculado que um item passa esperando entre atividades feitas por pessoas diferentes. | ||
|
Descrição
Mede o intervalo entre o fim de uma atividade e o início da próxima quando há troca de responsável (ex: de desenvolvedor para revisor). É vital para identificar falhas de comunicação e coordenação. Apoia o dashboard de 'Eficiência de Handoff'. Longas esperas costumam indicar falta de braço ou processos de notificação ineficientes.
Por que é importante
Identifica atrasos causados por falhas de coordenação ou falta de recursos durante handoffs entre times ou funções, que costumam ser grandes fontes de ineficiência.
Onde obter
Calculado identificando atividades sequenciais onde o atributo 'Assignee' ou 'User' muda, e medindo o intervalo de tempo entre elas.
Exemplos
PT1H15MP2DT4HPT25M
|
|||
|
Tempo de Processamento
ProcessingTime
|
A duração calculada de uma atividade, representando o tempo de trabalho ativo. | ||
|
Descrição
Tempo de Processamento é o tempo decorrido entre o início e o fim de uma atividade. Ele mede quanto tempo leva para concluir uma tarefa, excluindo o tempo de espera. Analisar o tempo de processamento ajuda a identificar quais atividades consomem mais esforço ativo. Isso difere do cycle time, que inclui o tempo de espera. Por exemplo, um code review pode ter um cycle time longo, mas um tempo de processamento curto, indicando que o revisor está ocupado e o PR está parado em uma fila.
Por que é importante
Mede a duração do trabalho ativo, ajudando a distinguir o tempo gasto na execução de uma tarefa do tempo de espera, o que é fundamental para melhorias de eficiência direcionadas.
Onde obter
Calculado subtraindo o 'EventTimestamp' do 'EndTimestamp' para um único registro de atividade.
Exemplos
PT5M15SPT2H30MP1DT12H
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp que indica quando os dados para este registo foram atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Registra a data da última extração de dados. Indica quão atualizados estão os dados analisados. É crucial para saber se a visão do processo é em tempo real ou um recorte de um momento específico, o que é fundamental para o monitoramento operacional.
Por que é importante
Indica a atualização dos dados, fundamental para garantir que as análises e dashboards reflitam informações recentes.
Onde obter
Este timestamp é gerado e adicionado durante o processo de extração, transformação e carga (ETL).
Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
Atividades do Ciclo de Vida de Desenvolvimento
| Atividade | Descrição | ||
|---|---|---|---|
|
Problema Criado
|
Marca o início do ciclo de vida de um item de desenvolvimento, representando a criação formal de uma tarefa, bug ou solicitação de funcionalidade. Este evento é capturado explicitamente quando um usuário cria uma nova issue em um repositório do GitHub. | ||
|
Por que é importante
Atividade inicial do processo, essencial para medir o cycle time total e entender a origem das demandas.
Onde obter
Evento capturado via GitHub Issues API. O tipo costuma ser 'opened' para um número de issue específico.
Captura
Monitore o evento 'opened' em uma issue via webhooks ou consulta de API.
Tipo de evento
explicit
|
|||
|
Problema Encerrado
|
O item é considerado concluído e a issue é fechada. Isso pode ocorrer automaticamente no merge do pull request ou manualmente por um membro do time. | ||
|
Por que é importante
Esta atividade serve como o fim definitivo do processo para um item, sendo crítica para calcular o cycle time de ponta a ponta.
Onde obter
Evento capturado via GitHub Issues API. O tipo de evento é 'closed'.
Captura
Monitore o evento 'closed' em uma issue via webhooks ou consulta de API.
Tipo de evento
explicit
|
|||
|
Pull Request Aberto
|
Indica que o código está pronto para revisão e integração. O desenvolvedor cria um pull request (PR) para propor mudanças da branch de feature para a branch principal. | ||
|
Por que é importante
Um marco crítico que divide o fim do desenvolvimento inicial e o início da esteira de revisão e integração. Essencial para analisar os tempos de cada fase separadamente.
Onde obter
Capturado do fluxo de eventos da API de Pull Request do GitHub ou webhooks. A ação do evento é 'opened'.
Captura
Monitore a ação 'opened' em um pull request via webhooks ou consulta de API.
Tipo de evento
explicit
|
|||
|
Pull Request Aprovado
|
Um revisor aprovou formalmente as alterações em um pull request, indicando que ele atende aos padrões de qualidade e funcionais. Isso é capturado quando um revisor envia sua revisão com o status 'approve'. | ||
|
Por que é importante
Um portão de qualidade e marco importante antes do merge. O tempo levado para chegar aqui após a criação do PR é um KPI crítico para a eficiência do processo de revisão.
Onde obter
Capturado da API de Pull Request do GitHub ou webhooks quando uma revisão é enviada com o estado 'APPROVED'.
Captura
Filtrar eventos de envio de revisão de pull request para o estado 'APPROVED'.
Tipo de evento
explicit
|
|||
|
Pull Request Mesclado
|
As mudanças de código aprovadas no pull request são integradas à branch de destino. Esta é a ação final que incorpora o novo código ao projeto. | ||
|
Por que é importante
Este é um marco crítico que representa a conclusão do desenvolvimento e da revisão. Para muitos times, é o passo final antes do deploy automatizado.
Onde obter
Capturado do fluxo de eventos da API de Pull Request do GitHub ou webhooks. A ação do evento é 'closed' e o atributo 'merged' do payload do pull request é true.
Captura
Monitore a ação 'closed' em um pull request e verifique se a flag 'merged' é verdadeira.
Tipo de evento
explicit
|
|||
|
Verificações de CI Passaram
|
Representa a conclusão com sucesso de verificações automatizadas, como builds ou análise estática. Este evento é inferido pelo status reportado pelo GitHub Actions. | ||
|
Por que é importante
Este portão de qualidade automatizado é crucial para a estabilidade do código. Falhas ou execuções demoradas podem ser gargalos significativos na esteira de entrega.
Onde obter
Inferido da API de Checks ou API de Statuses do GitHub. Uma execução de verificação ou atualização de status relata 'success' ou 'completed' com uma conclusão de 'success'.
Captura
Monitore a Checks API em busca de uma conclusão de 'success' nas suítes de verificação 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 modificações antes que o pull request possa ser aprovado. O revisor envia formalmente sua revisão com o status 'request_changes'. | ||
|
Por que é importante
Este evento sinaliza explicitamente um loop de retrabalho. Analisar sua frequência ajuda a identificar falhas de qualidade, requisitos confusos ou necessidade de treinamento.
Onde obter
Capturado da API de Pull Request do GitHub ou webhooks quando uma revisão é enviada com o estado 'CHANGES_REQUESTED'.
Captura
Filtrar eventos de envio de revisão de pull request para o estado 'CHANGES_REQUESTED'.
Tipo de evento
explicit
|
|||
|
Branch Criada
|
Representa o início do trabalho ativo em uma issue. É um evento capturado quando uma nova branch é enviada ao repositório, geralmente contendo o número da issue no nome. | ||
|
Por que é importante
Indica a transição do planejamento para a codificação ativa. Medir o tempo entre a criação da issue e este evento ajuda a analisar o tempo de início do desenvolvedor e atrasos iniciais no backlog.
Onde obter
Capturado via API Git do GitHub ou webhooks ouvindo eventos 'create' do tipo 'branch'. Muitas vezes é necessário vincular o nome da branch a uma issue por meio de convenções de nomenclatura, como 'feature/issue-123'.
Captura
Analise eventos de webhook 'create' para novas branches e associe-os a uma issue.
Tipo de evento
explicit
|
|||
|
Código Enviado para PR
|
Representa uma atualização no código enviado para revisão. Este evento é capturado cada vez que um novo commit é enviado para a branch associada a um pull request aberto. | ||
|
Por que é importante
Rastrear estes eventos é crucial para identificar loops de retrabalho. Múltiplos pushes após uma revisão indicam que alterações foram exigidas, afetando o cycle time.
Onde obter
Evento explícito na timeline do pull request, geralmente indicado pela adição de um commit. Capturado via webhook 'push' ou monitoramento de commits no PR.
Captura
Rastreie eventos de 'push' em uma branch associada a um pull request aberto.
Tipo de evento
explicit
|
|||
|
Implantação com Sucesso
|
As mudanças foram implantadas com sucesso em um ambiente específico. Este evento é capturado via GitHub Deployments API, geralmente após um merge. | ||
|
Por que é importante
Marca a transição do código do repositório para um ambiente de produção. Rastrear isso é essencial para medir o lead time total, desde a concepção da ideia até a produção.
Onde obter
Capturado via API de Deployments. Um serviço externo ou GitHub Action cria uma implantação e depois atualiza seu status para 'success'.
Captura
Monitore eventos de status de deploy via webhooks em busca do estado 'success'.
Tipo de evento
inferred
|
|||
|
Issue Reaberta
|
Uma issue anteriormente fechada é reativada, geralmente porque a correção foi insuficiente ou uma regressão foi encontrada. Este é um evento explícito que reinicia o ciclo de vida do item de desenvolvimento. | ||
|
Por que é importante
Sinaliza um loop de retrabalho importante, indicando um defeito que escapou para produção ou uma correção incompleta. Sua frequência mede a qualidade do software.
Onde obter
Evento capturado via GitHub Issues API. O tipo de evento é 'reopened'.
Captura
Monitore o evento 'reopened' em uma issue via webhooks ou consulta de API.
Tipo de evento
explicit
|
|||
|
Revisão Solicitada
|
O autor do pull request solicita formalmente que membros do time revisem o código. Essa ação no GitHub dispara notificações para os revisores escolhidos. | ||
|
Por que é importante
Marca o início oficial do handoff para o processo de code review. O tempo entre este evento e a entrega da revisão mede a agilidade dos revisores e possíveis gargalos.
Onde obter
Capturado do fluxo de eventos da API de Pull Request do GitHub ou webhooks. A ação do evento é 'review_requested'.
Captura
Monitore a ação 'review_requested' em um pull request.
Tipo de evento
explicit
|
|||
|
Verificações de CI Falharam
|
Representa a falha de uma verificação automatizada, como erro de build ou teste unitário. Isso é inferido a partir do status de falha reportado por sistemas como o GitHub Actions. | ||
|
Por que é importante
Esta atividade destaca problemas de qualidade técnica que exigem intervenção, gerando retrabalho. Analisar a frequência de falhas ajuda a melhorar os testes locais ou a qualidade do código.
Onde obter
Inferido da API de Checks ou API de Statuses do GitHub. Uma execução de verificação ou atualização de status relata 'failure' ou 'completed' com uma conclusão de 'failure'.
Captura
Monitore a Checks API em busca de uma conclusão de 'failure' nas suítes de verificação relevantes.
Tipo de evento
inferred
|
|||