A step-by-step guide to migrating from Perforce to Git
Como discutimos no artigo anterior, o Git agora é a escolha de fato para o SCM para quase todos os tipos de desenvolvimento digital. Mas se você tem anos de históricos valiosos armazenados no Perforce, é possível que o custo da troca esteja pesando. Neste artigo, vamos abordar essas preocupações de frente e vamos mostrar como migrar dados para o Git. Dividimos o processo de migração do Perforce para o Git em 8 etapas:
Etapa 1: mover dados do Perforce
Existem duas abordagens gerais para mover os dados do Perforce para o Git. Antes de mergulharmos nessa área, precisamos considerar uma diferença fundamental entre como o Perforce e o Git lidam com projetos de software.
Um servidor Perforce pode conter dezenas ou centenas de projetos de software distintos, cada um com seu próprio modelo de branches. Um desenvolvedor define uma “visualização” que informa ao servidor Perforce quais arquivos devem ser colocados em uma cópia de trabalho. Um repositório do Git, por outro lado, normalmente contém um único projeto de software e seus branches e tags (embora existam grandes repositórios monolíticos do Git). Normalmente, você clona o repositório e, talvez, consulta os submódulos ou subárvores.
A questão de mover os dados, então, tem duas partes: como extrair dados do Perforce e como traduzir esses dados em um conjunto equivalente de repositórios Git.
Opção 1 para mover dados do Perforce: usando o Git Fusion
Se você quiser preservar todo o histórico de seus dados no Perforce, você pode usar a própria ferramenta Git Fusion do Perforce para extrair uma seção de um servidor Perforce (um único projeto) em um repositório Git. Em essência, você:
Material relacionado
Como mover um Repositório do Git completo
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
- Instale o Git Fusion
- Configure as visualizações corretas dos seus dados, incluindo a estrutura de branches
- Use qualquer cliente Git para clonar do Git Fusion
- Empurre seu repositório para o Bitbucket
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.Agora, esse comando nem sempre oferece uma cópia 100% fiel dos seus dados do Perforce. Existem algumas operações do Perforce, como merges parciais, que simplesmente não têm equivalente no Git. Mas, apesar de tudo, esse método vai obter a maior parte do seu histórico sem muito esforço.
Lembre-se de que preservar os últimos 10 anos de histórico de branches de um SCM legado não significa que você tenha que continuar usando o mesmo fluxo de trabalho. É notável que você deve considerar a adoção de fluxos de trabalho de branches de características como o Git Flow como um primeiro passo prático.
Prós e contras
- Requer mais trabalho de configuração e tempo de execução
- Preserva a maior parte do histórico (permitindo que você desligue o servidor Perforce herdado)
- Mantém o modelo de branches legado no histórico
Movendo dados do Perforce Opção 2: recomeçar
A outra opção é começar de novo. Esqueça todo esse histórico desnecessário: basta extrair a cabeça (ponta) de cada branch no Perforce que corresponde ao seu projeto e verificar essas coisas em um novo repositório Git vazio. (O que quer dizer que você tem espaços de trabalho do Perforce definidos com uma "visualização" correta dos dados desejados.)
Essa é a técnica mais simples e rápida. Não importa se o histórico do Perforce era muito complicado, seu novo repositório Git é simples e eficiente. Você tem a chance de iniciar um novo fluxo de trabalho baseado em Git sem nenhuma bagagem acumulada.
A principal desvantagem é que você provavelmente quer manter o antigo servidor Perforce em um modo somente leitura, caso alguém precise pesquisar o código histórico por qualquer motivo. Essa opção não vai custar nada em taxas de licença, mas implica manter o servidor antigo ativo por um tempo.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.Prós e contras
- Rápido e simples
- Redesenhar o modelo e o fluxo de trabalho de branches
- Servidor Perforce herdado usado para acesso somente leitura
Etapa 2: usuários e permissões
Depois que os dados são movidos, a próxima tarefa, em geral, é começar a mapear seus usuários e permissões em novos projetos do Bitbucket. Se você usar o LDAP para um diretório de usuários, vai economizar algum tempo aqui. Caso contrário, você pode extrair facilmente um conjunto de contas de usuário do Perforce usando o comando p4 users –o e, em seguida, inseri-las no Bitbucket, um projeto de cada vez.
Traduzir as permissões do Perforce em permissões equivalentes do Bitbucket pode ser difícil porque as permissões do Perforce são granulares e complexas, com a possibilidade de excluir o acesso a arquivos individuais. Esse esquema de permissão complicado é uma das razões pelas quais um servidor Perforce pode ficar atolado – cada tentativa de acesso pode fazer com que o servidor execute um cálculo caro em uma estrutura de dados complicada.
Na maioria dos casos, é mais rápido pedir aos líderes do projeto que definam um conjunto mais simples de permissões no Bitbucket usando as permissões normais de projeto, repositório e branch. De fato, você vai querer rever sua configuração de permissões mesmo assim, já que o Git oferece muitas novas opções de fluxo de trabalho. Por exemplo, no Perforce, você pode ter restringido a criação de branches, enquanto no Bitbucket você só precisa restringir o acesso push ao branch principal.
Etapa 3: arquivos binários
Se você armazenou grandes blobs binários no Perforce, pense com cuidado sobre como quer gerenciá-los no Git. Você pode experimentar o Git LFS ou apenas usar um sistema regular de gerenciamento de artefatos. De qualquer forma, você não quer empurrar cegamente grandes blobs para um repositório Git.
Etapa 4: dependências complexas
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
Etapa 5: como estruturar sua equipe durante a migração
Então, seu servidor Perforce tem 100 projetos de 10 equipes. Você tem uma estratégia de migração e um conjunto de ferramentas definidos. Agende a janela de manutenção e pronto!
Bem… não.
Lembre-se de que mudar as ferramentas de SCM tem tanto a ver com desenvolvedores quanto com dados. Você tem pessoas, processos e horários a considerar — não tente colocar a carroça na frente dos bois. É muito arriscado.
Você precisa considerar um plano de projeto durante a fase de migração real. (Pode ser um bom momento para experimentar um novo fluxo de trabalho do Jira…) Aqui estão algumas opções para você dar uma olhada.
- Migre equipe por equipe e projeto por projeto. Procure iniciar um projeto e uma equipe no início de um sprint ou incremento do programa, quando você tiver algum tempo para se adaptar.
- Migre aos poucos. Importe todos os seus dados em um fim de semana, mas deixe que as equipes concluam com calma a mudança para o Git ao longo do tempo. Recolha periodicamente os deltas executando suas ferramentas de importação mais uma vez. Embora seja mais complexa, essa estratégia não é ruim se você tiver dependências entre equipes e os primeiros usuários precisarem de pelo menos um instantâneo recente no Git para alimentar seu pipeline de CI/CD.
- Use os dois sistemas ao mesmo tempo por um período de tempo. Embora não seja para os fracos de coração, é tecnicamente viável usar o Git Fusion para fazer uma troca de dados bidirecional, desde que você não esteja fazendo operações complexas que confundam o tradutor de dados.
Por fim, invista na comunicação das mudanças para a equipe — a motivação, o porquê e uma série de etapas para concluir o processo. Escolha uma equipe de “adoção inicial” com engenheiros experientes em todo o ciclo de vida de desenvolvimento de software e faça com que essa equipe seja um modelo para os outros. Encontre campeões do Git para ajudar as pessoas quando elas tiverem dificuldades. Fazer mudanças pequenas, compreensíveis e iterativas vai ajudar a tornar esse processo bem-sucedido.
Step 6: Mirrors and clusters
O Perforce tem um sistema simples, mas eficaz, para espelhar dados em locais remotos para reduzir o efeito da latência. Ele tem um sistema mais complexo para executar um conjunto de espelhos locais para agrupamento somente leitura. Embora a latência não seja mesmo uma grande preocupação para o Git, se você estiver executando uma operação mundial, deve procurar o Bitbucket Data Center tanto para clustering quanto para espelhamento, o que vai acelerar bastante os tempos de clonagem para uma equipe global.
Step 7: ALM tools
E agora algumas boas notícias — você tem muitas opções para sua pilha de ferramentas de ALM ao mudar do Perforce para o Git. Praticamente todos os desenvolvedores e ferramentas de ALM funcionam com o Git e, é claro, o Bitbucket oferece uma ótima integração com o Jira e o Bamboo. Ao fazer a transição para o Git, você pode explorar as características do Bamboo, como branches de plano, que aproveitam o fluxo de trabalho de um branch de característica.
Etapa 8: definindo o sucesso
Então, como exatamente se mede o sucesso durante uma migração do Perforce para o Git? Em muitos projetos de migração, tendemos a nos concentrar demais na fidelidade da transferência de dados. Mas essa não é uma métrica útil por vários motivos. É provável que você nunca consiga obter um histórico bit a bit no Git que seja o exato equivalente ao que aconteceu em um sistema SCM centralizado como o Perforce.
Uma abordagem mais prática é usar o CI/CD para verificação. Depois de mudar seu pipeline de CI/CD do Perforce para o Git, todos os seus testes ainda passam? E você ainda pode implementar seu software? Se todas as suas compilações antigas importantes ainda puderem passar pelo pipeline de CI/CD, é hora de declarar vitória!
Fim de papo
Então agora você viu por que há movimento do Perforce para o Git e como chegar lá de verdade. O próximo passo é escolher uma solução Git. Se você está saindo do Perforce por causa de desenvolvimento de jogos, veja por que os desenvolvedores de jogos adoram o Bitbucket.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
