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

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

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

Este Template abrangente orienta você sobre os dados essenciais para analisar o processo de ciclo de vida do desenvolvimento de software. Ele apresenta os principais atributos a coletar, as atividades importantes a acompanhar e orientações práticas para extrair essas informações diretamente do GitLab. Com esse material, você pode preparar seus dados para uma análise de Process Mining com mais segurança.
  • Atributos recomendados para coleta
  • Principais atividades a acompanhar
  • Orientações para extração
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos do ciclo de vida do desenvolvimento de software

Estes são os campos de dados recomendados para incluir no Event Log e fazer uma análise abrangente do ciclo de vida do desenvolvimento de software, identificando oportunidades de otimização.
3 Obrigatório 5 Recomendado 12 Opcional
Nome Descrição
Atividade
Activity
Nome da etapa ou do evento específico do processo, como “Issue criada” ou “Merge request integrada”.
Descrição

O atributo Atividade registra os eventos distintos que ocorrem com um item de desenvolvimento. No GitLab, eles não ficam armazenados em um único campo, mas são derivados de várias ações e campos de data e hora em Issues, Merge Requests e Pipelines de CI/CD. Por exemplo, a criação de uma issue, o envio de um commit, a falha de um pipeline e a aprovação de uma merge request são atividades distintas.

Esse atributo é fundamental para criar o mapa do processo, visualizar o fluxo de trabalho e analisar a sequência e a frequência dos eventos. Ele ajuda a identificar desvios, gargalos entre etapas e caminhos comuns do processo.

Por que isso importa

Define as etapas do mapa do processo e permite visualizar e analisar o fluxo de trabalho de desenvolvimento de ponta a ponta.

Onde encontrar

Derivado dos tipos de evento e das mudanças de estado no fluxo de eventos do GitLab ou da interpretação de campos de data e hora, como created_at, merged_at e closed_at, em Issues e Merge Requests.

Exemplos
Issue criadaDesenvolvimento iniciadoMerge request integradaPipeline com falhaImplantado em produção
Hora de início
StartTime
Data e hora que indicam quando uma atividade ou um evento começou.
Descrição

StartTime indica a data e a hora exatas em que uma atividade específica ocorreu. No GitLab, esses dados são registrados em diferentes campos. Por exemplo, a hora de início da atividade “Issue criada” corresponde ao campo created_at da issue, enquanto a hora de início de “Merge request integrada” corresponde ao campo merged_at da merge request.

Essa data e hora são o principal elemento temporal no Process Mining. Elas servem para ordenar os eventos cronologicamente, calcular a duração entre atividades, medir tempos de ciclo e analisar a performance do processo ao longo do tempo.

Por que isso importa

Este atributo fornece a sequência cronológica dos eventos, essencial para calcular todas as métricas baseadas em tempo e entender o fluxo do processo.

Onde encontrar

Extraído de vários campos de data e hora do GitLab, como created_at, updated_at e closed_at nas issues e merged_at nas merge requests.

Exemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Item de desenvolvimento
DevelopmentItem
Identificador exclusivo de uma unidade de trabalho, como uma funcionalidade, correção de bug ou tarefa. Ele serve como identificador principal do caso.
Descrição

O item de desenvolvimento representa uma unidade de trabalho rastreável que percorre o ciclo de vida de desenvolvimento de software. Ele reúne em um único caso todas as atividades relacionadas, da criação à implantação final. No GitLab, costuma ser representado pelo ID interno da issue (IID), exclusivo dentro de um projeto.

Analisar os dados por item de desenvolvimento permite medir o tempo de ciclo de ponta a ponta, identificar gargalos e verificar a Conformidade do processo. Essa análise é a base para entender a eficiência com que o trabalho é entregue, do conceito à produção.

Por que isso importa

Este é o identificador essencial do caso, que conecta todos os eventos do processo e permite rastrear o ciclo de vida completo de qualquer item de trabalho.

Onde encontrar

Normalmente, este é o ID interno (IID) de uma issue do GitLab. Ele aparece no campo iid da resposta da API de Issues.

Exemplos
1024512PRJ-2345
Gravidade
Severity
Nível de gravidade do item de desenvolvimento, geralmente usado para bugs ou incidentes.
Descrição

A gravidade indica o impacto de um bug ou problema, de crítico a baixo. O GitLab não tem um campo nativo para gravidade, então essa informação quase sempre é registrada em labels, como severity::1 e severity::2.

Este atributo é essencial para o Dashboard “Tendências de escalonamento de gravidade” e o KPI associado. Analisar as mudanças de gravidade ao longo do ciclo de vida pode revelar problemas inicialmente subestimados ou processos que agravam as situações.

Por que isso importa

Ajuda a priorizar o trabalho e analisar se os itens de alta gravidade são tratados mais rapidamente. Acompanhar as mudanças também permite calcular o KPI “Frequência de escalonamento de gravidade”.

Onde encontrar

Derivado das labels aplicadas a uma Issue do GitLab. É necessário mapear labels como S1 e S2 para interpretá-las como níveis de gravidade.

Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
Hora de término
EndTime
Data e hora que indicam quando uma atividade ou um evento foi concluído.
Descrição

EndTime indica a data e a hora exatas em que uma atividade terminou. Para muitos eventos pontuais no GitLab, como “Issue criada”, EndTime é igual a StartTime. Em atividades com duração, como “Revisão de código”, indica o momento da conclusão, por exemplo, quando a aprovação final é concedida.

Este atributo é essencial para calcular com precisão a duração de atividades individuais (tempo de processamento). Ele ajuda a analisar gargalos em detalhes, distinguindo o tempo dedicado ao trabalho ativo do tempo de espera entre tarefas.

Por que isso importa

Permite calcular com precisão a duração das atividades (tempos de processamento), o que é fundamental para identificar etapas ineficientes no processo.

Onde encontrar

Para eventos pontuais, corresponde a StartTime. Para atividades com duração, deve ser derivado da identificação do evento de conclusão correspondente nos dados.

Exemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Nome do projeto
ProjectName
Nome do projeto do GitLab ao qual o item de desenvolvimento pertence.
Descrição

Este atributo identifica o repositório de código ou projeto específico em que o trabalho é realizado. No GitLab, toda issue e merge request pertence a um projeto.

Analisar os dados por nome do projeto permite comparar a performance entre diferentes produtos, componentes ou serviços. Isso pode ajudar a identificar projetos com processos de SDLC mais saudáveis e permite filtrar Dashboards para uma área específica.

Por que isso importa

Permite segmentar a análise do processo por produto, aplicação ou componente e direcionar os esforços de melhoria.

Onde encontrar

Obtido dos campos name ou path_with_namespace da API de Projects, vinculados pelo campo project_id em Issues e Merge Requests.

Exemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Responsável
Assignee
Usuário responsável pela issue ou merge request no momento do evento.
Descrição

O responsável é o desenvolvedor ou usuário encarregado do item de trabalho em determinado momento do processo. No GitLab, essa informação fica nos campos assignee ou assignees de uma Issue ou Merge Request.

Analisar os dados por responsável é fundamental para o Dashboard “Carga de trabalho e alocação de desenvolvedores”. Isso ajuda a entender o uso dos recursos, identificar pessoas ou equipes sobrecarregadas e analisar os handoffs entre diferentes pessoas.

Por que isso importa

Registra quem executou o trabalho e permite analisar a carga de trabalho, a eficiência da alocação de recursos e os atrasos causados por handoffs.

Onde encontrar

Obtido dos campos assignee.username ou assignees nas respostas da API de Issues e Merge Requests do GitLab.

Exemplos
jdoeasmithr.williams
Tipo de item de desenvolvimento
DevelopmentItemType
Classificação do item de desenvolvimento, como “Funcionalidade”, “Bug”, “Tarefa” ou “Manutenção”.
Descrição

Este atributo classifica a natureza do trabalho realizado. No GitLab, isso costuma ser feito com labels em uma issue. As equipes usam labels para diferenciar novas funcionalidades, correções de defeitos, dívida técnica e outros tipos de trabalho.

Analisar os dados por tipo de item de desenvolvimento permite comparar os fluxos do processo e os tempos de ciclo de diferentes tipos de trabalho. Por exemplo, você pode verificar se os bugs são corrigidos mais rápido do que as funcionalidades são desenvolvidas ou se as tarefas de dívida técnica seguem outro processo de revisão.

Por que isso importa

Segmentar o processo por tipo de trabalho ajuda a identificar se alguns tipos têm maior probabilidade de sofrer atrasos, retrabalho ou desvios.

Onde encontrar

Geralmente, é derivado das labels aplicadas a uma Issue do GitLab. É preciso definir uma lógica de mapeamento para converter labels específicas em tipos padronizados.

Exemplos
FuncionalidadeBugTarefaDívida técnica
Branch de destino
TargetBranch
O nome da branch de destino de uma solicitação de merge.
Descrição

A branch de destino é aquela que receberá as alterações mescladas, como 'main', 'develop' ou uma branch de release, por exemplo, 'release/1.5'. Essa é uma informação essencial de qualquer solicitação de merge.

Analisar os dados por branch de destino pode revelar diferenças no processo de integração de código conforme o destino. Por exemplo, merges na 'main' podem exigir um processo de aprovação mais rigoroso e ter tempos de ciclo maiores do que os merges em uma branch de funcionalidade. Essa análise também ajuda a diferenciar implantações em produção de outros tipos de integração de código.

Por que isso importa

Ajuda a diferenciar os fluxos de trabalho de desenvolvimento e release, que podem variar bastante conforme a branch de destino.

Onde encontrar

Obtido do campo 'target_branch' na resposta da API de Merge Requests do GitLab.

Exemplos
maindeveloprelease/v2.1.0hotfix/user-auth-bug
É retrabalho
IsRework
Indicador booleano que informa se uma atividade faz parte de um ciclo de retrabalho.
Descrição

Este atributo calculado sinaliza atividades que representam um retrocesso no processo, como voltar ao desenvolvimento depois do início dos testes. Em geral, a lógica desse indicador identifica sequências específicas de atividades. Por exemplo, um evento 'Desenvolvimento iniciado' que ocorre depois de 'Falha no pipeline' ou 'Início dos testes de QA' no mesmo caso.

Este atributo alimenta diretamente o dashboard 'Análise de retrabalho e reexecuções' e o KPI 'Taxa de retrabalho após os testes'. Ele facilita a filtragem e a quantificação do retrabalho, ajudando as equipes a entender sua frequência, suas causas e seu impacto nos cronogramas dos projetos.

Por que isso importa

Sinaliza e quantifica o retrabalho diretamente, facilitando a análise das causas e do impacto de ineficiências no processo e de problemas de qualidade.

Onde encontrar

Calculado pela ferramenta de Process Mining, que analisa a sequência de atividades de cada caso e identifica padrões que indicam retrabalho.

Exemplos
truefalse
Nome da equipe
TeamName
Equipe de desenvolvimento associada ao projeto ou ao responsável.
Descrição

Nome da equipe identifica o grupo ou squad responsável pelo item de desenvolvimento. Essa informação geralmente não é um campo padrão do GitLab e costuma ser derivada das convenções de nomenclatura dos projetos, das estruturas de grupos ou do mapeamento de responsáveis para suas respectivas equipes em uma tabela de referência externa.

Este atributo serve para analisar a performance do processo por equipe. Ele ajuda a comparar a eficiência, a carga de trabalho e a adesão ao processo entre diferentes equipes, além de apoiar Dashboards como “Análise de gargalos por etapa” com uma visão por equipe.

Por que isso importa

Permite analisar a performance e comparar processos entre equipes, ajudando a identificar gargalos específicos de cada equipe e boas práticas.

Onde encontrar

Geralmente, é derivado do mapeamento do nome do projeto ou do responsável para uma estrutura de equipes definida fora do GitLab, ou inferido a partir das hierarquias de grupos do GitLab.

Exemplos
Frontend-AlphaBackend-ServicesPlatform-Infra
Sistema de origem
SourceSystem
Identifica o sistema de onde os dados foram obtidos.
Descrição

Este atributo especifica a origem dos dados do processo. Neste modelo de dados, o valor será sempre “GitLab”.

Esse atributo é fundamental em ambientes que combinam dados de vários sistemas, como Jira para planejamento e GitLab para execução. Ele permite filtrar e segmentar os dados e ajuda a manter a linhagem dos dados.

Por que isso importa

Esclarece a origem dos dados, algo fundamental para a governança de dados e a integração de informações de vários sistemas corporativos.

Onde encontrar

Este valor estático, “GitLab”, é adicionado durante a transformação dos dados.

Exemplos
GitLab
Status da solicitação de merge
MergeRequestStatus
O status da solicitação de merge associada ao evento, como 'Aberta', 'Mesclada' ou 'Fechada'.
Descrição

Este atributo registra o estado de uma solicitação de merge (MR) no momento do evento. No GitLab, as MRs podem ter os estados 'opened', 'closed', 'merged' ou 'locked'. Esse atributo é diferente do status geral do item de desenvolvimento.

Acompanhar o status da MR é essencial para analisar a etapa de integração de código do SDLC. Esse dado alimenta diretamente dashboards como 'Tempo de ciclo e throughput da revisão de código' e ajuda a identificar atrasos entre a criação, a revisão, a aprovação e a mesclagem da MR.

Por que isso importa

Mostra como funciona o processo de revisão e mesclagem de código, que muitas vezes é um gargalo crítico no SDLC.

Onde encontrar

Obtido do campo 'state' na resposta da API de Merge Requests do GitLab.

Exemplos
AbertomescladaEncerradobloqueada
Status do item de desenvolvimento
DevelopmentItemStatus
Status do item de desenvolvimento no momento do evento, como “Aberto”, “Em andamento” ou “Encerrado”.
Descrição

Este atributo representa o estado do item de trabalho principal, geralmente uma Issue no GitLab. As Issues do GitLab têm um campo state, que pode ser opened ou closed. As equipes costumam gerenciar status mais detalhados com labels específicas, como Status::Triagem, Status::Em desenvolvimento e Status::Em revisão.

Acompanhar as mudanças de status é fundamental para entender o ciclo de vida do caso. Isso ajuda a identificar quanto tempo os itens permanecem em cada estado e permite filtrar trabalhos em andamento ou concluídos em Dashboards como “Tempo de ciclo de ponta a ponta do SDLC”.

Por que isso importa

Mostra o estado do caso e permite analisar o tempo gasto em cada etapa e filtrar trabalhos em andamento ou concluídos.

Onde encontrar

O status principal vem do campo state de uma Issue do GitLab (opened ou closed). Status mais detalhados costumam ser derivados de labels.

Exemplos
AbertoEncerradoEm andamentoEm revisão
Status do pipeline
PipelineStatus
O status da execução do pipeline de CI/CD, como 'Sucesso', 'Falha' ou 'Em execução'.
Descrição

Este atributo indica o resultado da execução de um pipeline de CI/CD associado a um commit ou a uma solicitação de merge. No GitLab, os status mais comuns são 'running', 'pending', 'success', 'failed', 'canceled' e 'skipped'.

Esses dados são essenciais para o dashboard 'Análise de retrabalho e reexecuções'. Falhas frequentes no pipeline podem gerar retrabalho e atrasos significativos. Analisar a frequência, onde ocorrem e seu impacto é fundamental para melhorar a eficiência do desenvolvimento e a qualidade do código.

Por que isso importa

Acompanha o sucesso e as falhas de builds e testes automatizados, destacando ciclos de retrabalho e problemas de qualidade do código ou de automação de testes.

Onde encontrar

Obtido do campo 'status' na resposta da API de Pipelines de CI/CD do GitLab.

Exemplos
sucessofalhaem execuçãocancelado
Tempo de ciclo
CycleTime
O tempo total entre a primeira e a última atividade de um item de desenvolvimento.
Descrição

O tempo de ciclo é uma métrica calculada que mede a duração total de um caso. Em geral, é calculado pela diferença entre o primeiro evento, como 'Issue criada', e o último, como 'Implantado em produção', de um item de desenvolvimento.

Esse é um KPI essencial para medir a eficiência geral do processo. É a principal métrica de dashboards como 'Tempo de ciclo de ponta a ponta do SDLC' e ajuda a acompanhar melhorias e identificar casos demorados que podem indicar problemas sistêmicos.

Por que isso importa

Este é um KPI essencial de Process Mining que mede a eficiência de ponta a ponta do ciclo de vida do desenvolvimento.

Onde encontrar

Calculado pela ferramenta de Process Mining, subtraindo o StartTime mínimo do StartTime máximo de cada CaseId exclusivo.

Exemplos
10 dias e 4 horas23 horas e 15 minutos35 dias
Tempo de espera na transferência
HandoffWaitTime
Tempo ocioso calculado entre duas atividades consecutivas realizadas por responsáveis diferentes.
Descrição

Esta métrica calcula o intervalo entre a conclusão de uma atividade e o início da seguinte, especificamente quando há uma mudança de responsável. Por exemplo, mede o tempo entre a conclusão do trabalho de um desenvolvedor e o início da revisão de código por outra pessoa.

É a métrica principal do KPI 'Tempo médio de espera na transferência'. Ela ajuda a identificar ineficiências na alocação de recursos e na comunicação entre equipes ou pessoas, revelando atrasos que não fazem parte de nenhuma atividade em andamento.

Por que isso importa

Quantifica o tempo ocioso durante transferências entre pessoas ou equipes, revelando atrasos ocultos e gargalos de comunicação.

Onde encontrar

Calculado pela ferramenta de Process Mining. Para isso, ela analisa eventos consecutivos de um caso, verifica se o 'Responsável' mudou e calcula a diferença entre os horários.

Exemplos
1 dia e 2 horas15 minutos8 horas
Título do marco
MilestoneTitle
O título do marco ou sprint ao qual o item de desenvolvimento está associado.
Descrição

No GitLab, um marco é usado para acompanhar o trabalho relacionado a uma meta ou período definido, como um sprint ou uma versão de release. Este atributo registra o nome ou título desse marco.

Com ele, você pode analisar a performance do processo em sprints ou períodos de planejamento específicos. Assim, é possível verificar se o tempo de ciclo está diminuindo de um sprint para outro ou filtrar a visualização do processo para exibir apenas o trabalho relacionado a uma próxima release.

Por que isso importa

Relaciona o trabalho de desenvolvimento a ciclos de planejamento, como sprints ou releases, permitindo analisar a performance em relação aos períodos planejados.

Onde encontrar

Obtido do campo 'milestone.title' nas respostas da API de Issues ou Merge Requests do GitLab.

Exemplos
Release do 4º trimestre de 2023Sprint 23.11Fase 1: MVP
Última atualização dos dados
LastDataUpdate
Data e hora que indicam quando os dados deste evento foram atualizados pela última vez a partir do sistema de origem.
Descrição

Este atributo registra a data e a hora da última extração ou atualização dos dados do evento no conjunto de dados de Process Mining. Ele não indica quando o evento ocorreu, mas quando o registro foi sincronizado pela última vez.

Essa informação é essencial para entender a atualização dos dados e verificar se a análise do processo está em dia. Ela ajuda a confiar que os Dashboards e KPIs usam dados recentes e mostra o possível intervalo entre o sistema de origem e a análise.

Por que isso importa

Mostra se os dados estão atualizados e permite que você saiba o quanto a análise do processo está em dia.

Onde encontrar

A ferramenta de extração de dados ou o processo de ETL gera e registra essa data e hora durante a atualização dos dados.

Exemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Versão da release
ReleaseVersion
A versão planejada ou efetiva do software associada à implantação.
Descrição

Este atributo identifica a release de software específica à qual um item de desenvolvimento pertence. No GitLab, essa associação pode ser feita por meio de um marco, uma tag protegida ou uma entrada no recurso Releases.

Esse dado é essencial para o dashboard 'Acompanhamento do cumprimento do cronograma de releases'. Ao comparar a data efetiva da implantação com a data planejada para a versão da release, as organizações podem avaliar se estão cumprindo os prazos e identificar as causas dos atrasos.

Por que isso importa

Relaciona os itens de desenvolvimento a uma release de software específica, o que é essencial para acompanhar o progresso e o cumprimento do cronograma.

Onde encontrar

Esse dado pode vir de GitLab Releases, do nome de uma tag do Git ou do título de um marco usado no planejamento da release.

Exemplos
v1.2.0v3.0.0-beta2023.4.1
Obrigatório Recomendado Opcional

Atividades do ciclo de vida do desenvolvimento de software

Estas são as principais etapas e os marcos do processo a registrar no Event Log para descobrir o processo com precisão e identificar gargalos.
4 Recomendado 8 Opcional
Atividade Descrição
Implantado em produção
Esta atividade marca a implantação bem-sucedida do código no ambiente de produção, disponibilizando-o para os usuários finais. O evento é registrado quando um job específico de implantação em produção é concluído com sucesso em um pipeline de CI/CD do GitLab.
Por que isso importa

Este é o principal evento de encerramento do processo e indica que o valor foi entregue. Ele é essencial para medir o tempo total de ciclo do SDLC de ponta a ponta e a frequência de lançamento.

Onde encontrar

O evento é obtido do campo finished_at de um job de CI/CD concluído com sucesso e designado especificamente para implantar em produção. A funcionalidade Environments do GitLab registra essa informação explicitamente.

Coleta

Use o campo finished_at do job de CI concluído com sucesso para a implantação em produção.

Tipo de evento explicit
Issue criada
Esta atividade marca o início do ciclo de vida de desenvolvimento e representa a criação de um novo item de trabalho, como uma funcionalidade, um bug ou uma tarefa. Ela é registrada quando alguém cria uma nova issue no GitLab, que armazena a data e hora da criação.
Por que isso importa

Este é o principal evento de início do processo de ponta a ponta. Analisar o tempo entre a criação da issue e a implantação oferece uma visão completa do tempo de ciclo do SDLC.

Onde encontrar

Este evento é registrado explicitamente a partir do campo created_at da tabela issues ou pela API de Issues. As notas do sistema também registram a criação.

Coleta

Use o campo created_at da issue.

Tipo de evento explicit
Merge request criada
Indica que o trabalho inicial de desenvolvimento foi concluído e que o código está pronto para revisão e integração. Este é um evento explícito e fundamental no fluxo de trabalho do GitLab, registrado quando um desenvolvedor abre uma nova merge request (MR).
Por que isso importa

Este é um marco crítico que sinaliza a transferência do desenvolvimento para a revisão e os testes. Também marca o início da análise de todo o ciclo de revisão de código e do pipeline de CI/CD.

Onde encontrar

Este evento é registrado explicitamente a partir do campo created_at da tabela merge_requests ou pela API de Merge Requests.

Coleta

Use o campo created_at da merge request.

Tipo de evento explicit
Merge request integrada
Esta atividade indica a conclusão bem-sucedida da revisão e da integração do código. O evento é registrado explicitamente quando alguém integra a branch da merge request à branch de destino.
Por que isso importa

Este é um marco importante que indica a conclusão do desenvolvimento e da revisão. Ele encerra a medição do tempo de ciclo de desenvolvimento e inicia a medição do lead time de implantação.

Onde encontrar

Este evento é registrado explicitamente a partir do campo merged_at da tabela merge_requests. O GitLab também gera uma nota do sistema quando a integração é concluída.

Coleta

Use o campo merged_at da merge request.

Tipo de evento explicit
Aprovação adicionada
Representa a aprovação formal das alterações de código de uma merge request por um revisor. O GitLab registra esse evento explicitamente quando alguém clica no botão Aprovado.
Por que isso importa

As aprovações são etapas fundamentais de controle de qualidade. Acompanhar esse processo ajuda a analisar quanto tempo leva para obter as aprovações necessárias e a garantir a Conformidade com as políticas de revisão.

Onde encontrar

O evento é obtido dos registros de aprovação da merge request. Esses dados estão disponíveis pela API de Approvals ou no histórico da MR.

Coleta

Use a data e hora do registro de aprovação da merge request.

Tipo de evento explicit
Desenvolvimento iniciado
Esta atividade indica o início do trabalho ativo de programação na issue. Em geral, ela é inferida a partir do primeiro commit enviado para uma branch associada à issue, já que o GitLab não tem um botão explícito para iniciar o desenvolvimento.
Por que isso importa

Identifica o início exato do trabalho de desenvolvimento que agrega valor, permitindo medir com precisão a etapa de programação e separá-la do tempo de planejamento ou de espera na fila.

Onde encontrar

O evento é inferido pela data e hora do primeiro commit em uma branch de funcionalidade vinculada à issue. Para isso, é necessário relacionar as issues às branches, geralmente por convenções de nomenclatura ou metadados.

Coleta

Encontre a data e hora do primeiro commit em uma branch associada ao ID da issue.

Tipo de evento inferred
Implantação iniciada
Representa o início do processo de liberação do código em um ambiente específico, como homologação ou produção. No GitLab, corresponde ao início de um job `deploy` em um pipeline de CI/CD.
Por que isso importa

Acompanhar o início da implantação ajuda a isolar a duração dessa etapa. Isso é fundamental para medir e otimizar o lead time de implantação.

Onde encontrar

O evento é obtido do campo started_at de um job de CI/CD configurado como job de implantação. Esse recurso faz parte da funcionalidade Environments and Deployments do GitLab.

Coleta

Use o campo started_at do registro do job de CI para uma tarefa de implantação.

Tipo de evento explicit
Issue atribuída
Representa a atribuição de uma issue a um desenvolvedor ou equipe específica, indicando que a responsabilidade pelo trabalho foi definida. O GitLab registra esse evento explicitamente sempre que o campo de responsável da issue é preenchido ou alterado.
Por que isso importa

Acompanhar as atribuições é fundamental para analisar a alocação de recursos, a carga de trabalho da equipe e os tempos de handoff. Isso ajuda a identificar atrasos entre a criação do trabalho e o momento em que alguém começa a executá-lo.

Onde encontrar

O evento é obtido nas notas do sistema do GitLab para a issue, que registram quando um responsável é adicionado ou alterado. A data e hora do evento ficam registradas na nota.

Coleta

Extraia das notas do sistema da issue os eventos de alteração de responsável.

Tipo de evento explicit
Issue encerrada
Representa o encerramento administrativo final do item de trabalho, geralmente depois que as alterações são implantadas e verificadas. O evento é registrado explicitamente quando alguém encerra a issue no GitLab.
Por que isso importa

O encerramento de uma issue costuma marcar o fim de todo o trabalho relacionado. Comparar esse momento com o da implantação pode revelar atrasos na validação pós-implantação ou em processos administrativos.

Onde encontrar

Este evento é registrado explicitamente a partir do campo closed_at da tabela issues ou da nota do sistema correspondente.

Coleta

Use o campo closed_at da issue.

Tipo de evento explicit
Pipeline com falha
Esta atividade ocorre quando uma execução de pipeline de CI/CD falha em qualquer etapa, como em um erro de build ou em um teste. O GitLab registra explicitamente o status final de cada pipeline, facilitando a identificação das falhas.
Por que isso importa

Falhas em pipelines são uma das principais causas de retrabalho. Analisar sua frequência, duração e causa ajuda a identificar problemas de qualidade, testes instáveis e gargalos no ciclo de feedback para os desenvolvedores.

Onde encontrar

A falha é identificada pelo status failed de um registro de pipeline na tabela ci_pipelines. O campo finished_at indica quando ela ocorreu.

Coleta

Filtre os registros de pipeline com status failed e use o campo finished_at.

Tipo de evento explicit
Pipeline iniciado
Representa o início de um pipeline automatizado de CI/CD, que normalmente executa builds, testes e verificações de segurança. Sempre que um pipeline é acionado, por exemplo, por um commit ou pela criação de uma MR, o GitLab cria explicitamente um registro com a data e hora de início.
Por que isso importa

Acompanhar as execuções dos pipelines é essencial para monitorar a saúde e a eficiência dos processos automatizados de teste e integração. Isso ajuda a identificar quanto tempo é gasto na validação automatizada.

Onde encontrar

O evento é obtido do campo created_at ou started_at do registro do pipeline na tabela ci_pipelines ou pela API de Pipelines.

Coleta

Use a data e hora do registro de execução do pipeline associado à branch da MR.

Tipo de evento explicit
Revisão de código iniciada
Marca o início da revisão por pares de uma merge request. O evento é inferido a partir da primeira ação relacionada à revisão, como o primeiro comentário ou tópico publicado por alguém que não seja o autor.
Por que isso importa

Medir o tempo entre a criação da MR e o início da revisão revela atrasos na fila. Reduzir esse tempo de espera é essencial para encurtar o ciclo geral de revisão de código.

Onde encontrar

O evento é inferido pela data e hora do primeiro comentário ou tópico de revisão na merge request feito por alguém que não seja o autor da MR. Esses dados estão disponíveis nas notas do sistema ou pela API de Notes.

Coleta

Encontre a data e hora do primeiro comentário na MR feito por alguém que não seja o autor.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do GitLab

Pronto para começar?

Use este Template para preparar seus dados e começar a otimizar o ciclo de vida do desenvolvimento de software. Comece hoje a transformar seu processo!

Melhore o ciclo de vida do desenvolvimento de software: comece a otimizar agora

Elimine gargalos no SDLC, reduza o tempo de ciclo em 30% e melhore a qualidade.

Começar o teste grátis

Não é necessário informar cartão de crédito. Comece a otimizar agora.