Seu Template de dados do ciclo de vida do desenvolvimento de software
Seu Template de dados do ciclo de vida do desenvolvimento de software
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração
Atributos do ciclo de vida do desenvolvimento de software
| 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
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 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
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
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 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
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
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 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
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 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
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
|
|||
Atividades do ciclo de vida do desenvolvimento de software
| 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
Coleta
Use o campo
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
Coleta
Use o campo
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
Coleta
Use o campo
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
Coleta
Use o campo
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
Coleta
Use o campo
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
Coleta
Use o campo
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
Coleta
Filtre os registros de pipeline com status
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
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
|
|||
Guias de extração
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.
Não é necessário informar cartão de crédito. Comece a otimizar agora.