Desempenho de pipeline

Durações de build, taxas de sucesso e falha, MTTR, execuções recentes de workflow e onde aparecem as execuções autocorrigidas.

A página Pipeline Performance acompanha quão saudáveis e quão rápidos são seus workflows.

Há duas formas de usá-la. Como monitor, você dá uma olhada na visão geral e nas tendências para responder "a CI está melhorando ou piorando?" Como ferramenta de investigação, você filtra até um repositório ou workflow e usa a tabela de execuções e as métricas de recuperação para responder "o que exatamente aconteceu, e como lidamos com isso?" As seções abaixo estão dispostas aproximadamente nessa ordem.

Performance Overview#

• Workflow Health: taxa de sucesso geral como um medidor.
• Average Build Duration, Successful Builds e Failed Builds para a janela selecionada.
• Top Failed Builds: os três repositórios e os três workflows com mais builds com falha. Cada entrada tem link direto para o repositório ou o arquivo de workflow no GitHub, para que você possa pular do ponto crítico para a correção.
• Contagens de Repositories Monitored e Workflows Monitored, confirmando exatamente o que os números abrangem.

Orientação para ler o medidor: um único dia ruim raramente significa muito; uma única mesclagem quebrada pode afundar a taxa de sucesso de um dia sozinha. O que merece atenção é uma queda sustentada ao longo da janela, ou uma diferença entre repositórios: se a saúde de um repo fica muito abaixo do restante, Top Failed Builds geralmente nomeará o workflow responsável, e seu link direto leva você diretamente ao arquivo de workflow no GitHub.

Build Trends#

• Successful Builds Over Time by Repository: a tendência diária de builds bem-sucedidos, uma linha por repositório.
• Average Build Duration by Repository e Workflow Duration: gráficos de barras classificando repositórios e workflows por duração média, cada um com um menu suspenso Top 5 / Bottom 5. Os rótulos dos gráficos têm link para o repositório ou o arquivo de workflow no GitHub.
• Build Duration Trend Across Workflows para identificar pipelines que estão ficando mais lentos.

As tendências de duração vêm em dois formatos que vale distinguir. Uma mudança em degrau (a duração salta em um dia específico e permanece lá) quase sempre remonta a uma edição concreta: uma nova etapa, uma mudança de dependência, um runner diferente. Uma lenta escalada é o problema mais silencioso: conjuntos de testes crescentes e etapas acumuladas que ninguém percebe semana a semana. Os gráficos de tendência existem para tornar a escalada visível. Note que o agente de IA também observa isso: uma execução que leva muito mais tempo do que a média recente é um dos eventos que dispara uma análise em Optimization Insights.

Recent Workflow Runs#

A tabela Workflow Runs é um único feed de execuções individuais em todos os seus repositórios: ícone de status, timestamp, repositório, workflow, branch e duração. Cada coluna é ordenável, a ordem padrão é mais recente primeiro, e as execuções são paginadas a 13 por página. Clicar em uma linha abre a execução no GitHub.

Quando a autocorreção do Latchkey repara uma execução, a tabela mostra um selo verde Healed na coluna Heal. Clique nele para abrir o painel Heal Details na página Runners: o que falhou, o diagnóstico e a ação exata tomada em linguagem simples; para falhas diagnosticadas por IA, também inclui as iterações do agente. Isso importa ao ler esta página porque uma execução corrigida conta como um resgate, não uma passagem limpa: se o mesmo workflow continua precisando de correções, a instabilidade subjacente ainda está ali para ser resolvida. Veja Autocorreção para como a correção funciona e a página Runners para o feed completo de Recent Heals.

Recovery & Comparative Analysis#

• Build Fail Rate e Rebuild Success Rate: com que frequência os builds falham, e com que frequência uma re-execução fica verde.
• Mean Time to Recovery (MTTR) e MTTR Over Time: o tempo médio entre um build com falha e o próximo build bem-sucedido, acompanhado de sua tendência diária.
• Build Status by Repository: builds bem-sucedidos, com falha e cancelados por repositório em um gráfico de barras empilhadas, com um menu suspenso Top 5 / Bottom 5.

O que cada métrica de recuperação informa#

MTTR é o tempo médio entre um build com falha e o próximo build bem-sucedido. Ele mede todo o ciclo de recuperação da sua equipe: notar o build vermelho, diagnosticá-lo e entregar a correção. Não há um número "bom" universal; uma equipe que faz deploy muitas vezes ao dia precisa de MTTR medido em minutos, enquanto uma equipe de release semanal pode tolerar horas. O que é universalmente ruim é uma tendência crescente de MTTR Over Time: significa que as falhas estão ficando mais difíceis de diagnosticar, ou que a equipe está ficando mais lenta para responder, e qualquer uma das duas se agrava.

Rebuild Success Rate é o detector de instabilidade. Ele lhe diz qual fração das falhas desaparece quando você simplesmente executa o build de novo, e os dois extremos apontam para problemas muito diferentes:

Build Fail Rate só se torna significativa ao lado da taxa de sucesso de rebuild. Uma taxa de falha de 10% feita de regressões reais e uma taxa de falha de 10% feita de falhas instáveis do tipo re-execute-e-esqueça são problemas inteiramente diferentes, e esta página lhe dá ambos os números precisamente para que você possa distingui-los.

Glossário de métricas#