Painel publicado no GitLab Pages com as quatro métricas DORA da instância GitLab do cliente — frequência de deploy, lead time de mudanças, tempo de restauração do serviço e taxa de falha de mudanças — nos escopos que o cliente escolhe: instância inteira, grupos específicos ou projetos específicos. Mostra a situação dos últimos 30 dias com a variação sobre os 30 dias anteriores, a série mensal, a evolução entre coletas e a origem de cada número. Diretoria e alta gestão acessam pelo navegador com uma senha, sem usuário no GitLab.
1. Para quem
- Diretoria, alta gestão e patrocinadores que acompanham a entrega de software das equipes na plataforma GitLab.
- Clientes com instância GitLab self-managed, GitLab Dedicated ou grupos no GitLab.com, nas assinaturas GitLab Premium ou GitLab Ultimate.
- Clientes que registram deployments em ambientes do GitLab (com tier de produção) e, para as métricas de estabilidade, incidentes no GitLab.
2. Onde executamos
O painel é publicado no GitLab Pages de um projeto do engajamento no GitLab.com da Pointer. A coleta lê a instância GitLab do cliente pela API, somente leitura, com um token de acesso de leitura fornecido pelo cliente; nada é instalado na instância. Instância sem acesso pela internet: a coleta roda num runner com acesso à rede do cliente.
3. Escopo do serviço
- Escopos escolhidos pelo cliente: instância inteira, grupos específicos (com subgrupos) e/ou projetos específicos, definidos na configuração versionada do engajamento e alterados por merge request.
- As quatro métricas DORA: frequência de deploy (deploys por dia), lead time de mudanças (mediana entre o merge e a chegada à produção), tempo de restauração do serviço (mediana do tempo de abertura dos incidentes) e taxa de falha de mudanças (incidentes ÷ deployments), com as definições da documentação do GitLab.
- Fonte de cada número sinalizada: API de métricas DORA do GitLab (recurso nativo do GitLab Ultimate) ou cálculo da Pointer com as mesmas definições, usado quando a API não está disponível (GitLab Premium) e no escopo instância inteira; o painel mostra a fonte e o motivo em cada escopo.
- Situação e evolução: últimos 30 dias com a variação sobre os 30 dias anteriores (melhora, piora ou estável, com seta e texto), série mensal de 1 a 24 meses (mês corrente marcado como em andamento) e evolução entre coletas.
- Origem dos dados: para cada escopo, a fonte, os ambientes considerados (tier), o período, os projetos do escopo e os que têm ambiente de produção, com links, e a data da coleta.
- Visões: painel do escopo, tabela de todos os escopos, comparação de até 5 escopos e glossário executivo, com tabela alternativa em cada gráfico.
- Coleta periódica: agendamento semanal (periodicidade ajustável) e coleta sob demanda; cada coleta fica registrada no repositório do engajamento e forma o histórico.
- Acesso por senha: dados publicados cifrados (AES-256-GCM) e decifrados no navegador com a senha do painel, entregue por canal separado do link.
4. Escopos e fontes
Disponível Ofertado nas condições deste documento.Sob consulta Escopo e condições definidos em proposta específica, com execução piloto.
| Escopo | Assinatura / oferta GitLab | Fonte dos números | Estado |
|---|---|---|---|
| Grupos e projetos | GitLab Ultimate (GitLab self-managed, GitLab Dedicated ou GitLab.com) | API de métricas DORA do GitLab (nativa) | Disponível |
| Grupos e projetos | GitLab Premium, ou quando a API nativa não responde | Cálculo da Pointer com as definições da documentação do GitLab | Disponível |
| Instância inteira | GitLab self-managed ou GitLab Dedicated, com token de administrador ou auditor | Cálculo da Pointer (a API do GitLab não tem métricas DORA por instância) | Sob consulta |
- Só contam deployments bem-sucedidos em ambientes do GitLab com o tier de produção (ou os tiers definidos na configuração); projetos sem esse ambiente não influenciam os números e aparecem na origem dos dados.
- Tempo de restauração e taxa de falha dependem de incidentes registrados no GitLab (itens do tipo incidente); sem incidentes registrados, esses indicadores ficam vazios.
- O painel não classifica o desempenho em níveis: mostra valores, tendência e origem.
- Escopos podem se sobrepor (um projeto pode estar num grupo e na instância); os valores de escopos diferentes não se somam.
5. Recursos configurados
● Nativo — recurso da plataforma GitLab◐ Requer configuração○ Integração externa — depende de serviço do cliente ou de terceiro
| Recurso | Classificação | Detalhe |
|---|---|---|
| API de métricas DORA | Nativo | Recurso nativo do GitLab Ultimate (grupos e projetos; papel Reporter ou superior). Nas demais situações, o cálculo da Pointer usa as APIs nativas de ambientes, deployments, merge requests e issues do tipo incidente. |
| Ambientes com tier de produção e incidentes | Requer configuração | Requer configuração nos projetos do cliente: jobs de deploy com ambiente do GitLab (tier production, por nome ou por configuração do job) e incidentes registrados no GitLab para as métricas de estabilidade. |
| Token de acesso de leitura do cliente | Requer configuração | Escopo read_api: token de grupo ou de usuário de serviço com papel Reporter nos escopos; para a instância inteira, de administrador ou auditor. Guardado em variável de CI/CD protegida e mascarada do projeto do engajamento. |
| GitLab Pages | Requer configuração | Recurso nativo. O pipeline publica o painel no GitLab Pages do projeto do engajamento; os dados são publicados cifrados. |
| Agendamento de pipeline | Requer configuração | Recurso nativo (pipeline schedules): coleta periódica sem intervenção. |
6. Ferramentas
Ferramenta Pointer
psctl
Valida a configuração, coleta as métricas por escopo (fonte nativa ou calculada), grava cada coleta e gera o painel cifrado.
Recurso nativo da plataforma GitLab
API REST do GitLab
Métricas DORA (Ultimate), grupos, projetos, ambientes, deployments, merge requests e incidentes, somente leitura.
Recurso nativo da plataforma GitLab
GitLab Pages
Publica o painel para acesso pelo navegador.
7. Como o pipeline Pointer executa
Cada merge request valida a configuração do painel. A coleta roda pelo agendamento (semanal, por padrão) ou sob demanda: lê a instância GitLab do cliente pela API, somente leitura, grava a coleta no repositório do engajamento e dispara a publicação do painel no GitLab Pages. Se algum escopo ficar sem dados, a coleta registra o motivo e o painel mostra o escopo como sem dados.
8. Metodologia
Assessment → Implantação → Otimização → Transferência de conhecimento.
Fase 1
Assessment
- Kick-off: escopos a acompanhar (instância, grupos, projetos), assinatura e oferta GitLab, destinatários do painel e periodicidade da coleta.
- Conferência nos projetos do cliente dos ambientes com tier de produção e do registro de incidentes no GitLab.
- Coleta das informações do documento de pré-requisitos PR-DOR-01 e do token de leitura, entregue por canal seguro.
Fase 2
Implantação
- Configuração do painel por merge request no repositório do engajamento, validada pelo pipeline.
- Cadastro do token em variável protegida e mascarada, geração da senha do painel e criação do agendamento da coleta.
- Primeira coleta e publicação do painel; conferência da fonte e da cobertura de cada escopo.
Fase 3
Otimização
- Ajuste de escopos, período exibido e periodicidade por merge request.
- Acompanhamento das coletas e da renovação do token antes do vencimento.
Fase 4
Transferência de conhecimento
- Apresentação do painel à diretoria: leitura das métricas, fontes, origem dos dados e limites.
- Entrega do link e da senha por canais separados; registro de destinatários e decisões no repositório do engajamento.
9. Entregáveis
| Entregável | Descrição | Formato |
|---|---|---|
| Painel de métricas DORA | Painel do escopo, todos os escopos, comparação e glossário, com a origem de cada número; acesso por senha. | Site (GitLab Pages, dados cifrados) |
| Histórico de coletas | Uma coleta por execução, com números agregados por escopo, sem dados pessoais. | Repositório do engajamento |
| Configuração do painel | Instância, escopos, fonte, ambientes e período, versionados e validados pelo pipeline. | Repositório do engajamento |
10. Premissas
- Os números dependem do uso de ambientes com tier de produção nos jobs de deploy e do registro de incidentes no GitLab; o painel mostra os projetos que entram em cada escopo.
- Em GitLab Ultimate, grupos e projetos usam a API de métricas DORA do GitLab; nas demais situações, o cálculo da Pointer, sinalizado no painel. Pequenas diferenças de arredondamento entre as fontes podem ocorrer.
- O token do cliente é de leitura (read_api), com a validade definida pelo cliente; a renovação antes do vencimento é combinada no kick-off.
- A senha do painel é entregue por canal separado do link; quem tem o link e a senha vê os dados.
- Instância sem acesso pela internet: runner com acesso de saída à instância, na rede do cliente.
Fora do escopo
- Mudança nos pipelines das aplicações do cliente para registrar ambientes e deployments (pode ser tratada em outra oferta).
- Classificação do desempenho em níveis e metas de melhoria (o painel mostra valores, tendência e origem).
- Dashboards nativos do GitLab (Value Streams Dashboard, analytics de CI/CD), que o cliente usa na própria instância.
- Métricas de outras ferramentas além da instância GitLab informada.
Responsabilidades do cliente
- Definir os escopos, os destinatários e a periodicidade.
- Fornecer o token de leitura (read_api) com o papel exigido e renová-lo antes do vencimento.
- Manter ambientes com tier de produção nos deploys e registrar os incidentes no GitLab.
- Instância sem acesso pela internet: runner com acesso de saída à instância.
- Guardar a senha do painel e controlar a quem entrega o link.
Detalhamento no documento de pré-requisitos PR-DOR-01, enviado após a escolha do serviço.
11. Duração
A duração depende da quantidade de escopos, do acesso à instância (internet ou runner na rede do cliente) e da devolução do token e das informações do documento de pré-requisitos. O prazo do engajamento e o período de coletas são definidos na proposta.
12. Documentos relacionados
- PS-00 · Catálogo de Serviços
- PR-DOR-01 · Pré-requisitos: Painel executivo de métricas DORA
- PS-AVA-01 · Avaliação de maturidade DevSecOps e Customer Success Plan
- PS-AVA-02 · Levantamento da plataforma
- PS-OPS-01 · Operação assistida
- PS-IMP-01 · Implantação da plataforma GitLab em servidores Linux
- PS-IMP-02 · Implantação da plataforma GitLab em Kubernetes
- PS-MIG-01 · Migração GitLab para GitLab self-managed