Vantagens e Desvantagens do Controle de Versão Distribuído
O controle de versão distribuído (Distributed Version Control Systems – DVCS) tem chamdo a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Git e Mercurial (distribuídos).
Mas o que tem de errado com o controle de versão centralizado? Nada. Ele usa uma estrutura que atende muito bem a grande parte das equipes de desenvolvimento de software. Baseia-se na arquitetura cliente-servidor, com um repositório central (servidor) e cópias de trabalho para os desenvolvedores (clientes).
Para equipes de desenvolvimento com acesso ao repositório pela rede local, essa arquitetura funciona bem. A velocidade da rede não é problemática, o tempo de resposta do processamento é aceitável e todos os desenvolvedores da equipe têm permissão de leitura e escrita no repositório.
Não foi para resolver exatamente esse tipo de necessidade que o controle de versão distribuído foi criado. Imagine uma situação diferente:
- Equipe com centenas de desenvolvedores. Significa que mais processamento vai ser exigido do servidor central, piorando o tempo de resposta;
- Equipe espalhada em diferentes filiais da empresa. Acesso remoto ao repositório com limitações de conexão e de permissão de escrita;
A arquitetura cliente-servidor não funciona tão bem para essas situações. Soluções alternativas como aumentar a capacidade de processamento do servidor ou replicar os repositórios nem sempre são viáveis ou fáceis de serem implementadas.
Para essas situações, o controle de versão distribuído é mais adequado porque se baseia em repositórios autônomos e individuais.
Benefícios do Controle de Versão Distribuído
As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e às novas possibilidades de colaboração entre desenvolvedores (novos fluxos de trabalho).
Do Ponto de Vista do Desenvolvedor
-
Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um
commit,logoudiffpor exemplo. - Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo.
Do Ponto de Vista da Gerência/Coordenação
Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:
-
Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho, os repositórios dos desenvolvedores funcionam como cópias de
backupde todo o projeto. - Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório "central", quando existe, tem o papel do repositório "oficial" e não como processador central das requisições.
Desvantagens do Controle de Versão Distribuído
Nem tudo são flores com o DVCS.
Maior Complexidade
No centralizado, a forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.
O DVCS é mais complicado. Há diversas combinações de arquiteturas de repositórios e fluxos de trabalho possíveis, o que pode tornar o histórico da evolução do projeto bastante confuso.
Ao contrário do centralizado, não adianta só commit e update para funcionar "no tranco". Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos.
Travamento de Arquivos Binários Precisa Ser Centralizado
Diferentemente dos arquivos de texto, arquivos binários possuem um formato interno que não é baseado em linhas de texto e, por isso, não podem ser mesclados automaticamente pelo controle de versão ou manualmente pelo desenvolvedor.
Sendo assim, a edição concorrente de arquivos binários é problemática. Duas pessoas editando ao mesmo tempo uma figura, por exemplo, não conseguirão mesclar as modificações depois e o trabalho de uma delas precisará ser refeito.
Com arquivos binários, a melhor solução é usar o travamento, isto é, sinalizar que o arquivo está travado para edição e que ninguém mais deve editá-lo enquanto isso.
O modelo puramente distribuído não é adequado para lidar com travamento justamente por não possuir um servidor central que possa controlar as travas de todos.
Controle de Mudança Ainda é Centralizado
As ferramentas de controle de mudança (e.g. Trac, Redmine, Mantis, Bugzilla) ainda não acompanharam as de controle de versão na arquitetura peer-to-peer. Isto significa que mesmo usando um DVCS, ainda haverá uma ferramenta centralizada para controle de mudança.
Resumo das Características do Controle de Versão Distribuído
| Ponto de Vista | Vantagens | Desvantagens |
|---|---|---|
| Desenvolvedor |
|
|
| Coordenação/Gerência |
|
|
Considerações Finais
Controle de versão distribuído oferece algumas vantagens interessantes sobre o centralizado. Por outro lado, requer muito mais preparo da equipe e também do processo, o que não chega a ser realmente um impedimento uma vez que um processo formalizado e equipes capacitadas são fundamentais para produção de software de qualidade.
A próxima pergunta é: qual ferramenta de controle de versão mais adequada às suas necessidades?
Comentários
Comments powered by Disqus