O levantamento lê por API, somente leitura, a plataforma atual do cliente (GitLab, GitHub, Bitbucket, Azure DevOps ou AWS CodeCommit) e produz o inventário, 38 métricas de base, as ondas sugeridas e a estimativa de esforço da migração para uma instância GitLab de destino. Coletas repetidas formam uma série histórica e o comparativo das métricas entre as fases inicial e final. Os resultados ficam no mesmo site cifrado da avaliação e em um PDF oficial.
1. Para quem
- Organizações que planejam migrar repositórios e projetos de GitLab, GitHub, Bitbucket, Azure DevOps ou AWS CodeCommit para uma instância GitLab de destino e precisam de inventário, ondas e esforço calculados a partir de dados medidos.
- Organizações que precisam de linha de base medida por API para os KPIs do Customer Success Plan e de evidências medidas ao lado da autoavaliação do Teste de Maturidade (PS-AVA-01).
- Organizações que querem acompanhar indicadores de uso da plataforma entre o início e o fim de um ciclo de adoção.
2. Onde executamos
A coleta roda em um runner com acesso HTTPS à API da origem: os runners da instância quando a origem é acessível pela internet, ou um runner do projeto do engajamento na rede do cliente quando a origem é interna. Origem que nenhum runner alcança é coletada numa máquina da rede do cliente (coleta externa) e o resultado é registrado no projeto do engajamento. Os resultados são publicados no site do engajamento (GitLab Pages), no GitLab.com da Pointer.
3. Escopo do serviço
- Origens: GitLab (GitLab.com: grupo ou projeto; GitLab self-managed: instância, grupo ou projeto), GitHub (organização, usuário ou repositório; GitHub Enterprise Server por instância), Bitbucket Cloud (workspace, projeto ou repositório), Bitbucket Server/Data Center (instância, projeto ou repositório), Azure DevOps (organização, projeto ou repositório) e AWS CodeCommit (região ou repositório). Uma ou mais origens por engajamento.
- Inventário: volume por tipo (repositórios, LFS, wiki, uploads, registry, pacotes e artefatos), atividade, faixas de tamanho, maiores projetos, plataforma de pipeline na origem (GitHub Actions, Jenkins, Azure Pipelines, Bitbucket Pipelines, Bamboo ou CircleCI, que exigem conversão para GitLab CI/CD) e dependências entre projetos (include, trigger e needs com projeto).
- O que migra e o que exige ação: tabela com o tratamento de cada item no pipeline de migração Pointer: migrado pelo método oficial, recriado após a importação, imagens de contêiner copiadas, reconfiguração manual ou não migrado.
- Alertas: limites do Direct Transfer na instância de destino (padrões configuráveis: relação de até 5 GiB baixada da origem e arquivo descompactado de até 25 GiB), compatibilidade de versões e projetos acima dos limites.
- Ondas, duração e esforço: simulador com onda piloto, projetos inativos em onda própria, provedores de dependência primeiro e limites por janela (horas, GB e projetos); duração por onda, rodadas do pipeline de migração, horas Pointer por fase, horas do cliente (infraestrutura e desenvolvimento) e calendário. As ondas são exportadas em YAML e em planilha CSV para o engajamento de migração.
- 38 métricas de base: cada uma com numerador, denominador e período: adoção de CI, sucesso, duração e espera na fila de pipelines, reuso por include e por componentes do CI/CD Catalog, relatórios de teste e cobertura, merge trains, branch padrão protegida, merge condicionado a pipeline, regras de aprovação, CODEOWNERS, merge requests e issues por semana, tempo até o merge, deploys e falhas em produção, review apps, SAST, detecção de segredos, SCA, verificação de contêiner, DAST, frameworks de conformidade, 2FA, uso de registry e de pacotes, runners online e as 4 métricas DORA nativas da plataforma GitLab.
- Ligação com a avaliação: as métricas aparecem como evidências medidas em cada domínio do Teste de Maturidade, e um KPI do Customer Success Plan pode apontar para uma métrica, que preenche a linha de base e o resultado.
- Série histórica e comparativo por fase: coletas repetidas (manuais ou agendadas, por exemplo semanais) formam a série de cada indicador; o comparativo usa a coleta de referência da fase inicial e a da fase final e classifica cada variação como favorável, desfavorável ou estável conforme o sentido do indicador.
- Coleta resiliente: cada origem é independente; a falha de uma não impede as demais, e o que foi coletado é gravado e publicado.
4. Origens do levantamento
Disponível Ofertado nas condições deste documento.Sob consulta Escopo e condições definidos em proposta específica, com execução piloto.
| Origem | Escopos | Credencial somente leitura | Estado |
|---|---|---|---|
| GitLab.com | Grupo, projeto | Personal access token com escopo read_api; papel Reporter (Maintainer para variáveis, webhooks, espelhos, agendamentos e triggers) | Disponível |
| GitLab self-managed | Instância, grupo, projeto | Personal access token com escopo read_api; instância: usuário administrador; grupo e projeto: papel Reporter (Maintainer para variáveis, webhooks, espelhos, agendamentos e triggers) | Disponível |
| GitHub.com | Organização, usuário, repositório | Token de leitura; read:org para agrupar por time e read:packages para contar pacotes | Disponível |
| GitHub Enterprise Server | Instância, organização, usuário, repositório | Token de leitura; instância exige token de administrador | Sob consulta |
| Azure DevOps Services | Organização, projeto, repositório | Personal access token com leitura de código e build; Member Entitlement Management para contar usuários | Disponível |
| Azure DevOps Server | Coleção, projeto, repositório | Personal access token com leitura de código e build | Sob consulta |
| Bitbucket Cloud | Workspace, projeto, repositório | E-mail da conta Atlassian e API token | Disponível |
| Bitbucket Server/Data Center | Instância, projeto, repositório | Token HTTP de acesso | Sob consulta |
| AWS CodeCommit | Região, repositório | Access key ID e secret access key com codecommit:List, codecommit:Get e codecommit:BatchGet* | Disponível |
- Todos os escopos de uma mesma origem usam o mesmo coletor.
- Sob consulta: GitHub Enterprise Server, Azure DevOps Server e Bitbucket Server/Data Center; escopo e condições definidos em proposta específica, com execução piloto.
- Origem GitLab self-managed no escopo instância: token de usuário administrador; a coleta lê também usuários, runners e configurações da instância.
- A API do AWS CodeCommit não informa o tamanho dos repositórios: o levantamento registra quantidade, branches, pull requests e atividade.
- No Bitbucket Server/Data Center, o tamanho dos repositórios vem de um endpoint da interface web, não documentado na API REST, que pode faltar em algumas versões.
- Parte das métricas depende da origem: as métricas DORA nativas, a espera na fila e o merge condicionado a pipeline são lidos só de origem GitLab.
- O detalhe do credenciamento de cada origem está no documento de pré-requisitos PR-AVA-02.
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 REST da plataforma GitLab (origem GitLab) | Nativo | Leitura com token de escopo read_api. Métricas DORA, usuários, runners e configurações lidos quando a API da origem os entrega ao token; erro da API vira aviso e o campo fica em branco. |
| APIs de GitHub, Bitbucket, Azure DevOps e AWS CodeCommit | Integração externa | APIs das plataformas de origem, lidas com a credencial somente leitura do cliente, com retentativa e respeito aos limites de requisição da origem. |
| Agendamento de pipeline | Requer configuração | Coleta periódica em agendamento cuja descrição contém 'levantamento', sem variáveis de pipeline (bloqueadas no projeto do engajamento). |
| GitLab Pages | Requer configuração | Mesmo site cifrado da avaliação: abas Métricas da plataforma, Inventário e migração e Comparativo. |
6. Ferramentas
Ferramenta Pointer
psctl (coletores do levantamento)
Coletores por API sem SDK de terceiros (CodeCommit com assinatura SigV4 própria), consolidação do inventário e das métricas, modelo de ondas e esforço, publicação no site e PDF.
Recurso nativo da plataforma GitLab
GitLab Pages
Publica as abas do levantamento no site exclusivo do engajamento.
APIs oficiais de GitLab, GitHub, Bitbucket Cloud (API 2.0), Bitbucket Server/Data Center (REST 1.0), Azure DevOps e AWS CodeCommit
APIs das plataformas de origem
Fonte única dos dados coletados, lidos somente com operações de consulta.
7. Como o pipeline Pointer executa
Cada merge request valida a configuração do levantamento junto com a da avaliação. A coleta por API, manual ou agendada, grava o resultado no repositório do engajamento e dispara a republicação do site com as abas do levantamento. O PDF do levantamento é gerado sob demanda.
8. Metodologia
Assessment → Implantação → Otimização → Transferência de conhecimento.
Fase 1
Assessment
- Definição das origens, dos escopos, da janela das métricas e das exclusões.
- Emissão, pelo cliente, das credenciais somente leitura de cada origem e cadastro como variável protegida no projeto do engajamento.
- Definição do acesso de rede: runners da instância, runner do engajamento na rede do cliente ou coleta externa.
- Configuração do levantamento revisada por merge request e validada pelo pipeline.
Fase 2
Implantação
- Coleta por API de cada origem e gravação do resultado no repositório do engajamento, sem dados pessoais.
- Publicação das abas Métricas da plataforma e Inventário e migração no site cifrado.
- Revisão dos avisos de permissão da coleta (campos sem contagem).
Fase 3
Otimização
- Conferência do inventário com o cliente: projetos inativos, exclusões, dependências e itens de ação manual.
- Revisão das premissas do modelo de esforço no simulador e das ondas sugeridas.
- Coletas agendadas (por exemplo, semanais) até o fim da fase final, para a série histórica e o comparativo.
Fase 4
Transferência de conhecimento
- PDF do levantamento com todas as origens coletadas.
- Exportação das ondas para o engajamento de migração (YAML e planilha CSV).
- Encerramento: agendamento removido e credenciais revogadas pelo cliente.
9. Entregáveis
| Entregável | Descrição | Formato |
|---|---|---|
| Métricas da plataforma | 38 indicadores com numerador, denominador e período, DORA, usuários, runners e série histórica. | Site (aba no site cifrado) |
| Inventário e migração | Volume, atividade, maiores projetos, pipelines na origem, dependências, o que migra e o que exige ação, alertas e, depois da apresentação da proposta, simulador de ondas, duração e horas por equipe. | Site (aba no site cifrado) |
| Comparativo das métricas por fase | Coleta de referência inicial × final, variação favorável, desfavorável ou estável por indicador e série histórica de todas as coletas. | Site (aba Comparativo) e seção no PDF do Teste de Maturidade |
| Levantamento da Plataforma | Relatório com todas as origens coletadas. | PDF A4 |
| Ondas exportadas | Plano de ondas para o engajamento de migração. | YAML e planilha CSV |
10. Premissas
- A coleta é somente leitura: os coletores fazem só consultas (GET e HEAD; POST apenas em APIs de consulta, como a WIQL do Azure DevOps e a API do AWS CodeCommit) e nunca registram o token em URL, mensagem de erro ou log.
- Nenhum dado pessoal é gravado: usuários entram só em contagens; namespaces pessoais são mascarados no que é publicado.
- Campo que a API da origem nega vira aviso e fica em branco; o levantamento não estima valor ausente.
- Janela padrão das métricas: 90 dias; o detalhe por projeto cobre os projetos mais ativos (padrão: 3.000 por origem).
- A estimativa de duração usa fatores ajustados aos dois exemplos publicados pela GitLab (100 projetos, 19,9 mil issues, 83 mil merge requests e 100 mil pipelines em 8 h; 1.926 projetos, 22 mil issues, 160 mil merge requests e 1,1 milhão de pipelines em 34 h). A GitLab informa que não há fórmula exata: a estimativa é uma projeção e é recalibrada com a onda piloto.
- Velocidades de transferência, limites por onda e horas por equipe são premissas Pointer, exibidas no entregável com a origem e ajustáveis por engajamento.
- Ondas e esforço só são publicados no site do cliente depois da apresentação da proposta.
Fora do escopo
- Execução da migração (oferta de migração).
- Qualquer escrita, alteração de configuração ou arquivamento na plataforma de origem.
- Coleta de nomes, e-mails ou usernames de usuários.
- Tamanho dos repositórios no AWS CodeCommit (a API não informa).
Responsabilidades do cliente
- Criar a conta de serviço ou o usuário dedicado de cada origem e emitir a credencial somente leitura.
- Garantir o acesso de rede à API da origem: runner na rede do cliente ou máquina para a coleta externa, quando a origem é interna; certificado da CA interna e proxy, quando houver.
- Conferir o inventário com a Pointer (inativos, exclusões, dependências).
- Revogar as credenciais no encerramento.
Detalhamento no documento de pré-requisitos PR-AVA-02, enviado após a escolha do serviço.
11. Duração
A duração da coleta depende do número de origens, do volume de projetos e repositórios de cada uma e dos limites de requisição da API da origem. A coleta tem limite de 6 horas por execução. O prazo do levantamento é definido na proposta.
12. Documentos relacionados
- PS-00 · Catálogo de Serviços
- PR-AVA-02 · Pré-requisitos: Levantamento da plataforma
- PS-AVA-01 · Avaliação de maturidade DevSecOps e Customer Success Plan
- PR-AVA-01 · Pré-requisitos: Avaliação de maturidade DevSecOps e Customer Success Plan
- PS-MIG-01 · Migração GitLab para GitLab self-managed
- PS-MIG-02 · Migração GitHub para GitLab self-managed
- PS-MIG-03 · Migração Azure DevOps para GitLab self-managed