Do Perforce ao Git: por que mudar

Fluxo de trabalho

Deixando de lado todos os penduricalhos, em essência uma ferramenta de SCM é sobre colaboração: permitir que uma equipe de desenvolvedores trabalhe em um conjunto compartilhado de arquivos de software. O Git oferece branches simples e baratos do ponto de vista computacional, o que abre as portas para diversos fluxos de trabalho interessantes. Branches de tarefas, Git Flow, repositórios bifurcados — há um fluxo de trabalho rápido e fácil para qualquer tipo de equipe, desde código aberto até desenvolvimento profissional, auxiliado por ferramentas poderosas de revisão de código e colaboração.

O Git também facilita a colaboração além dos limites da empresa, um requisito comum no desenvolvimento multifuncional. Mesmo que o acesso à rede física a um repositório compartilhado do Git não seja possível, as ferramentas de patch e agrupamento do Git simplificam o compartilhamento de dados.

O Perforce, por outro lado, mantém um registro de branches por arquivo, em comparação com um funcionamento "por commit" com o Git. Como assim? Bem, para começar, ele cria uma grande quantidade de metadados no banco de dados do Perforce toda vez que você cria um branch. Esse comportamento contribui para problemas de desempenho em implementações maiores, na medida em que muitos administradores do Perforce restringem a criação de branches.

Pense nisso por um momento: toda vez que você quiser criar um branch de tarefas para experimentar uma nova função, você precisa pedir permissão. Se você não pode criar branches de tarefas, você pode verificar o código instável no branch principal, ou apenas esperar até que você esteja “pronto” antes de fazer o commit. Você sacrifica o benefício de ter CI/CD nos branches de tarefas e ser capaz de acompanhar o trabalho granular em andamento. O resultado final é a produtividade reduzida, pois os desenvolvedores vivem com fluxos de trabalho menos produtivos ou só começam a usar o Git em paralelo e descobrem como fazer o merge manual do trabalho de volta ao Perforce.

Além de serem caras, os branches do Perforce não são propícios ao tipo de fluxo de trabalho que a maioria dos desenvolvedores prefere. Os branches do Perforce são compartilhados; portanto, não existe um branch privado de tarefa com rebase periódico. E os algoritmos de merge do Perforce são complicados demais, com artigos inteiros escritos sobre como fazer o merge de arquivos que foram renomeados ou tiveram os atributos modificados.

E compartilhar código entre servidores do Perforce? Você voltou a compartilhar arquivos TAR sem histórico comum. O modelo de dados do Perforce pensa no histórico do software como sendo exclusivo para um único servidor, em comparação com a capacidade fácil do Git de clonar e compartilhar o histórico em todos os lugares.

Compartilhamento de pensamentos e comunidade

Deixando de lado os concorrentes comerciais, por que o Git derrotou o Mercurial e outros concorrentes dignos? É claro que tem algum valor na motivação, o que o Git tem. O Git foi criado por Linus Torvalds para resolver os desafios de desenvolvimento distribuído do projeto do kernel Linux e agora é a ferramenta SCM padrão para Linux, Android, OpenStack e a maioria dos outros projetos de código aberto significativos. É o que o pessoal legal está usando — então, se você é gerente de contratação, é provável que possa presumir que um novo engenheiro pode (e vai querer) trabalhar com o Git sem exigir treinamento extensivo.

E, claro, você tem todo o poder de uma comunidade de código aberto vibrante por trás do Git. O Git está evoluindo com rapidez para resolver problemas do mundo real, com novas funções importantes, como o Git LFS, entrando em cena. Você pode contribuir com seu próprio código para o projeto Git, se houver um bug que você queira corrigir, e você nunca vai ficar preso a um produto comercial com um roteiro e ritmo definidos por uma única empresa. Basta olhar para a variedade de programas cliente Git disponíveis: várias GUIs de desktop poderosas, integração com o Windows Explorer, plug-ins para cada IDE e ferramentas de desenvolvedor.

GUIs e ferramentas de desenvolvedor

Nos dias originais do Git, o suporte à GUI e à ferramenta estava um pouco ausente. Foi um obstáculo para os usuários que preferem uma interface visual para interagir com os repositórios Git. Colaboradores não técnicos, como artistas de jogos, foram particularmente privados de direitos. O plugin do Windows Explorer do Perforce foi um sucesso com esse público.

Mas, ainda bem, esses dias já passaram. GUIs como o Sourcetree oferecem uma experiência de apontar e clicar e há uma infinidade de integrações de shell para o Git. O Bitbucket oferece revisão de código, merge e pull requests, bifurcação, navegação de código on-line e uma infinidade de outras ferramentas de colaboração. De fato, todos, de cientistas de dados a agências criativas, estão organizando comunidades que fazem uso da colaboração aberta que o Git e o Bitbucket possibilitam.

Os desenvolvedores de jogos são especiais

Pensando nisso, o que impediu algumas comunidades, como desenvolvedores de jogos e pesquisadores que trabalham com enormes conjuntos de dados, de entrar no movimento? Tudo se resume ao tipo de dados e à complexidade da organização do projeto.

Arquivos binários

Os desenvolvedores de jogos, particularmente artistas, precisam trabalhar com grandes objetos binários, como texturas e recursos de áudio. Os cientistas de dados podem ter conjuntos de dados enormes que compreendem bilhões de amostras de eventos.

Então há dois problemas para o Git.

• Esses arquivos não podem passar por merge. Um mecanismo de bloqueio centralizado é útil e o Perforce oferece um. (Observe, no entanto, que mesmo um servidor centralizado oferece apenas um mecanismo de bloqueio em um único branch; portanto, confiar nessa função implica que você teve um fluxo de trabalho muito restrito.)
• Esses arquivos fazem com que o Git fique lento à medida que o tamanho do repositório aumenta.

O problema do tamanho do repositório é abordado com abrangência pelo Git LFS, uma extensão que permite que o Git manipule arquivos grandes enquanto delega o armazenamento real de arquivos em outro lugar.

O problema do bloqueio de arquivos é examinado em duas frentes. Do ponto de vista do gerenciamento de configuração de software, o Git LFS tem um tipo superior de bloqueio de arquivos no roteiro. O Git LFS vai ajudar a coordenar arquivos binários de bloqueio em vários branches com um algoritmo que garante que você esteja trabalhando na versão mais recente, não importa em qual branch você esteja. Assim você pode abrir fluxos de trabalho de branches para usuários que trabalham com grandes arquivos binários, em comparação com o modelo restrito de branch único do Perforce.

Também é útil pensar no bloqueio de arquivos como um problema de coordenação. Se você vai começar a trabalhar em um ativo compartilhado que não pode passar por merge, como você transmite esse conhecimento para todas as partes interessadas? De novo, é aqui que o advento dos fluxos de trabalho modernos usando pull requests e colaboração em equipe em tempo real brilha se destaca de verdade. Você pode comunicar com rapidez as intenções usando o Hipchat e verificar se há algum trabalho pendente em andamento em um arquivo específico.

Também é interessante considerar como o problema de lidar com arquivos grandes vai evoluir na era do Big Data. Para testar um trabalho de análise de Big Data, você pode precisar de um conjunto de dados de vários terabytes. Esqueça qualquer sistema SCM — este projeto é testado e executado em um sistema de arquivos compatível com Big Data. O que é necessário aqui é um sistema de CI/CD que possa orquestrar um pipeline mais complexo com artefatos presentes no HDFS ou no S3. Então chegamos ao próximo tópico.

Grandes projetos

O desenvolvimento de jogos é um exemplo clássico de um projeto de software com vários módulos ou componentes — o mecanismo de jogo, a interface do usuário, arte estática, renderizações de vídeo e assim por diante. O Perforce, como um repositório centralizado monolítico, pode hospedar todos esses módulos em um único servidor e permitir que os usuários escolham quais partes escolher no próprio espaço de trabalho.

No entanto, essa vantagem é discutível com abrangência agora. Sistemas Git modernos, como o Bitbucket, oferecem gerenciamento mais fácil de ferramentas de vários módulos do Git, como submódulos e subárvores. E o mais importante, grandes projetos como o Android mostraram como gerenciar um projeto complexo usando ferramentas de composição de nível superior. Muitas dessas lições foram trazidas para ferramentas modernas de CI/CD, como o Bamboo e o Bitbucket Pipelines, que podem orquestrar fluxos de trabalho complexos de integração contínua, modelar as dependências entre projetos e gerenciar artefatos entre projetos.

Essa tendência segue em grande parte a filosofia Git (e *nix) de compilar uma ferramenta que faz um único trabalho muito bem. Integração contínua e entrega contínua (CI/CD) é uma prática própria, com ferramentas dedicadas a entender o fluxo de trabalho de compilação e lançamento. Ele também se alinha às práticas recomendadas de desenvolvimento de software modernas, que visam usar pequenos microsserviços independentes em vez de projetos monolíticos.

Próximos passos

Há, é claro, alguma motivação no campo “do Perforce ao Git”, e o Git e as ferramentas modernas de CI/CD agora estão prontos para lidar com os maiores e mais complexos esforços de desenvolvimento. De fato, o Perforce até criou uma ferramenta chamada Git Fusion que permite extrair parte de um repositório central do Perforce como um repositório do Git.

Infelizmente, embora o Git Fusion tenha sido um esforço nobre, tentar colocar o Git em um sistema SCM centralizado não é muito fácil; se você tentar misturar seus modelos de uso, vai poder com facilidade corromper a visão dos dados de um sistema. Se você não misturar seus modelos de uso, é difícil ver o valor de colocar um back-end comercial centralizado por trás do Git. A tendência, como vimos, está na verdade na outra direção: como você coloca as últimas peças restantes do SCM centralizado que foram úteis no Git?

Se você estiver usando o Perforce para qualquer desenvolvimento de software ou jogo, é provável que esteja se perguntando (com nervosismo) sobre como migrar para o Git. Mas como é o processo? E vale a pena o custo de troca? É exatamente o que vamos abordar no próximo artigo.