Pointer — página inicial do catálogo
Pré-requisitos · PR-DOR-01 · oferta PS-DOR-01

Pré-requisitos: Painel executivo de métricas DORA

Checklist de prontidão

Marcações ficam salvas somente neste navegador.

  • Reunião de prontidão
  • Reunião de prontidão
  • Cliente
  • Cliente
  • Cliente
  • Preflight automático

Este documento é enviado depois da escolha da oferta PS-DOR-01 — Painel executivo de métricas DORA. Ele lista as informações que o cliente devolve à Pointer, o token de leitura que o cliente cria e entrega por canal seguro e o checklist conferido antes da primeira coleta. O prazo de devolução é definido no kick-off.

  1. Escopos e fonte dos números
  2. O que o cliente informa e decide
  3. Dados publicados no painel
  4. Credenciais que o cliente entrega à Pointer
  5. Informações a enviar
  6. Checklist de prontidão

1. Escopos e fonte dos números

EscopoFonteToken exigido
Grupos (com subgrupos)API de métricas DORA do GitLab em GitLab Ultimate; cálculo da Pointer nas demais situaçõesread_api com papel Reporter no grupo (ou no grupo de topo)
ProjetosIdemread_api com papel Reporter no projeto (ou no grupo que o contém)
Instância inteiraCálculo da Pointer (a API do GitLab não tem métricas DORA por instância)read_api de usuário administrador ou auditor (GitLab self-managed ou GitLab Dedicated; não se aplica ao GitLab.com)
  • Um mesmo painel combina escopos dos três tipos; cada escopo mostra a fonte usada e o motivo.
  • Grupos e projetos são informados pelo caminho completo (por exemplo, sistemas/portal-servicos).

2. O que o cliente informa e decide

ItemEspecificaçãoObrigatório
IdentificaçãoNome do órgão ou da empresa (exibido no título do painel) e sigla.Sim
Instância GitLabURL no formato https:// seguido do host; oferta (GitLab self-managed, GitLab Dedicated ou GitLab.com) e assinatura (GitLab Premium ou GitLab Ultimate).Sim
EscoposInstância inteira e/ou caminhos completos dos grupos e dos projetos, com o nome a exibir.Sim (ao menos um)
Ambientes de produçãoTier dos ambientes do GitLab que contam como produção (padrão: production).Não
Período exibidoDe 1 a 24 meses (padrão: 12).Não
Periodicidade da coletaPadrão: semanal, segunda-feira às 07:00 (horário de Brasília).Não
DestinatáriosQuem recebe o link e a senha do painel.Sim
Acesso à instânciaInstância acessível pela internet a partir do GitLab.com, ou runner na rede do cliente com acesso de saída à instância e ao GitLab.com.Sim
Certificado da instânciaSe emitido por autoridade certificadora interna, o certificado da CA (arquivo PEM).Condicional: CA interna
Logo do clienteArquivo de imagem com autorização de uso, exibido no cabeçalho do painel.Não
  • Os números dependem de ambientes com tier de produção nos jobs de deploy e, para tempo de restauração e taxa de falha, de incidentes registrados no GitLab.

3. Dados publicados no painel

  • Por escopo: nome e caminho, fonte, métricas dos últimos 30 dias e dos 30 anteriores, série mensal, evolução entre coletas, projetos do escopo com ambiente de produção (caminho, link e nomes dos ambientes) e data da coleta.
  • Nenhum dado pessoal: a coleta registra caminhos e nomes de grupos e projetos e números agregados.
  • Tudo publicado cifrado (AES-256-GCM) e decifrado no navegador com a senha do painel.

4. Credenciais que o cliente entrega à Pointer

O cliente cria o token e o entrega por canal seguro combinado no kick-off; a Pointer o cadastra em variável de CI/CD protegida e mascarada do projeto do engajamento. O token não é enviado por e-mail, chat ou documento.

CredencialFinalidadePermissõesFormato e validadeObrigatório
Token de acesso de leitura da instância GitLabColeta das métricas pela API, somente leitura.Escopo read_api. Grupos e projetos: token de grupo com papel Reporter no grupo de topo dos escopos, ou token de usuário de serviço com papel Reporter nos escopos. Instância inteira: usuário administrador ou auditor. Token de acesso (texto)
Definida pelo cliente; renovação antes do vencimento combinada no kick-off; revogado no encerramento
Sim

5. Informações a enviar

Informações sem sigilo, devolvidas pelo cliente antes da reunião de prontidão. Os campos marcados como obrigatórios são conferidos pela validação automática do pipeline.

Identificação

InformaçãoExemploObrigatórioObservação
Nome do órgão ou da empresaTribunal ExemploSimExibido no título do painel.
SiglaTEXSimExibida no cabeçalho.

Instância

InformaçãoExemploObrigatórioObservação
URLhttps://gitlab.cliente.gov.brSimhttps:// seguido do host.
Oferta e assinaturaGitLab self-managed, GitLab UltimateSimDefine a fonte dos números de grupos e projetos.
AcessoInternetSimInternet ou runner na rede do cliente.

Escopos

InformaçãoExemploObrigatórioObservação
Instância inteiraNãoNãoExige token de administrador ou auditor.
Grupossistemas (Sistemas corporativos)Condicional: um escopo ao menosCaminho completo e nome a exibir.
Projetossistemas/portal-servicos (Portal de Serviços)Condicional: um escopo ao menosCaminho completo e nome a exibir.

Painel

InformaçãoExemploObrigatórioObservação
DestinatáriosDiretoria de TISimRecebem o link e a senha por canais separados.
Período exibido12 mesesNão1 a 24 meses.
Periodicidade da coletaSemanalNãoPadrão: segunda-feira às 07:00.

6. Checklist de prontidão

Itens conferidos antes da execução. "Preflight automático" indica verificação feita pelo pipeline contra o ambiente real; os demais são conferidos na reunião de prontidão ou pelo cliente.

☐ItemVerificado por
☐Escopos informados com o caminho completo de cada grupo e projeto.Reunião de prontidão
☐Token read_api entregue por canal seguro, com o papel exigido para os escopos e data de vencimento informada.Reunião de prontidão
☐Instância acessível pela internet ou runner com acesso à instância disponível.Cliente
☐Projetos dos escopos com jobs de deploy em ambientes com tier de produção.Cliente
☐Incidentes registrados no GitLab, para as métricas de estabilidade.Cliente
☐Configuração do painel validada no pipeline.Preflight automático