Fala galera do mal!
Estou aqui hoje para publicar meu primeiro artigo, espero que gostem (se não gostarem, que o estalo do Thanos lhes desintegre ).
Neste artigo vou falar sobre um assunto que vem sendo motivo de muita discussão hoje em dia, principalmente em projetos novos, ou em equipes de desenvolvimento que estão dando seus primeiros passos para elaboração e definição de um processo de software.
Neste passo a equipe costuma definir padrões, convenções, frameworks, linguagens, ambientes de desenvolvimento e, para controlar as alterações do projeto, precisamos escolher entre 3 grandes ferramentas de mercado.
Essas ferramentas possuem pequenas particularidades, as quais, por falta de conhecimento prévio, tornam-se um problema no decorrer do projeto, pela pouca expertise no uso.
Ou, como ocorre na maioria dos casos, pela estrutura proposta de trabalho não ser aderente a metodologia da ferramenta em questão. 🙂
Lembrem-se: Nunca, never, de forma alguma escolham a ferramenta apenas por ser a “modinha do momento”, pois, nem tudo que é moda se enquadra para todos
Agora que fizemos esta pequena introdução e estudo de caso, vamos finalmente parar com a lengalenga e vamos ao ponto. 😀
Ah e se ficar muito grande vocês esperam sair o filme 🙂
>>Leitura Recomendada: Mapeamento objeto-relacional — tudo sobre!
Git, SVN e CVS: qual sistema de controle de versão ideal para mim?
Existem várias soluções disponíveis e, por isso, criamos uma comparação de recursos definitiva para que você possa decidir a melhor solução para você. 😀
Este é um tópico bastante técnico, portanto, se você não tiver um histórico de software, leia nossa comparação cuidadosamente e consulte seu pessoal técnico antes de tomar qualquer decisão final (espero que você seja técnico do fundo do coração).
Softwares de controle de versão, incluindo o bem conhecido SVN e Git, foram projetados desde o início para permitir que equipes de programadores trabalhassem juntos em um projeto sem desperdiçar horas-homem em papelada.
Em vez de varrer manualmente as ramificações do código e as notas associadas, o controle de versão permite um repositório central que é organizado, lógico e facilita as atualizações de arquivos, a notação e até mesmo a mesclagem.
Além disso, você também deve considerar a velocidade, a funcionalidade e a curva de aprendizado associadas ao sistema.
Para decidir qual é o certo para o seu projeto e equipe, vamos dar uma olhada em alguns dos principais sistemas disponíveis e as razões pelas quais alguns programadores preferem um ou outro.
Sistema de Versões Concorrentes (CVS)
Senhores, esse carinha existe desde os anos 80 e tem sido muito popular entre os desenvolvedores comerciais e de código aberto.
Originalmente o CVS lidava com conflitos entre dois programadores, permitindo apenas que a última versão do código fosse trabalhada e atualizada.
Foi um sistema em que o usuário deve publicar as alterações rapidamente para garantir que outros usuários não os tenham vencido.
Agora, o CVS pode manipular projetos de ramificação para que o software desenvolvido possa divergir em diferentes produtos com recursos exclusivos e será fundido posteriormente.
Prós do CVS
- Está em uso há muitos anos e é considerado uma tecnologia madura (famosa panela velha que faz comida boa);
Contras do CVS
- Mover ou renomear arquivos não inclui uma atualização de versão;
- Riscos de segurança de links simbólicos para arquivos;
- Sem suporte à operação atômica (lembra da história da atomicidade né? Espero que sim), levando à corrupção da fonte;
Estrutura do sistema CVS
O controle de versão centralizado segue a topologia em estrela, havendo apenas um único repositório central, mas várias cópias de trabalho, uma para cada desenvolvedor.
A comunicação entre uma área de trabalho e outra passa obrigatoriamente pelo repositório central.
Tendo isso em vista, nossa amiga APACHE resolveu criar o seu próprio CVS chamado de Subversion.
>>Leitura Recomendada: XML vs JSON: Entenda como fazer a melhor escolha
Subversion do Apache (SVN)
O SVN foi criado como uma alternativa ao CVS que corrige alguns bugs no sistema, mantendo alta compatibilidade com ele.
Assim como o CVS, o SVN é gratuito e de código aberto, com a diferença de ser distribuído sob a licença Apache, em oposição ao GNU.
Para impedir que a corrupção no banco de dados ocorra, o SVN emprega um conceito chamado operações atômicas (Você também lembra disso, né?).
Todas as alterações feitas na origem são aplicadas ou nenhuma é aplicada, o que significa que nenhuma alteração parcial afetará a fonte original.
Muitos desenvolvedores mudaram para o SVN, uma vez que é uma tecnologia mais nova que usa os melhores recursos do CVS e os aprimora.
Prós SVN
- Sistema mais novo baseado no CVS;
- Inclui operações atômicas;
- Operações de banchs mais baratas;
- Ampla variedade de plug-ins para IDEs;
- Não usa modelo peer-to-peer.
Contras SVN
- Ainda contém erros relacionados à renomeação de arquivos e diretórios;
- Comandos de gerenciamento de repositório insuficientes;
- Velocidade comparativa mais lenta.
Com isso, surgiu o nosso queridinho da atualidade o tal do Git.
Estrutura do sistema SVN
>>Leitura Recomendada:
Leia nosso artigo sobre a importância da documentação de software
Git
Desenvolvido primeiramente por Linus Torvalds (sim, o cara do Linux), o Git adota uma abordagem radical que difere muito do CVS e do SVN.
Os conceitos originais do Git eram fazer um sistema de controle de revisão distribuído mais rápido que desafiasse abertamente as convenções e práticas usadas no CVS.
É desenvolvido principalmente para Linux e tem as velocidades mais altas. Ele também será executado em outros sistemas semelhantes ao Unix, e as portas nativas do Git estão disponíveis para o Windows como msysgit.
Como não há um servidor centralizado, o Git não se presta a projetos individuais de desenvolvedores ou a pequenas equipes, pois o código pode não estar necessariamente disponível ao usar um computador sem repositório.
Existem soluções alternativas para esse problema, e algumas vêem a velocidade aprimorada do Git como um tradeoff decente para o aborrecimento.
O Git também vem equipado com uma ampla variedade de ferramentas para ajudar os usuários a navegar no sistema de histórico.
Cada instância da fonte contém toda a árvore do histórico, que pode ser útil ao desenvolver localmente, sem uma conexão com a internet.
Prós Git
- Ótimo para quem odeia o CVS/SVN;
- Aumento dramático na velocidade de operação;
- Árvore de histórico completo disponível off-line;
- Modelo distribuído, peer-to-peer.
Contras Git
- Curva de aprendizado para aqueles usados no SVN;
- Não é ideal para desenvolvedores únicos;
- Suporte limitado do Windows comparado ao Linux.
Estrutura do sistema GIT
O Git tem várias qualidades: é popular principalmente entre projetos open source, é rápido (com algumas ressalvas: veja por que o Facebook escolheu o Mercurial ao invés do Git) e tem um bom design interno.
Porém, simplicidade não está entre essas qualidades. Pelo contrário, o Git é bastante complexo e sua interface é inconsistente e pouco intuitiva.
A complexidade do Git aparece de várias formas, uma delas é no seu modelo de comandos transporte:
Há vários lugares onde os arquivos podem estar: stash, diretório de trabalho (working tree na terminologia do Git), index (também chamado de stage area ou cache), repositório local e remoto.
A área stash é opcional, mas o index não pode ser evitado completamente. Trata-se de uma área intermediária de preparação para a geração da revisão.
>>Leitura Recomendada: Leia nosso manual prático sobre o banco de dados NoSQL
Alerta de Spoilers!
Pós- Créditos: Mercurial
Aproveitando o conteúdo, vamos falar sobre outro version control, pouco usado porém, vale a pena conferir (vingador secundário). Este chama-se MERCURIAL!
O Mercurial começou perto do mesmo tempo que o Git e também é uma ferramenta de controle de revisão distribuída.
Ele foi feito originalmente para competir com o Git para desenvolvimento de Kernel Linux e, como o Git foi selecionado, o Mercurial tem tido menos sucesso nessa área.
No entanto, isso não quer dizer que não é usado. O OpenOffice.org, por exemplo, usa Mercurial.
É diferente de outros sistemas de controle de revisão em que o Mercurial é implementado principalmente em Python, em oposição a C, mas há algumas instâncias em que C é usado.
Devido à sua natureza distribuída e sua criação em Python, os desenvolvedores de linguagem Python estão considerando uma mudança para o Mercurial, pois permitiria que desenvolvedores não-essenciais tivessem acesso mais fácil à criação de novas árvores e à reversão de mudanças.
Os usuários notaram que o Mercurial compartilha alguns recursos com o SVN, além de ser um sistema distribuído. Devido às semelhanças, a curva de aprendizado para aqueles já familiarizados com o SVN será menos acentuada.
A documentação do Mercurial também é mais completa e facilitará o aprendizado das diferenças mais rapidamente.
Algumas das principais desvantagens do Mercurial incluem que ele não permite que dois pais sejam mesclados e, ao contrário do Git, ele usa um sistema de extensão em vez de ser programável por scripts.
Isso pode ser ideal para alguns programadores, mas muitos acham que o poder do Git é um recurso que eles não querem negociar.
O Mercurial é bem documentado e usado em muitos projetos bem conhecidos. 🙂
Para descobrir qual é o melhor para você, considere o projeto e os desenvolvedores. E fale com eles, abra debates sempre
A primeira decisão que você precisará tomar é se a escolha se ajusta às necessidades do seu negócio e da sua equipe, e então – tão importante quanto – você deve ter certeza de que sua escolha não vai enfurecer sua equipe de codificação.
Bem, cansei de falar (ou melhor, escrever) e acredito que me prolonguei até demais.
Procurei ser curto e grosso , falando apenas o necessário a nível de conhecimento (um exemplo claro é o CVS e o Mercurial). 😀
Eles já devem ser desconsiderados de cara, tendo os motivos já justificados acima (se não ficou claro, sugiro que leiam novamente ). Com isso, sobraram duas opções que devem ser avaliadas de acordo com a sua necessidade e de seus projetos.
E sim, existem formas de mesclar SVN e GIT, porém, isso é assunto para ooooooutro artigo, que só será escrito caso este faça bastante sucesso. Sendo assim, não esqueça de ler, curtir, comentar, compartilhar e tudo com ar e ir, dessa forma você ajuda que este tipo de assunto continue sendo divulgado.
Bem, agora eu me despeço e, espero que tenham gostado. Agora vou trabalhar que é melhor.
Abraços de seu sempre amigo da vizinhança — não é o homem aranha — Bruno Rafael.
