Source: Dev.to | Dec 17, 2025 (UTC)
Por que essa migração precisava acontecer
O GitLab Community Edition funciona bem no começo. Mas, quando os times crescem, os repositórios se multiplicam e o volume de pipelines explode, surgem limites claros:
falta de governança
configurações inconsistentes
runners heterogêneos
pipelines instáveis
ausência de recursos corporativos essenciais
A migração para o GitLab Enterprise Edition era mais que uma melhoria técnica.
Era um passo em direção à maturidade organizacional.
O desafio?
Não existe uma migração oficial que preserve tudo corretamente.
Sem outra saída, foi criado uma solução própria.
O que torna essa migração tão complexa?
Mover 4 mil projetos não é mover pastas.
É preservar um ecossistema inteiro, com elementos como:
histórico completo de commits
branches protegidas
tags de releases
variáveis e segredos
pipelines com includes espalhados
issues e comentários
estados de arquivamento
runners e permissões
A ferramenta nativa de import/export do GitLab quebra grande parte disso no caminho.
Eu precisava construir uma automação capaz de migrar tudo, confiavelmente.
O toolkit que construiu a ponte
Foi desenvolvido um conjunto modular de scripts em Bash para garantir controle absoluto sobre cada parte da migração. Ele está publicado aqui:
👉 https://github.com/clcesarval/migrar-gitlab
A arquitetura tinha duas camadas claras:
-
A camada Git
Responsável por:
clonar todos os repositórios
reconstruir branches
garantir a integridade do DAG
preservar tags exatamente como no CE
reconfigurar remotes
reaplicar estado de arquivamento -
A camada API
Responsável por:
variáveis e segredos
issues e comentários
hierarquias de grupos
permissões
recriação de projetos no destino
Cada script fazia apenas uma coisa, mas fazia com precisão.
Entre eles:
clone-projects.sh
replace_gitlab-ci.sh
push_projects.sh
migrar-variaveis.sh
migrate-issues.sh
scripts recursivos para subgrupos
inventário completo de runners
Era automação com propósito, não mágica.
O caos escondido que apareceu
A documentação oficial ajudava, mas apenas parcialmente. Muitas partes eram inconsistentes, incompletas ou simplesmente não funcionavam como descrito quando aplicadas em grande escala.
Além disso, detectei problemas como:
includes de pipeline com caminhos absolutos que quebrariam após a migração
variáveis duplicadas, sem escopo ou mal organizadas
runners antigos com configurações imprevisíveis
projetos arquivados reaparecendo como ativos na importação oficial
tags sendo recriadas de forma incorreta
A adoção do processo padrão teria potencialmente causado um impacto operacional severo em toda a organização.
Os testes piloto… e os erros que salvaram a migração
Para garantir que tudo funcionaria, rodei vários testes piloto, em ambientes isolados.
E todos eles, sem exceção, apresentaram erros no começo.
Tive:
include: /old-group/subgroup/template.yml
Enter fullscreen mode
Exit fullscreen mode
Залишити відповідь