Desenvolvimento de Software: Ferramentas além da IDE - Parte 2

Nas edições 92 e 93 da Java Magazine, foram publicadas as duas primeiras partes desta série de artigos que tem como objetivo abordar ferramentas além da IDE que auxiliem desenvolvedores de software a realizar seu trabalho. A maioria das profissões hoje em dia utiliza sistemas de informação para automatizar e auxiliar nas tarefas do dia a dia, e a informática certamente não seria a exceção. Pelo contrário, é uma das áreas para as quais existe uma enorme diversidade de ferramentas que auxiliam nas inúmeras atividades que podem estar presentes em um processo de desenvolvimento de software.

Focando nas atividades de codificação (implementação) e testes de um sistema de informação, foram citadas nos artigos anteriores desta série algumas subatividades bastante comuns e que geralmente acompanham uma ou mais ferramentas que auxiliam em sua condução: criação e edição do código-fonte; compilação, execução e depuração; criação e manipulação de um banco de dados; construção (build) e gerência de dependências; realização de testes unitários; compartilhamento com controle de versão; gerenciamento de falhas (bugs) e novas funcionalidades; análise de desempenho (profiling); integração contínua; dentre outras...

O objetivo desta série de artigos é abordar as subatividades do processo de software citadas acima, demonstrando ferramentas (preferencialmente gratuitas e de código-fonte aberto) que auxiliem o desenvolvedor em sua execução. Espera-se contar, também, com sugestões dos leitores para inclusão de outras tarefas/ferramentas na lista anterior.

Na primeira parte da série, foram abordadas as tarefas de criação, edição, compilação, execução e depuração de código-fonte utilizando a IDE – exemplos com Eclipse e NetBeans – e, para aplicações Web/corporativas, os respectivos servidores – sendo Tomcat e GlassFish utilizados como exemplo. Além disso, a parte 1 também incluiu a criação e manipulação de um banco de dados – MySQL e PostgreSQL sendo escolhidos para demonstração –, mostrando tanto a integração das próprias IDEs quanto a utilização de uma ferramenta externa, o SQuirreL.

Já na segunda parte, o foco foi dado às tarefas de automação da construção (build) – Maven e Ant são os exemplos –, gerenciamento de dependências – Maven novamente e Ivy para integração com o Ant – e testes unitários – exemplos apresentados com o JUnit.

Nesta, que é a terceira parte da série, o foco serão as ferramentas de controle de versão. Tais ferramentas permitem que diversos desenvolvedores compartilhem o código-fonte de um mesmo projeto a partir da manipulação de repositórios de código que, como poderá ser visto ao longo do artigo, podem ser centralizados ou distribuídos. A primeira seção do artigo explica o que são e como funcionam as ferramentas de controle de versão para, nas seções seguintes, serem apresentadas demonstrações de como integrá-las ao ambiente de desenvolvimento.

Como nos artigos anteriores, continuarão a ser utilizadas as IDEs NetBeans e Eclipse e o projeto EngeSoft introduzido na parte 1. E dado que já foram apresentadas ferramentas de automação da construção (build) na parte 2 da série (em particular Ant e Maven), serão apresentadas também neste artigo instruções para integração do controle de versão ao build da aplicação.

O que é controle de versão (version control)?

O controle de versão, também conhecido como controle de revisões (revision control) ou controle de código-fonte (source control), consiste em armazenar e gerenciar diferentes versões de arquivos que compõem um projeto de desenvolvimento de software ao longo do tempo. Uma ferramenta de controle de versão geralmente oferece as seguintes funcionalidades a um desenvolvedor:

• Armazenamento (backup) e restauração: arquivos são salvos no repositório do projeto, associados à data/hora na qual foram armazenados. Em qualquer momento, o desenvolvedor pode visualizar o conteúdo dos arquivos em qualquer uma de suas versões antigas armazenadas, além de poder também restaurá-las, ou seja, substituir o conteúdo atual do arquivo pelo conteúdo de uma versão anterior;
• Sincronização: quando o projeto é desenvolvido não só por um, mas por um time de desenvolvedores, permite que todos se mantenham sincronizados com as últimas versões dos arquivos do projeto com uma única operação;
• Autoria: somente arquivos novos ou alterados são enviados ao repositório e cada envio é associado ao autor das alterações, o que permite identificar os responsáveis por cada parte do projeto em caso de necessidade. Além disso, cada alteração pode ser associada a um comentário por parte do autor, que permite aos demais desenvolvedores compreender o motivo da mesma;
• Ramificação: quando criado, um repositório possui uma área comum chamada “tronco” (trunk) na qual todos os arquivos são colocados. Caso um desenvolvedor queira criar uma versão alternativa do projeto (ex.: para experimentar algumas funcionalidades diferentes) poderá fazer uma cópia de todos os arquivos, criando um ramo (branch). Posteriormente, caso queira (ex.: os experimentos deram certo), o desenvolvedor pode efetuar a fusão (merge) do conteúdo do ramo com o conteúdo do tronco.

A atividade se popularizou bastante com o lançamento da primeira ferramenta open source para controle de versão em 1990, o CVS. Dez anos depois, uma empresa chamada CollabNet iniciou a construção do Subversion (também chamado de SVN, veja Links), uma ferramenta similar ao CVS, porém sem algumas de suas falhas e com funcionalidades extras. O Subversion foi lançado em 2004 e é hoje a ferramenta de controle de versão estilo cliente–servidor mais popular.

Mesmo antes de seu lançamento, porém, começaram a surgir ferramentas de controle de versão que seguiam um estilo distribuído, baseado no paradigma peer-to-peer. Ao contrário das ferramentas cliente–servidor, que armazenam as informações em um computador central e exigem que os desenvolvedores estejam conectados para utilizarem o controle de versão, as ferramentas distribuídas mantêm repositórios separados em cada máquina cliente, permitindo que os desenvolvedores trabalhem nos mesmos ainda que estejam off-line.

Para sincronização, os desenvolvedores enviam uns aos outros patches (arquivos que descrevem as alterações feitas). Em um time de desenvolvimento, o repositório de um dos desenvolvedores (ou da organização como um todo, gerenciado por um de seus membros) pode ser considerado o repositório central e todos enviam seus patches a este repositório para que sejam feitas as fusões necessárias.

Nas seções a seguir, será mostrado o funcionamento de uma ferramenta de cada tipo. No lado cliente–servidor foi escolhido o Subversion, por ser a ferramenta de código aberto mais popular deste tipo. Já como controle de versão distribuído, será usado como exemplo o Git (veja Links), um sistema de controle de versão distribuído criado por Linus Torvalds (criador do Linux) para ser utilizado pelos desenvolvedores do Kernel (núcleo) do Linux.

Subversion

Para começar a utilizar o Subversion e assim experimentar suas funcionalidades é preciso ter um repositório em um servidor central pois, como já dito, o Subversion é uma ferramenta de controle de versão cliente–servidor. Neste ponto será preciso escolher dentre duas alternativas: criar um servidor em uma máquina local ou utilizar um serviço de hospedagem de projetos que tenha suporte SVN.

Na seção Links, indicamos sites com instruções para instalação do servidor Subversion no Ubuntu Linux e no Windows, porém uma busca no Google certamente apresentará muitas outras páginas similares dentre as quais o leitor poderá escolher a que preferir. Caso prefira utilizar um serviço de hospedagem na Internet, veja também em Links o endereço de um site que compara diversos serviços de hospedagem SVN.

Para este artigo foi escolhido o site Google Code (veja Links), que oferece hospedagem gratuita para projetos de desenvolvimento open source, com suporte SVN e Mercurial (uma outra ferramenta de controle de versão, porém distribuída). Foi criado um projeto para a EngeSoft, aplicação de exemplo que estamos utilizando desde a primeira parte desta série, no endereço http://code.google.com/p/engesoft-jm/. Clicando na aba Source o leitor poderá obter o código do projeto via SVN, como será demonstrado nesta seção.

Subversion no Eclipse

Começando com o Eclipse (utilizando a última versão disponível, o Eclipse Indigo, distribuição for Java EE Developers), será preciso instalar um plug-in para suporte ao SVN. Destacamos duas alternativas, o Subversive e o Subclipse (veja Links), sendo que o primeiro será utilizado no artigo. Para instalar o Subversive, utilize a função de instalação de novas funcionalidades do próprio Eclipse e procure pelo item Subversive SVN Team Provider no repositório do Eclipse Indigo.

Partindo do projeto EngeSoft criado na primeira parte desta série de artigos (se preferir, crie um novo Dynamic Web Project e adicione uma página index.html para que o projeto tenha algum conteúdo), para armazenar seu conteúdo no repositório do servidor basta clicar no projeto com o botão direito do mouse e escolher a opção Team > Share Project.... O assistente para compartilhamento do projeto se abrirá, pedindo que especifique qual ferramenta de controle de versão deseja utilizar. Escolha SVN e clique Next.

Forneça os dados sobre o repositório no servidor como mostra a Figura 1. Os seguintes campos deverão ser preenchidos nesta parte do assistente:

• URL: o endereço do repositório (no nosso caso é o endereço fornecido pelo Google Code ao abrir a sua aba Source);
• User: seu nome de usuário, caso o serviço de hospedagem exija autenticação (no Google Code é o e-mail associado à sua conta Google);
• Password: senha associada ao seu nome de usuário, caso o serviço exija autenticação (no Google Code é uma senha gerada especificamente para este acesso, e não a senha da sua conta Google. Veja mais detalhes na aba Source do site);
• Save authentication: marque esta opção se você não quiser inserir a sua senha do SVN a cada vez que o Eclipse acessar o servidor.

Figura 1. Configuração para compartilhamento do projeto EngeSoft no Eclipse usando SVN.

Ao clicar em Next, o Eclipse perguntará se você deseja normalizar a URL do projeto (Figura 2), pois ela se refere a um dos recursos do repositório (o tronco). Clique em No, para que os arquivos sejam colocados dentro do tronco, e não diretamente na raiz do repositório. Confirme todos os dados e finalize o assistente para que o Eclipse entre em contato com o servidor e faça as devidas verificações.

Figura 2. Confirmação da normalização da URL do projeto.

Se tudo estiver OK, a janela representada na Figura 3 se abrirá para que você possa selecionar os arquivos que farão parte deste commit. Um commit é uma confirmação que o desenvolvedor concluiu seu trabalho em um conjunto de arquivos e os mesmos podem ser arquivados no controle de versão e compartilhados com os demais membros do projeto. A janela é dividida em duas partes principais: na parte superior é possível fornecer um comentário que será associado ao commit, podendo escrever um comentário novo no campo texto ou escolher um comentário utilizado anteriormente no menu drop-down que encontra-se logo abaixo. Na parte inferior os arquivos que serão enviados ao servidor devem ser escolhidos, sendo que o Eclipse automaticamente seleciona todos os arquivos do projeto exceto as classes compiladas.