Controle de versão de software: tire aqui suas dúvidas
Se você trabalha com desenvolvimento de aplicações, ou mesmo na criação de layouts/recursos de front-end mais ligados à usabilidade, certamente vai compreender as dificuldades que o controle de versão de software se propõe a solucionar!
- Quantas vezes você, sem querer, sobrescreveu um código escrito por um colega, resultando em falhas substanciais no sistema final, como vazamento de informações em mensagens de erro, encoding errado no output (codificação ou escape impróprios de saída), falha ao preservar a estrutura do código da página, etc.?
- Quantas vezes detectou alterações no código-fonte, sem, no entanto, conseguir identificar quem promoveu as mudanças e por qual razão?
- Já viu projetos atrasarem por causa da Torre de Babel ocasionada pela codificação simultânea de dezenas de programadores (que não conseguem sincronizar seus trabalhos), gerando erros de lógica, de sintaxe ou compilação?
Se esses obstáculos são recorrentes no workflow dos projetos em sua empresa, a razão está certamente na ausência de um sistema de controle de versão de software (o que, com tantas opções de sistemas de versionamento open source, não é algo comum, convenhamos).
Por outro lado, pode ser que sua empresa até tenha adotado algum método de controle de versão, mas sem alcançar a sincronia e a eficiência no trabalho em equipe que você esperava.
Seja por uma razão ou por outra, este post foi elaborado para ser um miniguia sobre o tema, mostrando o que é controle de versão, como funciona a transferência dos arquivos para os repositórios, quais os sistemas mais usados e, é claro, como o versionamento pode auxiliar no aumento do fluxo de entregas para quem trabalha com metodologias de desenvolvimento ágil. Confira!
Entenda o conceito de controle de versão
Segundo Bolinger & Bronson, o primeiro sistema de controle de versão de software surgiu ainda em 1972. Batizado de Source Code Control System (SCCS), esse sistema foi o mais importante recurso de sincronia de arquivos até o desenvolvimento do RCS (Revision Control System), lançando as bases para a criação de novos sistemas mais modernos em recuperação de versões antigas de arquivos.
Para quem não está muito habituado com o assunto, controle de versão é um sistema que registra todas as alterações realizadas em um arquivo (ou em um grupo de arquivos), permitindo que os usuários possam resgatar versões específicas (check out).
Embora esse recurso seja primordialmente utilizado pelos desenvolvedores web, é possível usar um sistema de controle de versão nas mais diversas atividades. Seria o caso, por exemplo, da possibilidade de um designer recuperar versões anteriores de layout em andamento.
Descubra como funciona o controle de versão
Os projetos de desenvolvimento de software, em geral, envolvem dezenas, às vezes, centenas de pessoas. O gerente de projeto tem o (árduo) desafio de gerenciar recursos, colaboradores, requisitos e prazos. Não é uma tarefa fácil, especialmente quando nos lembramos que os códigos-fontes são escritos e reescritos milhares de vezes.
Para piorar, todas as linhas são criadas simultaneamente por pessoas diferentes. Ou seja, em algum momento, será necessário integrar todo o trabalho da equipe, algo impossível de ser feito manualmente. É aqui que entra o controle de versão de software (Version Control System ou VCS).
O funcionamento do controle de versão varia em cada sistema (local, centralizado ou distribuído, os quais veremos adiante). Entretanto, em essência, um sistema de versionamento é capaz de gerenciar todos os comandos executados na edição de um arquivo, salvando a sequência de alterações, de forma independente, em um determinado repositório.
Esse recurso abre portas para uma mudança profunda no workflow da equipe. Os Sistemas de Controle de Versão Distribuídos, por exemplos, permitem:
- ter um diagnóstico detalhado do processo evolutivo do projeto;
- controlar o trabalho da equipe com facilidade, sabendo, inclusive, quais as alterações feitas por cada desenvolvedor (com detalhes como data/horário das inserções);
- sincronizar melhor as tarefas do time de TI, culminando em entregas mais rápidas e com menor percentual de bugs;
- garantir maior proteção aos arquivos utilizados no processo de desenvolvimento de software; etc.
Conheça os tipos de controle de versão
1. Sistema de Controle de Versão Local
O mais elementar modelo de versionamento (e também o mais suscetível a falhas). Nesse formato, dos primórdios do controle de versão, os arquivos são simplesmente copiados para diretórios locais. Ou seja, haverá, concorrentemente, dentro do mesmo computador, os arquivos atuais e suas cópias. Nem precisa ser muito criativo para imaginar os problemas dessa limitação, certo?
O primeiro problema do controle de versão de software local (VCS local) foi que ninguém conseguia trabalhar em equipe (simultaneamente), uma vez que não havia comunicação instantânea entre as máquinas-clientes para agregar os arquivos modificados.
O segundo era que, se algo ocorresse com seu computador, todo o trabalho seria perdido definitivamente. Não parece muito atraente, concorda?
Por fim, a terceira desvantagem se refere aos riscos de você, por engano, acabar sobrescrevendo arquivos sem querer, gravar algum código no arquivo errado ou não conseguir localizar o repositório.
Uma das ferramentas de controle de versão local mais conhecidas é o RCS, desenvolvido ainda em 1982, como uma evolução do Source Code Control System (SCCS), citado acima. O RCS ainda é distribuído em muitos computadores (incluindo o Mac OS X), mesmo que seja obsoleto.
Apesar de ser um dos primeiros sistemas de controle de versão, a permanência do RCS no mercado se dá pela sua simplicidade, bem como pelo fato de ainda ser uma ferramenta extremamente útil para textos que são revisados continuamente (como documentações e gráficos processuais).
2. Sistema de Controle de Versão Centralizado
O controle de versão local deu aos desenvolvedores a possibilidade de recuperar versões específicas dentro de suas próprias máquinas. O problema é que essa individualização dos patches (diferenças entre os arquivos) impedia o trabalho em conjunto com outros desenvolvedores. Essa dificuldade motivou a criação de uma versão evoluída do VCS local, o chamado Sistema de Controle de Versão Centralizado (Centralized Version Control System ou CVCS).
Esse controle de versão de software foi criado em torno de uma arquitetura cliente-servidor, na qual existe um servidor central que agrega todos os arquivos versionados pela equipe de desenvolvimento. Agora, além da possibilidade de resgate dos arquivos (check out), já era possível também ter vários desenvolvedores atuando simultaneamente sobre o mesmo projeto.
A rotina básica dos desenvolvedores que escrevem seus códigos sob o suporte de um sistema de controle centralizado começa pela execução do comando check out, por meio do qual é carregada uma cópia do projeto em sua área de trabalho.
Para trazer as versões atualizadas, é necessário executar o comando update. Por fim, após promover novas alterações, o comando commit deve ser acionado, a fim de remeter as modificações realizadas ao repositório.
As evoluções entre os modelos locais e centralizados são visíveis:
- o administrador consegue gerenciar melhor o que cada um produz;
- o desenvolvedor tem, agora, um conhecimento mínimo do que seu colega está codificando, o que ajuda na percepção de erros de sintaxe, semântica, etc.
- a integração permanente dos arquivos em um servidor confere mais rapidez no desenvolvimento do projeto.
Todas essas vantagens fizeram desse formato, por muitos anos, um sinônimo de controle de versão. Mas ainda havia ineficiências, que foram percebidas ao longo do uso de sistemas como CVS, Subversion e Perforce.
A principal delas é que a extrema dependência do servidor era perigosa. Da mesma maneira que no VCS local, todas as versões dos arquivos estavam em uma única máquina (servidor).
Ou seja, se esse servidor ficasse fora do ar por 2 horas, a equipe toda deixaria de gravar novas versões. Além disso, se houvesse alguma falha nesse ponto exclusivo de gravação, todo o trabalho seria perdido.
Essa constatação foi a ignição para o surgimento de um novo modelo de controle de versão de software: o controle distribuído.
3. Sistema de Controle de Versão Distribuído
Eis a última palavra em sistema de versionamento. No chamado DVCS (Distributed Version Control System), os clientes não fazem mais cópias das últimas versões dos arquivos no servidor: eles são os próprios repositórios das alterações realizadas.
Sim, o repositório exclusivo alocado em um servidor central dá lugar a um sistema que, além das cópias armazenadas no servidor, multiplica a cópia total de tudo o que é feito nas máquinas-clientes.
Assim, se o servidor falhar, quaisquer dos repositórios autônomos e independentes, instalados em todos os computadores, podem ser usados para restaurar o conteúdo danificado. Perceba que, no controle de versão de software distribuído, o check out é também o backup completo das versões produzidas.
A rotina dos programadores que trabalham com esse sistema é similar à dos que atuam com o sistema centralizado. As diferenças principais são que, no formato distribuído, o check out é chamado clone, os comandos commit e update ocorrem localmente e a sincronização dos repositórios é feita por meio das operações pull e push.
Enquanto o comando pull atualiza o repositório local com as alterações externas realizadas, o comando push faz exatamente o contrário: remete as alterações feitas localmente aos repositórios externos.
Principais controles de versão usados no mercado de desenvolvimento de software
1. Sistema de Controle de Versão Local
RCS (Revision Control System)
O RCS foi o 2º controle de versão de grande impacto, mas é mantido até hoje pelo GNU Project. Desenvolvido em 1982 por Walter Tichy, o RCS usava técnicas mais avançadas do que o pioneiro SCCS. Sua fragilidade estava em sua capacidade de trabalhar apenas com arquivos individuais e não com projetos inteiros.
2. Sistema de Controle de Versão Centralizado
- CVS (Concurrent Version System)
Consequência da necessidade de resgatar versões específicas de diversas máquinas, o CVS foi criado em 1984 por Dick Grune, apresentando a vantagem de ser o primeiro sistema a conseguir agregar múltiplos arquivos. Suas especificações são a base dos outros tipos de controle de versão de software que o sucederam.
O CVS funciona sobre o binômio “histórico/estado das versões”, ou seja, ele mantém o histórico (com informações sobre quem fez cada modificação, em que data e horário), bem como os respectivos versionamentos do arquivo ao longo do tempo.
Além disso, o CVS integra todas as atividades realizadas em um mesmo projeto por diferentes desenvolvedores, uma vez que o servidor do sistema assume papel central na troca de informações, possibilitando que diversos profissionais trabalhem remotamente de forma colaborativa.
Links interessantes:
- SVN Subversion
Conhecido como SVN, o Apache Subversion é um controle de versão de código aberto desenvolvido em 2000 pela CollabNet. Atualmente, entretanto, é um software mantido como um projeto da Apache Software Foundation.
A proposta do SVN era oferecer uma estrutura semelhante ao CVS (arquitetura similar, com modelo cliente-servidor), corrigindo, entretanto, algumas deficiências do seu antecessor. O SVN, por exemplo, é multiplataforma, o que permite que clientes com diferentes SOs visualizem o mesmo servidor que mantém o repositório.
O SVN trabalha com operações atômicas e é extremamente flexível, sendo capaz de manter o histórico mesmo após a execução de comandos como mover, copiar ou renomear, uma novidade em relação aos controles de versão anteriores.
Nesse modelo, o cliente fica com uma cópia local de seus arquivos e faz a atualização periódica (e a sincronização) por meio do acesso ao servidor, que se dá nos limites configurados pelo administrador, por um endereço local ou uma URL.
Tutorial Subversion para Mac OS X
Tutorial Subversion para Windows
- Perforce
Conhecido como P4, o Perforce é uma ferramenta de controle de versão de software muito popular entre os desenvolvedores devido à sua robustez, extensa quantidade de avaliações e disponibilidade de suporte. Aliás, esse sistema tem a reputação de prover um nível de suporte fora do comum.
Diferentemente de algumas aplicações comerciais, o Perforce enfatiza a versatilidade: está disponível nas plataformas mais “obscuras” (como IBM OS/390 e Open WMS). Além disso, essa ferramenta provê algumas funcionalidades que não estão presentes no CVS. Lida muito bem como arquivos binários e suporta operações atômicas. Diferentemente do CVS, Perforce tem seu próprio modelo de segurança.
3 Sistema de Controle de Versão Distribuído
- Git
Desenvolvido desde 2005, o Git foi inicialmente concebido para o Kernel (núcleo) do Linux. Sua criação começou quando diversos desenvolvedores Kernel Linux resolveram deixar o BitKeeper, um controle de versões distribuído que passou a ser pago quando o detentor dos direitos autorais da ferramenta optou por torná-la proprietária.
É muito usado em projetos open source e possui algumas características marcantes, como concepção simples (mas poderosa), adequação a grandes projetos e velocidade. A maior parte das operações no Git necessita apenas de recursos locais para operar, o que explica sua velocidade maior do que os demais sistemas.
Não há mais servidores centrais como no SVN. Dentre alguns que usam o Git, podemos mencionar Linux Kernel, Wine e Fedora. Para assimilar bem o trabalho com essa ferramenta, o ideal é não pensar no funcionamento de outros VCSs, como Perforce ou Subversion, isso porque, apesar de ter interface similar, o Git pensa as informações de forma diferente dos outros tipos de controle de versão de software.
Tecnicamente, a maioria dos controles de versão organiza os patches em uma lista de mudanças por arquivo, formando uma espécie de estrutura hierarquizada. O Git, por outro lado, enxerga os dados como um conjunto de snapshots (captura de um instante). Dessa forma, quando você faz o commit no Git, seria como se ele tirasse uma fotografia daquele momento. Caso nada tenha sido alterado, as informações não são armazenadas novamente.
Essas especificações fazem do Git muito mais um minissistema de arquivos — com incríveis recursos agregados — do que meramente um VCS.
Links:
Gui-Git – multiplataforma de interface para Git
Downloads, documentações e acesso à comunidade Git.
- Mercurial
Mercurial é mais um controle de versão de software distribuído. Da mesma forma que o Git, o release 0.1 do Mercurial foi lançado em 2005, quando um grupo de desenvolvedores decidiu deixar de utilizar o BitKeeper. O nome faz referência ao deus mitológico cujas características eram a inteligência, a eloquência e a rapidez. De fato, o Mercurial VCS tem todos esses atributos.
O sistema foi criado para suportar o desenvolvimento de projetos de grande porte, muito além de pequenos trabalhos de designers/desenvolvedores independentes. Essa ênfase nos trabalhos de grande envergadura não significa, entretanto, que times enxutos não possam utilizar o Mercurial.
Trata-se de um modelo mais simples que o Git, com funções similares a outros sistemas distribuídos. Apesar possuir interface funcional e armazenamento eficiente, o Mercurial não foi escolhido para gerenciamento do código do Kernel do Linux. Adotou-se o Git como padrão.
Embora tenha sido desenvolvido inicialmente pensando no Linux, o Mercurial acabou, ao longo do tempo, apresentando melhor desempenho em outros SOs: foi desenvolvido em Python e, portanto, funciona muito bem em qualquer sistema operacional compatível com essa linguagem (Linux, Windows e até o Mac OS X).
Com ótima documentação disponível, o Mercurial apresenta ótima interoperabilidade. Foram criados plug-ins para várias IDEs (ambientes de desenvolvimento), como é o caso do Mercurial Eclipse para o Eclipse, além dos plug-ins para Visual Studio e NetBeans.
Assim como no Git e no Subversion, o comando commit é atômico, ou seja, se a operação for suprimida no meio do processo, as alterações são desconsideradas, garantindo que o repositório não ficará “fragmentado”. No Mercurial, os comandos para propagar as modificações entre os repositórios são o hg push e o hg pull.
Este link traz uma comparação interessante entre o desempenho do Subversion, Git e Mercurial. Outros links:
Lista de ferramentas – Mercurial.
- Bazaar
Muito semelhante ao Mercurial e ao Git. Alguns links úteis sobre a ferramenta:
Configurando o Bazaar em 5 minutos;
Diferenças entre Bazaar e Git.
Vantagens do controle de versão no desenvolvimento ágil
A força-motriz das metodologias de desenvolvimento ágil é a integração entre colaboradores, algo que um controle de versão faz com perfeição. Essa espécie de “máquina do tempo” dos arquivos oferece vários benefícios a quem atua com método ágil:
Criação de tags
Diferentemente das metodologias tradicionais, em que entregas são feitas apenas nas fases finais do projeto, os métodos ágeis trabalham com entregas a cada iteração.
Assim, as sucessivas entregas exigem que haja controles que permitam reverter arquivos em caso de falhas. Os sistemas de controle de versão de software oferecem suporte à marcação (criação de tags), o que fornece uma visão clara de cada etapa do processo.
Facilidade na atuação conjunta
O foco no desenvolvimento ágil é a entrega contínua. Com isso, é preciso ter diversos profissionais atuando juntos sobre o mesmo projeto, sem que haja risco de que um sobrescreva o código do outro.
Rastreamento de todo o processo evolutivo dos arquivos
Nas metodologias ágeis, são dezenas de desenvolvedores trabalhando simultaneamente sobre a mesma aplicação. Caso haja erros (por exemplo, má validação de dados do usuário) é preciso saber onde ele se originou, quando e quem o gerou. O controle de versão permite esse rastreamento, auxiliando na solução de conflitos entre versões ou detecção de falhas com mais rapidez.
DevOps & controle de versão
O DevOps é a base fundamental para a transformação da TI. Afinal, ninguém discordaria que rapidez e inovação são dois pilares básicos para o sucesso dos negócios em uma sociedade digital, certo?
A cultura DevOps representa uma mudança de mentalidade das equipes de TI, saindo das entregas complexas, a cada 6 meses, para um universo dinâmico de integração total entre os membros do time de tecnologia (com entregas múltiplas, rápidas e participação de todos os stakeholders, desde o início do projeto).
A busca incessante pela integração contínua entre os times de desenvolvimento e operações (que, nesse novo modelo, passam a trabalhar simultaneamente) exige a presença de ferramentas ágeis, baseadas na automação de processos.
O objetivo desses recursos é multiplicar a frequência de deployments, prover taxas de failures ínfimas e deixar o lead time do projeto mais curto. É nesse contexto que o controle de versão de software e o deploy automatizado se consolidam como as mais poderosas ferramentas para o sucesso dessa abordagem ágil.
Desde a década de 60, a Engenharia de Software tem buscado novos métodos e ferramentas para assegurar o sucesso dos projetos. Ultimamente, entretanto, a inserção da tecnologia no centro de todos os processos humanos intensificou a necessidade de prover entregas mais céleres, com melhor qualidade e menor custo.
As metodologias pesadas (tradicionais) de desenvolvimento de software (construídas sob a influência de métodos usados na Engenharia Civil/Elétrica) não mais conseguiam dar conta das demandas do mundo da TI no novo milênio. Planejamento rígido, centralização, entrega apenas no final do projeto e forte enfoque na documentação geravam, invariavelmente, violações de prazo, aumento de custos e baixa produtividade.
Os métodos ágeis redefiniram a forma de trabalhar em um projeto de TI, trazendo, com eles, novas ferramentas de eficiência, tais quais a incorporação do já existente controle de versão de e as automações, como base de seu dinamismo operacional.
Nos negócios digitais da atualidade, é preciso atuação conjunta na solução de problemas, maior foco na usabilidade do que nas documentações, forte participação do cliente em todas as etapas do processo e, é claro, entregas contínuas. Esse ambiente intenso torna imprescindível o uso de VCSs como os descritos neste post.
É evidente que apenas utilizar um sistema de controle de versão de software não é sinônimo de sucesso; o êxito de um time de TI advém do uso de um conjunto de estratégias, abordagens e recursos modernos, como metodologias ágeis, cultura DevOps, continuous deployment, provas de conceito e, evidentemente, os controles de versão.
E então, ficou com alguma dúvida a respeito do assunto? Deixe seu comentário que responderemos o mais rápido possível!
