Blog Pronus

A Pronus acaba de lançar duas máquinas virtuais prontas para uso, denominadas de PronusBox, contendo servidores de aplicação direcionados à Gerência de Configuração de Software (GCS). Cada PronusBox possui uma ferramenta de controle de mudança e de controle de versão previamente instaladas e configuradas para operarem de modo integrado, conforme diretrizes específicas de GCS.

A primeira PronusBox contém o Trac como controle de mudança e o Subversion como controle de versão. A segunda PronusBox disponível usa o Redmine para controle de mudança e o Subversion e o Mercurial como opções de controle de versão centralizado e distribuído respectivamente.

A proposta é cobrar por cada máquina uma fração do valor em horas técnicas que seriam usadas para a instalação e configuração de um servidor a partir do zero. Com uma estimativa bastante otimista de 60 horas técnicas para a preparação de um servidor equivalente, o preço de cada PronusBox varia entre R$ 300 e R$ 350.  Como promoção de lançamento, neste mês de janeiro, oferecemos um desconto de 28,5% por cada PronusBox. Aproveite!

No artigo anterior, apresentei o caso em que “Roberval” — um típico integrante de uma equipe de administração de redes — executou a tarefa de instalar um servidor de aplicação com Redmine e Mercurial para a equipe de desenvolvimento. Demorou vários dias para terminar e mesmo assim, ainda ficou faltando alguns ajustes.

O desfecho poderia ter sido outro, mais  simples e rápido. O começo seria igual, com Roberval recebendo a incumbência de instalar o servidor com Redmine e Mercurial. Porém, ao invés de preparar um servidor, prefere procurar uma solução pronta. Como os servidores da empresa já usam virtualização, então o ideal seria uma máquina virtual pré-configurada com as aplicações desejadas que pudesse ser baixada, instalada sem maiores dificuldades.

Uma procura rápida no Google com os termos “máquina virtual redmine mercurial” mostra um resultado bastante interessante logo na primeira opção. A especificação da PronusBox (a máquina virtual encontrada) descreve em detalhes a configuração existente e alguns procedimentos administrativos como criação de projetos e backup. Não há dúvida: é essa mesma.

O passo seguinte é conseguir a verba para aquisição.  Como o pedido de instalação já havia sido aprovado, a verba para aquisição da máquina virtual foi liberada sem maiores dificuldades. Além do mais, o preço é irrisório.

O que demorou mais tempo foi baixar os 750 MiB da máquina virtual. Depois disso, conforme esperado, a instalação foi simples e o serviço estava no ar. Ao invés de duas semanas preparando um servidor, tudo pronto em menos de um dia! Chefe contente e  desenvolvedores satisfeitos.

A virtualização de servidores traz algumas vantagens bastante interessantes:

1. Otimização dos recursos disponíveis. O mesmo servidor físico pode ser multiplicado em vários servidores virtuais, economizando equipamento e energia.
2. Independência de plataforma. Uma máquina virtual pode conter um sistema operacional diferente da máquina hospedeira.
3. Flexibilização através de Máquinas Virtuais. Podem ser instaladas, trocadas, congeladas, salvas e até mesmo adquiridas prontas para uso com facilidade.

A aquisição de uma máquina virtual com um servidor de aplicação costuma ser extremamente viável. Afinal, preparar um servidor de aplicação é trabalhoso e complicado. Entender as aplicações desejadas, descobrir as dependências, pesquisar e testar alternativas de configuração e analisar os resultados é bastante demorado, chegando facilmente a semanas de trabalho.

Uma caso possível (baseado em fatos reais):

“Robervaldo faz parte da equipe de administração de redes de uma empresa. Em uma segunda-feira qualquer, chega ao serviço e recebe a notícia que precisa preparar um servidor com o Redmine e o Mercurial (pra ontem, claro). Sem fazer a menor ideia do que sejam essas aplicações, só lhe resta recorrer ao Google. Descobre que Redmine é uma aplicação web para gerenciamento de projetos feita em Ruby on Rails e que Mercurial é uma ferramenta de controle distribuído de versão. O próximo passo é instalar.

Quase tão ruim quanto não achar nenhuma solução é achar dezenas delas. No site do Redmine existem várias e várias sugestões de como fazer a instalação em diversos sistemas operacionais e versões. Nenhuma dessas receitas é ‘oficial’, feita por membros do projeto; são todas feitas por colaboradores externos com diferentes graus de conhecimento da ferramenta. Algumas receitas estão claramente desatualizadas, mas continuam listadas no site. Outras recomendam passos e pacotes diferentes para instalação. Qual é a melhor maneira? O jeito é experimentar.

Robervaldo instala a versão mais nova do Ruby, mais a versão X do pacote tal e assim por diante. Mas opa! O Redmine na versão Y não funciona com o pacote tal na versão X nem com o Ruby mais atual! E agora? Desinstala tudo e começa de novo? A instalação bagunçou outros aplicativos que estavam instalados antes? Formata, ué.

Tem de escolher um tipo de banco de dados. Mas qual? Postgres? MySql? Sqlite3? Uni-duni-tê…

Passados três dias, depois de aprender que o teste de instalação deve ser feito em uma máquina virtual, usando snapshots, o Redmine parece estar funcionando. A próxima instalação é a do Mercurial.

Parece mais fácil. Poucas opções. Exe ou msi? Precisa ou não do TortoiseHg? Qual Python 2.X? Salamê-minguê…

Ah… não é só instalar, tem de publicar os repositórios pela rede. HTTP? SSH? NFS? Sorvete-colorê…

Uma semana se passou e o chefe em cima, cobrando. Robervaldo anda pelo corredor e os desenvolvedores que esperam o servidor olham torto. A demora deixa todo mundo tão irritado que nem a mulher do café o cumprimenta mais.

Mais dois dias. Acabou? Quase. Falta juntar o Redmine com o Mercurial. Robervaldo encontra um artigo promissor sobre integração dos dois. Epa! De 2009??? Funciona ainda? Outro link para autenticação do Apache pelo MySql. Também de 2009??? Mas e agora, Roberval, se você usou Postgres? Planos par ao fim de semana são cancelados…

Mais três dias e tudo entregue. Fim da história!?!

Epílogo: Duas horas tranquilas depois da entrega do servidor e o telefone toca. Coisa boa não deve ser:

- Roberval, o pessoal quer que o Redmine crie automaticamente os repositórios, precisa também fazer um script de backup e, aproveitando, dá uma olhada em como fazer blá blá blá…”

Mas tudo isso poderia ser mais simples. No próximo artigo, vamos abordar como a aquisição de uma máquina virtual economiza dinheiro e tempo, além de fornecer um servidor tecnicamente mais bem preparado.

O Mercurial chega à versão 1.7 com uma série de melhorias em diversas áreas. A lista completa das mudanças está disponível neste link.

O TortoiseHg continua seguindo os lançamentos do Mercurial e, nesta versão, além de acompanhar as mudanças da versão 1.7 do Mercurial também faz algumas pequenas correções. A lista está disponível aqui.

Não há dúvidas de que o controle de versão distribuído (Distributed Version Control System – DVCS) veio não só pra ficar, mas também para tomar o lugar das ferramentas de controle de versão centralizado. As etapas têm sido as mesmas de quando apareceu o Subversion com a proposta de substituir o CVS: 1. desconfiança, 2. curiosidade, 3. interesse, 4. aceitação.

Quem está tendo o primeiro contato com o DVCS geralmente cai na fase 1 (desconfiança). Não conhece como funciona e, por isso, desconfia. Afinal, se funciona do jeito que está (mesmo que não muito bem), pra que mudar?

O pessoal da fase 2 (curiosidade) já leu algo a respeito e está intrigado com as vantagens que “dizem” que o DVCS tem. Mas ainda falta um empurrãozinho para pelo menos tentar experimentar um DVCS pra ver como é.

O objetivo deste artigo é apresentar um experimento simples e rápido mostrando que o modo de trabalho de um DVCS, especificamente o Mercurial, não muda tanto assim do usado no Subversion. Espera-se com isso, levar o leitor mais perto da fase 3: interesse.

O experimento simulará dois usuários trabalhando no mesmo projeto, executando algumas operações bem comuns e básicas de controle de versão através do Mercurial, comparando sempre com o mesmo passo feito pelo Subversion.

Para aproveitar melhor o experimento, é necessário:

1. saber os conceitos básicos do controle de versão distribuído;
2. instalar o Mercurial ou o TortoiseHg na sua máquina;
3. já ter usado o Subversion e ter ele ou o TortoiseSvn instalado na máquina;

Observação: O experimento será apresentado com operações pela linha de comando por questão de espaço e comodidade. O experimento pode ser feito também através das interfaces gráficas TortoiseHg e TortoiseSVN, que possuem os mesmos comandos usados no roteiro.

1. Preparando os Repositórios

Quando se sabe que no DVCS cada desenvolvedor tem um repositório e que um repositório pode se conectar com qualquer outro, logo se imagina que o modelo distribuído é uma anarquia. Na verdade, qualquer desenvolvimento sem regras vira uma bagunça. No modelo distribuído, os repositórios podem ser arranjados em várias topologias e a topologia cliente-servidor é uma delas.

Vamos criar 3 repositórios: um oficial, um para um user 1, e outro para o user 2, sendo esses dois últimos para simular os dois desenvolvedores. A convenção estabelece que não haverá comunicação direta entre o repositório dos desenvolvedores 1 e 2. Apenas através do repositório oficial, exatamente como acontece no modelo centralizado.

O acesso ao repositório oficial, tanto do Mercurial, quanto do Subversion, será feito por acesso local para manter o roteiro simples. No exemplo, será usado o diretório /tmp (que é o diretório temporário do linux) para manter todos os repositórios. Escolha um diretório que melhor lhe convier.

2. Publicação Inicial

O próximo passo é fazer uma primeira publicação no repositório. Use um arquivo chamado numeros.txt que deverá ser criado no diretório do repositório/cópia de trabalho com o seguinte conteúdo:

um
dois
três

O Mercurial teve um passo adicional para enviar ao repositório oficial o que foi feito no repositório local.

3. Vendo o histórico do projeto?

Note que o Mercurial também fornece uma numeração sequencial além da identificação da revisão por hash. Esta numeração é válida apenas para o repositório local e foi criada por comodidade, para facilitar a referência a uma revisão em comandos locais, ao invés de se usar o identificador hash.

4. Atualização do Repositório do Usuário 2

O usuário 2 está com seu repositório desatualizado em relação ao repositório oficial. A sincronização se dá pelo comando hg pull -u que já atualiza a área de trabalho acoplada com a última revisão.

5. Edição Concorrente

Usuários 1 e 2 executarão mudanças concorrentes no mesmo arquivo. user 1 acrescentará a palavra “zero” na primeira linha enquanto usuário 2 acrescentará “quatro” na última linha. Como as mudanças acontecerão em partes diferentes do mesmo arquivo, a mesclagem ocorrerá sem conflitos.

Descrição das falhas nas operações:

1. O arquivo numeros.txt está desatualizado em relação à última revisão do repositório. É necessário atualizar/mesclar para que seja aceito.
2. Por padrão, a operação de push não permite que um ramo fique com mais de uma ponta, isto é, tenha bifurcações após a combinação dos grafos de revisões. Qualquer linha individual de desenvolvimento deve ser antes unificada localmente com a linha presente no repositório-oficial antes de ser enviada.

6. Visualização do Grafo de Revisões

O histórico de revisões do DVCS é um grafo acíclico direcionado (Directed Acyclic Graph – DAG). Na interface gráfica, é possível ver os caminhos sendo bifurcados e reunificados. Pela linha de comando, é necessário antes habilitar o plugin do Mercurial que conseguir ver o grafo textualmente.

Edite o arquivo de configuração do repositório do usuário 2, cujo caminho é /tmp/user2/.hg/hgrc e adicione as seguintes linhas ao final

[extensions]
hgext.graphlog =

@ changeset: 3:3eddeb3252ea
|\ tag: tip
| | parent: 1:f01fe74e7279
| | parent: 2:c3664eb01670
| | user: user2
| | date: Sun Apr 18 22:06:03 2010 -0300
| | summary: merge
| |
| o changeset: 2:c3664eb01670
| | parent: 0:b353a0bdea31
| | user: user2
| | date: Sun Apr 18 22:05:21 2010 -0300
| | summary: quatro
| |
o | changeset: 1:f01fe74e7279
|/ user: user1
| date: Sun Apr 18 22:05:43 2010 -0300
| summary: zero
|
o changeset: 0:b353a0bdea31
user: user1
date: Sun Apr 18 22:04:40 2010 -0300
summary: primeiro commit

O grafo apresentado mostra que as revisões produzidas pelos usuários 1 e 2 formaram linhas independentes de desenvolvimento que depois foram reunificadas.

Conclusões

Usando o Mercurial na topologia cliente-servidor, com um repositório oficial equivalente ao repositório central do Subversion, nota-se que não há nenhuma grande mudança na forma do trabalho, nem nos comandos, que são idênticos para a maioria das operações. A impressão que se tem é de que o Mercurial é um Subversion com push e pull.

À primeira vista, parece que o Mercurial precisa de mais comandos para fazer a mesma coisa que se faz no Subversion. A razão disso, e que só é mostrado quando se vê o grafo de revisões, é que cada desenvolvedor trabalha em uma linha independente, equivalente a um ramo privativo, no qual pode publicar suas revisões sem a obrigatoriedade de mesclar com outra revisão a cada etapa, que é o que acontece no Subversion. O resultado é um fluxo de trabalho ainda melhor que no modelo centralizado.

No Mercurial, e em DVCS em geral, todo desenvolvedor trabalha naturalmente em um ramo privativo. O mesmo resultado poderia ser obtido no Subversion definindo-se ramos privativos para cada desenvolvedor a cada tarefa, bug etc. a ser implementado. Quem já usou ou tentou usar uma solução assim no Subversion, sabe quanto é trabalhoso e complicado fazer isso.

Mercurial continua evoluindo em ritmo firme e constante. Chega agora a versão 1.5 com diversas melhorias no núcleo, extensões, interface web, Windows e documentação. A lista completa está disponível neste link mas aí vão alguns destaques:

• Melhoria no comportamento do comando heads para ramos nomeados.
• Nova opção -b/--branch para definir um ramo específico para os comandos clone, bundle, incoming, outgoing, pull e push.
• Suporte a certificados de servidor SSL e melhoria no suporte a IPv6
• subrepos agora com suporte básico ao Subversion. Subrepos é uma área do Mercurial que tem evoluído bastante. O objetivo é tratar um repositório e seus subrepositórios como um grupo, tal como é feito no Subversion com o svn:externals.
• Suporte a plugins de autorização.
• Adição de script WSGI para IIS isapi-wsgi

A atualização de versão é recomendada a todos os usuários.

Para quem usa Linux e linha de comando, a melhor forma de instalar continua sendo o easy_install, ao invés dos pacotes da distribuição Linux. Note que o Mercurial precisa compilar umas partes escritas em C e por isso precisa do pacote python-dev. A seguir os comandos necessários para instalar o Mercurial no Ubuntu:

sudo apt-get install python-setuptools python-dev
sudo easy_install Mercurial

Para quem usa Windows, a melhor opção é instalar pelo TortoiseHg, que já instala o Mercurial automaticamente.

TortoiseHg 1.0

O TortoiseHg também está com versão nova: versão 1.0. O pacote de instalação pode ser obtido a partir deste link.

O TortoiseHg também funciona no Linux, e ajuda bastante em algumas operações tais como visualização de diferenças e do histórico de log, que são ruins de ver pela linha de comando só usando o hg diff ou hg log por exemplo. A não ser que você use o  Gnome/Nautilus, com o qual se integra, a ativação do TortoiseHg no Linux é ser feita pela linha de comando usando o comando hgtk e seus subcomandos.

A instalação do TortoiseHg no Linux pode ser feita pelos pacotes da distribuição ou pelo easy_install:

sudo easy_install http://bitbucket.org/tortoisehg/targz/downloads/tortoisehg-1.0.tar.gz

Um dos fatores do sucesso do Git é, sem dúvida alguma o GitHub: design elegante e funcional, gráficos interessantes etc.. Suponha que você deseje participar do GitHub ou mesmo usar algum projeto armazenado lá, só resta a opção de usar o Git, certo?

Não mais! Com o plugin do Mercurial Hg-Git seus problemas acabaram: você pode continuar usando o Mercurial mesmo que o repositório oficial do projeto esteja em Git! Do próprio site:

Este é o Hg-Git plugin para Mercurial, que adiciona a habilidade de push e pull de um repositório Git para um repositório Hg. Isto significa que pode-se colaborar em projetos baseados em Git a partir do Hg, ou usar um servidor Git como um ponto de colaboração de um time de desenvolvedores usando tanto o Git quanto o Hg.

O plugin foi desenvolvido pelo próprio pessoal do GitHub com o claro e justo intuito de aumentar o público-alvo dos seus serviços, mas amplia bastante as possibilidades de trabalho dos desenvolvedores e projetos que, tal como nós da Pronus, escolheram o Mercurial como DVCS.

Nem faz tanto tempo que saiu a versão 1.3 e já lançaram a versão 1.3.1 do Mercurial. Esta versão chega com várias pequenas correções sobre a versão anterior. Entre elas, destacam-se:

• consertado o uso excessivo de memória para operações de diff e strip
• resolvido o problema de lentidão no cálculo de heads de ramos
• resolvido o problema de lentidão na extensão fetch
• update –check agora mostra vários ramos
• Vários pequenas alterações na documentação e outros pequenos defeitos corrigidos

A lista completa de alterações está disponível neste link.

A atualização de versão é recomendada a todos os usuários. Para quem usa Linux e linha de comando, a melhor forma é usar o easy_install

sudo easy_install -U Mercurial

TortoiseHg 0.8.1

Para quem usa o TortoiseHg, saiu a versão 0.8.1 que já vem com a versão 1.3.1 do Mercurial. Sendo assim, basta instalar essa nova versão no Windows e pronto.

Há várias outras correções nessa versão. A lista completa está aqui. Uma das mudanças é a inclusão do livro do Mercurial em formato PDF no pacote.

Foi lançada a nova versão 1.3 do Mercurial. Chega com várias novidades, das quais destaco:

1. Sub-repositórios (ainda em fase experimental) – Veja subseção abaixo
2. Python 2.3 não é mais suportado. É necessário usar a versão entre a 2.4 e a 2.6
3. Tradução para Português-Brasileiro
4. merge: adicionada opção de preview -P/ –preview. Sempre bom saber qual o resultado vai dar antes de se comprometer com ele.
5. update: adicionada opção -c/–check  para abortar atualização em caso de modificações locais pendentes.
6. Extensão alias incorporada ao núcleo
7. Extensão share (experimental)

Subrepositórios no Mercurial

A nova funcionalidade de subrepositórios segue a linha da propriedade svn:externals do Subversion. A idéia é permitir o uso de um repositório dentro de outro (fica sendo um subdiretório) e tratar todos como um só grupo.

As possibilidades são interessantes: é possível montar um projeto combinando partes formadas por projetos independentes.

Ao invés de propriedades, o mercurial usa um arquivo chamado .hgsub para registrar os subrepositórios. Só lembrando que arquivos que começam com ‘.’ são ocultos no Linux.

A criação e o registro dos subrepositórios ainda precisam ser feitos manualmente nesta versão que ainda é experimental. Entretanto, já estão previstas melhorias nesse sentido e também em manter subrepositórios não nativos, isto é, de outros sistemas tais como Subversion ou Git.

Extensão Alias

Alias era uma extensão à parte, mas agora é distribuída junto com o Mercurial. Mesmo assim, precisa ser habilitada no arquivo .hgrc do usuário para funcionar.

Permite a criação de “apelidos” para conjuntos de comandos e parâmetros usados com frequência. Por exemplo:

[extensions]
alias =

[alias]
llog = log --limit 10

A configuração acima cria um “novo” comando llog equivalente à execução do comando log --limit 10.

Extensão Share

Esta extensão permite criar — localmente — áreas de trabalho independentes que compartilham fisicamente o mesmo repositório (diretório store do .hg). A vantagem é que todos os commits feitos aparecem automaticamente no histórico dos repositórios compartilhados sem a necessidade de comandos de push ou pull.

É útil para a criação de uma área de trabalho para um ramo, por exemplo,  e não desperdiça espaço com um armazenamento do repositório interno.

Instalação da Versão 1.3

No Linux, é mais vantajoso usar o easy_install para obter a versão mais recente (easy_install -U Mercurial). A outra opção seria usar os pacotes da distribuição, mas essa alternativa costuma ser mais desatualizada.

No Windows, é possível utilizar o Mercurial 1.3, inclusive através da linha de comando, instalado diretamente o TortoiseHg 0.8. Interessante ressaltar que o TotoiseHg também funciona em plataformas não-Windows. Veja a página do TortoiseHg para mais informações.

Estão abertas as inscrições para o novo curso de Gerência de Configuração de Software com Trac e Mercurial. A grande novidade é o uso do Mercurial para o controle de versão distribuído.

Sobre o Mercurial

Mercurial é uma das mais populares ferramentas da nova geração de controle de versão distribuído. É usada por diversos projetos grandes tais como o OpenJDK (Java), NetBeans, Google Code, Python etc.

Possui um conjunto de comandos parecidos com o Subversion, o que facilita o seu aprendizado. Além disso, traz os diversos benefícios do modelo distribuído de controle de versão, tais como independência, rapidez e produtividade.

Sobre o Curso

O curso tem duração de 16 horas e, apesar de apresentar conceitos teóricos, é voltado para a parte prática de Gerência de Configuração, com diversos exemplos e exercícios de fixação do uso conjunto do Trac e do Mercurial para atender às necessidades do dia a dia do desenvolvimento de software e destaque aos novos fluxos de trabalho do modelo distribuído de controle de versão.

O curso também cobre a instalação e configuração do servidor do Trac e de um repositório “oficial” do Mercurial, tratando inclusive de alguns procedimentos de autorização, backup e restauração.

O programa completo está disponível na página do curso.

A próxima turma está marcada para os dias 17 e 18 de agosto em São Paulo.

Faça já sua inscrição e aproveite a promoção de lançamento até o dia 17 de julho (15% de desconto)!