Template de dados para o Ciclo de Vida de Desenvolvimento de Software (SDLC)

GitLab
Template de dados para o Ciclo de Vida de Desenvolvimento de Software (SDLC)

Template de dados para o Ciclo de Vida de Desenvolvimento de Software (SDLC)

Este template guia você pelos dados essenciais para analisar seu SDLC. Ele define os atributos e atividades chave e ensina como extraí-los do GitLab, garantindo uma preparação de dados segura para o Process Mining.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Orientação para Extração
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos do Ciclo de Vida de Desenvolvimento

Estes são os campos recomendados para o seu event log para garantir uma análise completa do SDLC.
3 Obrigatório 5 Recomendado 13 Opcional
Nome Descrição
Atividade
Activity
O nome da etapa ou evento, como 'Issue Criada' ou 'Merge Request Mesclado'.
Descrição

O atributo Atividade registra eventos reais do item (criação de issue, push, falha de pipeline, aprovação de MR). No GitLab, esses dados vêm de diferentes ações e campos de tempo.

Ele é a base para montar o mapa de processo, ver o workflow e analisar sequências. Serve para achar desvios, gargalos e os caminhos mais comuns.

Por que é importante

Define as etapas no mapa de processo, permitindo a visualização e análise do workflow de desenvolvimento de ponta a ponta.

Onde obter

Derivado de tipos de eventos e mudanças de estado no fluxo do GitLab, ou interpretando campos de timestamp como 'created_at', 'merged_at' e 'closed_at' em Issues e Merge Requests.

Exemplos
Problema CriadoDesenvolvimento IniciadoMerge Request mescladoPipeline falhouImplantado em Produção
Hora de Início
StartTime
O timestamp que indica quando uma atividade ou evento começou.
Descrição

O StartTime registra exatamente quando uma atividade ocorreu no GitLab via campos de timestamp. Ex: para 'Issue Created', usa-se o created_at; para 'Merge Request Merged', o merged_at.

Este é o dado temporal base para o Process Mining. Ele serve para ordenar eventos, calcular durações, medir o tempo de ciclo e analisar a performance do processo ao longo do tempo.

Por que é importante

Oferece a ordem cronológica dos eventos, base para calcular métricas de tempo e entender o fluxo.

Onde obter

Extraído de vários campos de timestamp no GitLab, como 'created_at', 'updated_at', 'closed_at' em issues e 'merged_at' em merge requests.

Exemplos
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Item de Desenvolvimento
DevelopmentItem
O ID único da tarefa (feature, bug ou task), usado como identificador principal do caso.
Descrição

O Item de Desenvolvimento é a unidade rastreável no SDLC (no GitLab, o IID da Issue). Ele une todas as ações, do início ao deploy, em um caso único.

Isso permite medir o tempo de ciclo total, achar gargalos e ver se o processo é seguido à risca, revelando a eficiência da entrega.

Por que é importante

ID do caso: essencial para unir todos os eventos e rastrear o ciclo de vida completo de uma tarefa.

Onde obter

Geralmente o IID da Issue do GitLab (campo 'iid' na resposta da API).

Exemplos
1024512PRJ-2345
End Time
EndTime
O timestamp que indica quando uma atividade ou evento foi concluído.
Descrição

O EndTime (Horário de Término) registra a data e hora precisas em que uma atividade foi concluída. Para eventos atômicos no GitLab, como "Issue Criada", o EndTime é igual ao StartTime. Para atividades com duração, como "Revisão de Código", representa o momento da conclusão (ex: quando a aprovação final é dada).

Este atributo é essencial para calcular a duração exata de cada atividade (Tempo de Processamento). Ele ajuda na análise detalhada de gargalos, diferenciando o tempo de trabalho ativo do tempo de espera entre as tarefas.

Por que é importante

Permite o cálculo de durações precisas das atividades (tempos de processamento), fundamental para identificar etapas ineficientes.

Onde obter

Para eventos atômicos, este valor é igual ao StartTime. Para atividades com duração, ele deve ser derivado localizando o evento de conclusão correspondente nos dados.

Exemplos
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Gravidade
Severity
O nível de severidade, geralmente usado para bugs ou incidentes.
Descrição

A severidade indica o impacto de um bug (de crítico a menor). Como o GitLab não tem esse campo nativo, costuma-se usar labels (ex: 'severity::1').

Este atributo é vital para o Dashboard de 'Tendências de Escalonamento' e seu KPI. Analisar mudanças na severidade revela problemas subestimados ou falhas no processo que agravam a situação.

Por que é importante

Auxilia na priorização e na análise de agilidade em itens de alta severidade. O acompanhamento de mudanças alimenta o KPI de 'Frequência de Escalonamento de Severidade'.

Onde obter

Derivado das 'labels' aplicadas a uma Issue do GitLab. É necessário um mapeamento para interpretar labels como 'S1', 'S2' como níveis de gravidade.

Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
Nome do projeto
ProjectName
O nome do projeto no GitLab onde o item está.
Descrição

Identifica o repositório ou projeto. No GitLab, toda issue/MR pertence a um projeto.

Isso permite comparar a performance de diferentes serviços ou produtos, vendo quais projetos têm um SDLC mais saudável, além de facilitar filtros nos dashboards.

Por que é importante

Permite que a análise do processo seja segmentada por produto, aplicação ou componente, facilitando esforços de melhoria direcionados.

Onde obter

Obtido nos campos 'name' ou 'path_with_namespace' da API de Projetos, via 'project_id'.

Exemplos
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Responsável
Assignee
O usuário que era o responsável pela issue ou MR no momento do evento.
Descrição

O Responsável (Assignee) é quem cuida do item em certa fase. No GitLab, fica nos campos assignee ou assignees.

Analisar por responsável é crucial para o Dashboard de 'Carga de Trabalho'. Ajuda a equilibrar recursos, achar times sobrecarregados e entender as passagens de bastão (handoffs).

Por que é importante

Registra quem executou o trabalho, permitindo a análise da carga de trabalho, eficiência na alocação de recursos e a identificação de atrasos causados por transferências entre equipes.

Onde obter

Obtido nos campos 'assignee.username' ou 'assignees' da API de Issues e Merge Requests do GitLab.

Exemplos
jdoeasmithr.williams
Tipo do Item de Dev
DevelopmentItemType
Classificação do item: 'Feature', 'Bug', 'Tarefa' ou 'Manutenção'.
Descrição

Categoriza o trabalho via labels (ex: 'Feature', 'Bug', 'Dívida Técnica').

Isso permite comparar o fluxo de cada tipo: bugs são resolvidos mais rápido que novas funções? Dívidas técnicas têm um processo de revisão diferente?

Por que é importante

Segmentar o processo por tipo de trabalho ajuda a ver quais categorias sofrem mais com atrasos, retrabalho ou desvios.

Onde obter

Geralmente derivado das 'labels' aplicadas a uma Issue do GitLab. É necessária uma lógica de mapeamento para converter labels específicas em tipos padronizados.

Exemplos
Funcionalidade (Feature)BugTarefaDívida técnica
Branch de destino
TargetBranch
O nome da branch para onde o código será mesclado (merge request).
Descrição

A Target Branch é o destino das mudanças (ex: 'main', 'develop'). É um dado chave do Merge Request.

Analisar por branch revela como o processo muda conforme o destino: merges na 'main' podem ter aprovações mais lentas e rigorosas que em feature branches. Ajuda também a isolar o que é deploy real em produção.

Por que é importante

Ajuda a diferenciar diversos workflows de desenvolvimento e release, já que os processos mudam bastante dependendo da branch de destino.

Onde obter

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

Exemplos
maindeveloprelease/v2.1.0hotfix/user-auth-bug
É Retrabalho
IsRework
Um indicador booleano que sinaliza se uma atividade faz parte de um loop de retrabalho.
Descrição

Sinaliza retrocessos, como voltar para desenvolvimento após iniciar os testes. A lógica detecta sequências como 'Development Started' vindo após 'Pipeline Failed'.

Alimenta o Dashboard de 'Análise de Retrabalho' e o KPI de 'Taxa de Retrabalho'. Permite medir e entender a frequência e o impacto do retrabalho nos prazos.

Por que é importante

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

Onde obter

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

Exemplos
verdadeirofalse
Nome da Equipe
TeamName
A equipe de desenvolvimento ligada ao projeto ou responsável.
Descrição

Nome da Equipe indica a squad responsável pelo item. Geralmente não é nativo do GitLab, sendo extraído via nomes de projetos, grupos ou tabelas externas de mapeamento.

Este dado permite analisar a performance por equipe, comparar eficiência, carga de trabalho e conformidade, alimentando dashboards como a 'Análise de Gargalos por Estágio' sob a ótica de times.

Por que é importante

Permite a análise de desempenho e a comparação de processos entre diferentes equipes, ajudando a identificar gargalos específicos ou melhores práticas de cada time.

Onde obter

Geralmente obtido mapeando o nome do projeto ou o responsável para uma estrutura de equipe externa ou via hierarquia de grupos do GitLab.

Exemplos
Frontend-AlphaServiços-BackendPlatform-Infra
Sistema de Origem
SourceSystem
Identifica o sistema de origem dos dados.
Descrição

Indica a fonte dos dados (neste caso, 'GitLab').

Crucial se você combina dados de vários sistemas (ex: Jira para planos e GitLab para execução). Facilita o filtro, a segmentação e mantém o histórico de origem.

Por que é importante

Garante clareza sobre a origem dos dados, o que é fundamental para a governança de dados e integração de múltiplos sistemas corporativos.

Onde obter

Valor fixo 'GitLab', inserido na etapa de transformação dos dados.

Exemplos
GitLab
Status do Item de Dev
DevelopmentItemStatus
O estado do item no momento do evento: 'Open', 'In Progress' ou 'Closed'.
Descrição

Estado da Issue no GitLab (state: 'opened' ou 'closed'). Detalhes maiores vêm de labels (ex: 'Status::In-Dev').

Monitorar as mudanças é vital para entender o ciclo. Ajuda a ver quanto tempo as tarefas param em cada fase e permite filtrar trabalhos ativos no dashboard de 'Cycle Time'.

Por que é importante

Fornece um panorama do estado do caso, permitindo analisar o tempo gasto em cada fase e filtrar o que está em andamento ou concluído.

Onde obter

O status principal vem do campo 'state' ('opened', 'closed'). Status mais detalhados costumam vir das labels.

Exemplos
openedfechadoEm ProgressoEm Revisão
Status do Merge Request
MergeRequestStatus
O status do merge request: 'Opened', 'Merged' ou 'Closed'.
Descrição

Registra o estado do MR ('opened', 'closed', 'merged', 'locked'). É diferente do status geral do item.

Monitorar isso é vital para analisar a fase de integração e alimenta Dashboards de 'Cycle Time de Revisão', mostrando atrasos entre criação, aprovação e mesclagem.

Por que é importante

Dá visibilidade à revisão e mesclagem de código, que costumam ser gargalos críticos no SDLC.

Onde obter

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

Exemplos
openedmergedfechadolocked
Status do pipeline
PipelineStatus
O status da rodada do pipeline: 'Success', 'Failed' ou 'Running'.
Descrição

Indica o resultado do pipeline ('success', 'failed', etc.).

Fundamental para a 'Análise de Retrabalho'. Falhas constantes atrasam o time; entender onde elas ocorrem ajuda a melhorar a eficiência e a qualidade do código.

Por que é importante

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

Onde obter

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

Exemplos
successfalhourunningcancelado
Tempo de Ciclo
CycleTime
O tempo total entre o início e a conclusão do item.
Descrição

O Tempo de Ciclo (Cycle Time) é uma métrica calculada que mede a duração total de um caso. Geralmente é a diferença de tempo entre o primeiro evento (ex: "Issue Criada") e o último (ex: "Implantado em Produção") para um Item de Desenvolvimento.

Este é o principal KPI para medir a eficiência global do processo. É a métrica central em dashboards como "Tempo de Ciclo SDLC Ponta a Ponta", servindo para monitorar melhorias e identificar casos muito longos que podem indicar falhas sistêmicas.

Por que é importante

KPI central de Process Mining que mede a eficiência total do ciclo de desenvolvimento.

Onde obter

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

Exemplos
10 days 4 hours23 horas e 15 minutos35 dias
Tempo de Espera em Handoff
HandoffWaitTime
Tempo de inatividade calculado entre duas atividades consecutivas realizadas por responsáveis diferentes.
Descrição

Mede o intervalo entre atividades quando o responsável muda (ex: fim do dev até o início da revisão).

Dado principal do KPI 'Tempo Médio de Espera no Handoff'. Expõe falhas de comunicação e alocação, focando em atrasos onde ninguém está agindo.

Por que é importante

Quantifica o tempo ocioso em passagens de bastão (handoffs) entre pessoas ou times, revelando atrasos e falhas de comunicação.

Onde obter

Calculado pela ferramenta de Process Mining. Requer a análise de eventos consecutivos em um caso, verificando se o Responsável (Assignee) mudou e calculando a diferença de tempo.

Exemplos
1 dia e 2 horas15 minutos8 horas
Tempo de Processamento
ProcessingTime
A duração de uma única atividade, calculada como a diferença entre o horário de término e de início.
Descrição

O tempo de processamento mede o trabalho ativo em uma atividade, diferindo do tempo de espera entre elas. É o cálculo de EndTime menos StartTime de um evento. Para eventos instantâneos, o valor é zero.

Essa métrica é vital para analisar gargalos em estágios específicos. Ao somar os tempos de processamento de um estágio, como Revisão de Código, os analistas descobrem quanto tempo é realmente dedicado à tarefa, expondo etapas ineficientes.

Por que é importante

Mede a duração de cada atividade, ajudando a separar o tempo de trabalho ativo do tempo de espera para uma análise de gargalos precisa.

Onde obter

Calculado pela ferramenta de Process Mining como a diferença entre o Horário de Término (EndTime) e o Horário de Início (StartTime) de uma atividade.

Exemplos
2 horas e 30 minutos0 minutos3 dias e 8 horas
Título do Milestone
MilestoneTitle
O nome do milestone ou sprint onde o item está alocado.
Descrição

Um Milestone (Marco) no GitLab é usado para rastrear o trabalho em relação a um objetivo específico ou período (timebox), como um sprint ou uma versão de lançamento. Este atributo captura o nome ou título desse marco.

Ele permite analisar o desempenho do processo no contexto de sprints ou períodos de planejamento específicos. Pode ser usado para verificar se os tempos de ciclo estão melhorando de um sprint para outro ou para filtrar a visão do processo e mostrar apenas o trabalho relacionado a um lançamento futuro.

Por que é importante

Conecta o desenvolvimento aos ciclos de planejamento (sprints ou releases), permitindo analisar o desempenho em relação aos prazos planejados.

Onde obter

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

Exemplos
Release Q4-2023Sprint 23.11Fase 1: MVP
Última Atualização de Dados
LastDataUpdate
O carimbo de data/hora que indica quando os dados para este evento foram atualizados pela última vez no sistema de origem.
Descrição

Data e hora da última extração ou atualização dos dados, não do evento em si.

Essencial para saber se os dados estão atualizados. Isso dá segurança ao usuário de que os KPIs refletem o cenário atual e mostra o intervalo entre o GitLab e a análise.

Por que é importante

Garante transparência sobre a atualização dos dados, para que os usuários saibam quão recente é a análise.

Onde obter

Timestamp gerado pela ferramenta de extração ou ETL na hora da atualização dos dados.

Exemplos
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Versão da release
ReleaseVersion
A tag da versão de software (planejada ou real) usada no deploy.
Descrição

Identifica a release do software (via Milestone ou Tag).

Vital para o dashboard de 'Adesão ao Cronograma'. Ao comparar o deploy real com a data planejada, a empresa mede sua pontualidade e entende os motivos de possíveis atrasos.

Por que é importante

Conecta itens de desenvolvimento a um release específico, o que é fundamental para rastrear o progresso e o cumprimento do cronograma de lançamento.

Onde obter

Pode vir do GitLab Releases, do nome de uma git tag ou de um milestone de planejamento.

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

Atividades do Ciclo de Vida de Desenvolvimento

Estas são as principais etapas do processo e marcos a serem capturados no seu log de eventos para uma descoberta precisa de processos e identificação de gargalos.
4 Recomendado 8 Opcional
Atividade Descrição
Implantado em Produção
Implantação real em produção para o usuário final. Ocorre quando o job de 'deploy to production' do pipeline termina com sucesso.
Por que é importante

Evento final: entrega de valor. Essencial para medir o tempo total do SDLC e a frequência de lançamentos.

Onde obter

Capturado do timestamp 'finished_at' de um job de CI/CD bem-sucedido designado para deploy em produção. O recurso de Ambientes do GitLab rastreia isso explicitamente.

Captura

Use o registro de data e hora 'finished_at' do job de CI de implantação em produção bem-sucedido.

Tipo de evento explicit
Merge Request criado
Indica que o desenvolvimento inicial está concluído e o código está pronto para revisão e integração. Este é um evento central explícito no workflow do GitLab, capturado quando um novo merge request (MR) é aberto.
Por que é importante

Marco crítico: passagem de desenvolvimento para revisão/teste. É o ponto de partida para analisar o ciclo de revisão e o pipeline.

Onde obter

Evento explícito do timestamp 'created_at' na tabela de merge requests ou via API.

Captura

Use o registro de data e hora 'created_at' do merge request.

Tipo de evento explicit
Merge Request mesclado
Fim da revisão e integração. Evento explícito quando o MR é mesclado na branch de destino.
Por que é importante

Marco importante: desenvolvimento e revisão concluídos. Finaliza a métrica de cycle time e inicia o lead time de deploy.

Onde obter

Evento explícito do timestamp 'merged_at' na tabela de merge requests.

Captura

Use o registro de data e hora 'merged_at' do merge request.

Tipo de evento explicit
Problema Criado
Início do ciclo: criação de uma nova tarefa (feature, bug ou task). Registrado no GitLab com o timestamp de criação da issue.
Por que é importante

Evento inicial: permite ver o tempo total desde a criação da issue até o deploy (cycle time do SDLC).

Onde obter

Evento explícito do timestamp 'created_at' na tabela de issues ou via API.

Captura

Use o registro de data e hora 'created_at' da issue.

Tipo de evento explicit
Aprovação Adicionada
Representa a aprovação formal das mudanças de código por um revisor. Evento capturado explicitamente quando o botão 'Approve' é clicado no GitLab.
Por que é importante

As aprovações são etapas críticas de qualidade (quality gates). Rastreá-las ajuda a analisar o tempo necessário para obter as validações exigidas e garante a conformidade com as políticas de revisão.

Onde obter

Capturado de eventos de aprovação de merge request. Estão disponíveis via API de Aprovações ou no histórico do MR.

Captura

Use o registro de data e hora do log de eventos de aprovação do merge request.

Tipo de evento explicit
Desenvolvimento Iniciado
Início da codificação ativa. Como não há um botão 'iniciar' no GitLab, identificamos pelo primeiro commit enviado para a branch vinculada.
Por que é importante

Marca o início exato do trabalho de desenvolvimento que gera valor, permitindo medir a fase de codificação pura e separá-la do planejamento ou espera.

Onde obter

Identificado ao localizar o timestamp do primeiro commit em uma feature branch vinculada à issue. Exige que issues e branches estejam conectados, geralmente por convenção de nomes ou metadados.

Captura

Localize o timestamp do primeiro commit em uma branch vinculada ao ID do problema (issue ID).

Tipo de evento inferred
Implantação Iniciada
Marca o início da implantação do código em ambientes como staging ou produção. No GitLab, equivale ao início de um job de 'deploy' no pipeline.
Por que é importante

Marcar o início do deploy ajuda a isolar quanto tempo essa fase leva, sendo vital para otimizar o lead time de entrega.

Onde obter

Capturado do timestamp 'started_at' de um job de CI/CD configurado como job de implantação. Faz parte do recurso de Ambientes e Implantações do GitLab.

Captura

Use o registro de data e hora 'started_at' do log do job de CI para uma tarefa de implantação.

Tipo de evento explicit
Pipeline falhou
Falha no pipeline (erro de build, teste, etc.). O GitLab salva o status final de cada rodada, facilitando a detecção.
Por que é importante

Falhas no pipeline são grandes causas de retrabalho. Analisar sua frequência e motivos ajuda a detectar problemas de qualidade, testes instáveis e gargalos no feedback para o time.

Onde obter

Identificado pelo status 'failed' em um registro de pipeline na tabela 'ci_pipelines'. O timestamp 'finished_at' indica quando a falha ocorreu.

Captura

Filtre registros de pipeline com o status 'failed' e utilize o timestamp 'finished_at'.

Tipo de evento explicit
Pipeline iniciado
Início de um pipeline automatizado de CI/CD (builds, testes, etc.). O GitLab gera um registro com timestamp toda vez que o pipeline é disparado por um commit ou MR.
Por que é importante

Acompanhar pipelines é essencial para ver a saúde dos testes e integração. Mostra quanto tempo se gasta em validações automáticas.

Onde obter

Capturado do timestamp 'created_at' ou 'started_at' de um registro de pipeline na tabela 'ci_pipelines' ou via API de Pipelines.

Captura

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

Tipo de evento explicit
Problema Atribuído
Representa a entrega de uma issue a um desenvolvedor ou time. É um evento explícito registrado sempre que o campo de responsável (assignee) é preenchido ou alterado.
Por que é importante

Monitorar atribuições é vital para gerir recursos e carga de trabalho. Ajuda a ver o tempo que uma tarefa leva para ser iniciada após criada.

Onde obter

Capturado das notas de sistema do GitLab para a issue, que registram quando um responsável (assignee) é adicionado ou alterado. O timestamp do evento fica registrado na nota.

Captura

Extraia eventos de "responsável alterado" das notas de sistema da issue.

Tipo de evento explicit
Problema Encerrado
Representa o encerramento administrativo do item, após deploy e verificação. Capturado quando a issue é fechada no GitLab.
Por que é importante

Fechar uma issue geralmente marca o fim de todo o trabalho relacionado. Comparar isso com o tempo de deploy pode revelar atrasos na validação pós-implantação ou processos administrativos.

Onde obter

Evento explícito do timestamp 'closed_at' na tabela de issues ou de notas do sistema.

Captura

Use o registro de data e hora 'closed_at' da issue.

Tipo de evento explicit
Revisão de Código Iniciada
Marca o início da revisão por pares de um merge request. Este evento é identificado pela primeira ação de revisão, como o primeiro comentário feito por terceiros.
Por que é importante

Medir o tempo entre a criação do MR e o início da revisão evidencia atrasos em fila. Reduzir essa espera é vital para agilizar o ciclo total de revisão.

Onde obter

Identificado pelo timestamp do primeiro comentário ou thread de revisão no merge request feito por alguém que não seja o autor. Disponível via system notes ou Notes API.

Captura

Encontre o timestamp do primeiro comentário de usuário em um MR que não tenha sido feito pelo autor.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do GitLab