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

Documento enviado ao cliente depois da escolha do serviço PS-MIG-04 — Migração Bitbucket Cloud 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. Workspace e repositórios no Bitbucket Cloud
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. Workspace e repositórios no Bitbucket Cloud

• O workspace é informado no plano de migração e define o escopo da listagem.
• Pull requests de fork ou entre projetos diferentes viram merge requests vazios (documentação GitLab).
• Revisores dos pull requests são importados quando o username casa com uma identidade Bitbucket vinculada na instância de destino.
• Issues importadas recebem label pelo tipo (bug, enhancement, proposal, task); estados resolved, invalid, duplicate, wontfix e closed viram issue fechada.
• Imagens e anexos inline em Markdown continuam como links para o Bitbucket Cloud e deixam de funcionar se o repositório de origem for apagado.
• Durante a janela da onda, os repositórios da onda não recebem alterações no Bitbucket Cloud.

4. Host de migração

5. Runner do engajamento

6. Rede

7. Usuários e contribuições

• Não há usuários placeholder nem reatribuição depois da importação: o mapeamento posterior à migração não se aplica ao Bitbucket Cloud (documentação GitLab).
• O importador usa o nickname do Bitbucket e procura a identidade Bitbucket vinculada na instância de destino; sem correspondência, o autor passa a ser a conta que fez a importação, com referência ao autor original.
• Para a correspondência, cada usuário ajusta o nome público da conta Atlassian igual ao username do Bitbucket e conecta a conta Bitbucket no perfil da instância de destino (Service sign-in), antes da onda. A atribuição de autoria por identidade vinculada está no roadmap.
• O pipeline não cria usuários a partir do Bitbucket Cloud (o GitLab Congregate não migra contas de usuário nem chaves SSH do Bitbucket Cloud): os usuários do destino vêm de LDAP, SAML ou cadastro.
• A documentação do GitLab Congregate descreve a criação, pelo provedor de identidade, de um usuário de sistema para receber as contribuições órfãs; o pipeline não exige essa conta.
• 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 Bitbucket Cloud durante a janela.
• Decisão sobre a conta que recebe as contribuições sem correspondência (conta dona do token do destino).
• Comunicação aos usuários sobre o fim do uso dos repositórios no Bitbucket Cloud (o pipeline não arquiva a origem Bitbucket Cloud).
• Responsável por cada item de tratamento manual da matriz, inclusive a conversão dos Bitbucket Pipelines.

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) analisados e aceitos ou corrigidos, com registro no registro de decisões.
• Validação funcional pelo cliente nos repositórios críticos da onda: clone, merge requests e, quando usados, issues e wiki.

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 e-mail da conta Atlassian também fica em variável do ambiente, fora do repositório do engajamento. 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

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 e acesso

Conteúdo não migrado

Notas da matriz

• A confirmar na onda piloto: regras de aprovação (não importadas pelo importador nem pelo GitLab Congregate, segundo a documentação GitLab e a matriz do GitLab Congregate); webhooks (não suportados pelo importador nem pelo GitLab Congregate, segundo a matriz do GitLab Congregate).
• Autoria: sem identidade Bitbucket vinculada ao usuário do destino, pull requests e comentários ficam na conta da importação.

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.