Pré-requisitos: Migração GitHub para GitLab self-managed

Documento enviado ao cliente depois da escolha do serviço PS-MIG-02 — Migração GitHub para GitLab self-managed. Lista o que o cliente provisiona, as credenciais que entrega, as informações a enviar à Pointer, o checklist de prontidão e a matriz do que é migrado. O prazo de devolução das informações e do checklist é definido no kick-off.

Os itens do checklist marcados como Preflight automático são conferidos pelo pipeline Pointer contra a instância de destino real antes da primeira onda; os demais são conferidos na reunião de prontidão ou pelo próprio cliente. Nenhuma onda é executada com erro no preflight.

1. Origem e destino suportados
2. Configuração da instância de destino
3. Organização e repositórios no GitHub
4. Host de migração
5. Runner do engajamento
6. Rede
7. Usuários e contribuições
8. Governança da migração
9. Critérios de aceite por onda
10. Entrega das credenciais
11. Credenciais que o cliente entrega à Pointer
12. Informações a enviar
13. Matriz de itens migrados
14. Checklist de prontidão

1. Origem e destino suportados

2. Configuração da instância de destino

3. Organização e repositórios no GitHub

• A organização não pode ter política de acesso de aplicações de terceiros (third-party application access policy) que restrinja a instância de destino (documentação GitLab).
• Custom repository roles do GitHub Enterprise Cloud não são suportados e causam importação parcial (documentação GitLab).
• Colaboradores diretos são importados com o mapeamento de papéis Read → Guest, Triage → Reporter, Write → Developer, Maintain → Maintainer e Admin → Owner; outside collaborators não são importados.
• O GitHub só expõe o e-mail público dos usuários: a correspondência com os usuários do destino é feita pela planilha login do GitHub → usuário no destino.
• A regra Require status checks to pass before merging não é importada; é recriada como verificação externa (external status checks) no destino.
• Durante a janela da onda, os repositórios da onda não recebem alterações no GitHub.

4. Host de migração

5. Runner do engajamento

6. Rede

7. Usuários e contribuições

• Contribuições chegam em usuários placeholder na instância de destino (mapeamento posterior à migração, padrão desde a versão 17.8).
• O pipeline não cria usuários a partir do GitHub: os usuários do destino já existem, provisionados por LDAP, SAML ou cadastro.
• Reatribuição em lote pelo pipeline, com a planilha login do GitHub → usuário no destino, que vale antes da correspondência por e-mail (só o e-mail público do GitHub) ou por username.
• Reatribuição pedida pelo Owner do grupo de topo; com a opção de reatribuição sem confirmação ligada no destino, é imediata.
• A conta dona do token do destino é a conta da importação.

8. Governança da migração

• Aprovador de cada onda e do rollback, do lado do cliente.
• Janela de manutenção de cada onda e congelamento de escrita no GitHub durante a janela.
• Responsável pelos usuários placeholder sem correspondente (Owner do grupo de topo) e prazo.
• Momento do corte (arquivamento dos repositórios no GitHub) e comunicação aos usuários.
• Responsável por cada item de tratamento manual da matriz, inclusive a conversão dos workflows do GitHub Actions.

9. Critérios de aceite por onda

• Relatório da onda sem erro: todo repositório existe no destino e nenhuma importação terminou com falha.
• Alertas (relações com falha, diferença entre objetos lidos e importados nas estatísticas do importador) analisados e aceitos ou corrigidos, com registro no registro de decisões.
• Com reatribuição: todos os usuários reatribuídos ou aguardando aceite, se o destino exigir confirmação.
• Validação funcional pelo cliente nos repositórios críticos da onda: clone, merge requests e issues.

10. Entrega das credenciais

Cada credencial é cadastrada como variável de CI/CD do projeto do engajamento, com as opções Protected e Masked and hidden e escopo restrito ao ambiente de migração, que é protegido e exige aprovação para a migração e o rollback de cada onda. O pipeline lista, sem valores, as variáveis exigidas pelo plano, e o preflight reprova se faltar alguma. A configuração do GitLab Congregate com os tokens só existe durante cada job no host de migração.

Tokens nunca são colados em chat, issue ou arquivo; se isso ocorrer, o token é revogado e outro é emitido. No encerramento, os tokens usados na origem e no destino são revogados e as contas de administrador criadas para o engajamento são desativadas.

11. Credenciais que o cliente entrega à Pointer

Nenhum valor secreto é enviado por e-mail, chat, issue ou arquivo. Cada credencial é cadastrada como variável de CI/CD protegida no projeto do engajamento, com escopo do ambiente, e revogada no encerramento.

12. 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.

Origem

Destino

Host de migração e rede

Usuários

Ondas

Pós-migração e corte

Contatos

13. Matriz de itens migrados

O tratamento de cada item segue a documentação oficial do método de migração e é conferido na onda piloto do engajamento.

Repositório

Pull requests → merge requests

Issues e planejamento

CI/CD e automação

Usuários, organização e acesso

Conteúdo não migrado

Notas da matriz

• A confirmar na onda piloto: eventos de issues e de pull requests (a documentação GitLab informa que podem ser importados como item adicional; a API de importação lista como etapas opcionais só anexos, colaboradores e comentários pelo endpoint único); webhooks (não importados pelo importador; o GitLab Congregate informa que ainda não suporta).
• Referências: a instância de destino cria links só para issues citadas em comentários (o GitHub usa # para issues e pull requests) e não cria links em descrições.
• GitHub Enterprise Server: toda a matriz é conferida na onda piloto.

14. 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.