Posts Tagged ‘subversion’

Quebra de build devido ao mau uso do Subversion

June 16th, 2008

Saber pilotar o Subversion além do commit e update é importante, mas só isso não basta. A falta de um processo adequado de Gerência de Configuração de Software pode levar a resultados indesejáveis devido ao uso inadequado da ferramenta. Um exemplo disto é o mau uso do repositório como backup, que pode levar à situação conhecida como “quebrar a build”.

Imagine uma equipe com 10 desenvolvedores que usam a política de sempre fazer o commit das alterações feitas durante o dia antes de ir embora da empresa.

Em princípio, parece ser uma boa idéia pois aproveita o backup noturno que é feito automaticamente no servidor, evitando o risco de perder alguma coisa caso haja problema na máquina de um desenvolvedor.

Por outro lado, gera o problema de quebrar a build: um desenvolvedor “A” publica (faz o commit) de algo no repositório que não compila. Quando outra pessoa (desenvolvedor “B”) fizer uma atualização (update), sua cópia de trabalho passa a não compilar mais.

O que já é ruim, pode piorar ainda mais: o desenvolvedor “B” resolve consertar a o sistema para que volte a compilar. Paralelamente, o desenvolvedor “A” faz o mesmo, produzindo uma solução parecida mas diferente. Ao publicarem no repositório, vão acabar gerando conflitos.

Não está ruim o suficiente ainda? Troque o desenvolvedor “B” por desenvolvedor “B”, “C”, “D”, “E” etc. e terá o caos instalado com a equipe inteira parada enquanto o problema é resolvido.

Pra fechar com chave de ouro, só falta dizer que a culpa é do controle de versão! Como se fosse responsabilidade do controle de versão verificar o conteúdo do que é publicado no repositório!

Como evitar que esse tipo de problema aconteça?

Uma solução seria o uso de ramos privativos para cada desenvolvedor trabalhar na sua tarefa, de forma que a integração com o trunk é feita só ao final. Vou tratar deste assunto com mais detalhes em outra oportunidade mas já adianto que resolve este problema mas cria outro, que é a necessidade constante de realização de operações de merge. Basta lembrar que merge é a operação mais complicada do controle de versão (seja ele qual for).

A outra solução é bem mais simples. Basta estabelecer a política de nunca publicar no repositório sem antes compilar e testar. Esta solução ainda pode evoluir para um política mais abrangente, que aceita apenas tarefas completadas, compiladas e verificadas.

Necessidade de Um Processo de Gerência de Configuração

Não há nada no Subversion que verifique se o código a ser publicado no repositório não irá quebrar a build. Afinal, não é responsabilidade do controle de versão isso. Quem define quando e que isto deve ser feito é o processo de Gerência de Configuração ajustado para suas necessidades específicas da equipe de desenvolvimento.

Controle de Versão não é só commit e update

June 10th, 2008

Usar uma ferramenta de controle de versão é muito importante, mas será que a equipe de desenvolvimento está realmente tirando algum proveito real disso ou só cumprindo uma etapa burocrática?

Eu trabalhei em uma empresa que usava o CMVC como controle de versão (nem perca tempo procurando sobre a ferramenta pois é antiga e ruim). Ao entrar para a equipe de desenvolvimento, recebi alguns treinamentos mas nenhum relacionado à ferramenta de controle de versão; apenas me ensinaram como fazer as operações equivalentes ao commit e update do Subversion, nada mais. (observação: o CMVC trabalha com a política pessimista de travamento)

Usar o commit e update já ajuda, claro. Evita perder código-fonte e sobrescrever o trabalho de outro desenvolvedor. Mas será que controle de versão é só isso? Está mais para usar o repositório para fazer backup apenas. É como ter uma ferrari na garagem e só usar pra ir comprar pão na padaria a duas quadras de casa.

O controle de versão ajuda a resolver outros tipos de problemas, tais como:

  1. Recuperar um arquivo de uma versão anterior: Um arquivo “A” foi apagado, mas não devia. Agora, passadas N revisões, quero trazer o arquivo de volta, mantendo o histórico com aquele arquivo “A” original.
  2. Desfazer uma mudança sem afetar outras: A revisão atual do repositório é 100 e agora descobriu-se que a mudança feita na revisão 90 não devia ter acontecido. É necessário desfazer esse conjunto de alterações, sem perder as modificações feitas entre as revisões 90 e 100, que são válidas.
  3. Trabalhar em versões diferentes (mas semelhantes) do mesmo software: Uma nova versão foi lançada e é necessário manter seu código ativo para correções de defeitos que porventura serão encontrados e corrigidos.
  4. Replicar a correção de um defeito em vários ramos: Uma correção foi feita em um ramo e agora é necessário que todas as mudanças que foram feitas para corrigir os defeitos sejam refeitas em outros ramos. Um problema em potencial é que os outros ramos receberam suas próprias modificações nesse período.

Para resolver esses problemas, precisa-se de bem mais que commit e update.

Talvez não sejam todos na equipe que precisem saber fazer todas as operações, mas não é nem um pouco confortável mexer numa ferramenta importante como o controle de versão sem ter segurança no que se está fazendo. Investir em treinamento de todos os desenvolvedores ajuda bastante a mudar esse quadro.

Outra coisa importante a saber é que o controle de versão é uma atividade de Gerência de Configuração de Software e resolve uma parte dos problemas da área. Também é importante usar algum software para controle de mudança e ter um processo que guie a utilização das ferramentas.

Disponíveis os binários do Subversion 1.5rc9 e do Tortoise 1.5rc

June 9th, 2008

Estão disponíveis os binários para o Subversion 1.5rc9, inclusive do TortoiseSVN 1.5rc. Quer dizer que já podemos começar a testar as novas funcionalidades! A versão final deve ser lançada nas próximas semanas.

O link para os binários é http://merge-tracking.open.collab.net/servlets/ProjectProcess?pageID=3711

Qual o diretório adequado para os repositórios do Subversion?

June 6th, 2008

O Linux já vem com uma estrutura padrão de diretórios: no /etc ficam os arquivos de configuração, no /tmp ficam todos os arquivos temporários do sistema, e assim por diante. Mas onde devem ficar os repositórios do Subversion?

Nos inúmeros artigos e blogs espalhados pela internet cada um dá seu palpite: alguns sugerem /opt/svn, outros /var/svn e já vi até mesmo uso do /home. Qual deles seria o diretório mais adequado?

Vamos eliminar primeiramente o /home. Num servidor em que os repositórios serão utilizados por vários desenvolvedores, o diretório /home não serve pois é destinado às áreas dos usuários. Por um repositório numa área de usuário representaria um projeto do usuário e não da equipe. Outro problema seriam as permissões de leitura e escrita.

O que vai decidir mesmo o diretório mais adequado é a finalidade do diretório dentro da estrutura já planejada do Linux. Mas onde está descrito qual a finalidade de cada diretório?

Existe um padrão chamado FHS (Filesystem Hierarchy Standard) que define a finalidade dos principais diretórios em um sistema operacional Linux ou do tipo Unix. Por este padrão, o diretório /opt serve para pacotes opcionais e /var para os arquivos transientes e temporários das aplicações, tais como arquivos de log. Sendo assim, nem um, nem outro é o ideal para se por os repositórios.

O candidato ideal é o diretório /srv cuja finalidade é armazenar os dados dos serviços oferecidos pelo sistema, o que é exatamente o que o Subversion faz ao disponibilizar seus repositórios.

Resumindo, nossa recomendação é para usar o diretório /srv para por os repositórios de acordo com o padrão:

/srv
    svn/
        repos1/
        repos2/
       ...

Treinamento de Gerência de Configuração de Software com Trac e Subversion em Julho em São Paulo

June 4th, 2008

Está marcada para a primeira semana de julho, em São Paulo , a próxima turma do treinamento em Gerência de Configuração de Software com as ferramentas open source Trac e Subversion.

São 24hs de treinamento divididos em dois módulos (Básico e Avançado) que cobrem inúmeras tarefas cotidianas e avançadas de gerência de configuração voltadas para desenvolvedores, testadores e líderes de projeto.

A novidade dessa nova turma fica por conta da utilização das versões recém-lançadas do Trac (0.11) e do Subversion (1.5), que trazem novas funcionalidades tais como configuração do workflow e rastreamento automático de mesclagens respectivamente.

Para mais informações sobre preço, local e inscrições, consulte os links:

Lançada a versão 1.5rc8 do Subversion

June 4th, 2008

Uma semana depois do lançamento da versão 1.5rc7, o pessoal do Subversion lança a versão 1.5rc8. Esta versão conserta um defeito encontrado na versão anterior e também contém algumas atualizações de traduções de mensagens.

A expectativa é que a versão 1.5 final saia nas próximas semanas.

Para uma relação completa das mudanças desta versão, veja http://svn.collab.net/repos/svn/tags/1.5.0-rc8/CHANGES

Autenticação Básica do Subversion usando Apache 2

June 3rd, 2008

O Apache 2, além de funcionar como servidor do repositório, fornece vários serviços complementares ao Subversion, tais como compressão de dados, criptografia e autenticação. Este artigo vai falar um pouco a respeito de como configurar a autenticação do Subversion usando a autenticação básica do Apache 2.

Conforme consta na wikipedia, autenticação “… é um processo que busca verificar a identidade digital do usuário de um sistema, normalmente, no momento em que ele requisita um log in (acesso) em um programa ou computador”. O modo mais comum de autenticação envolve um nome de usuário (username) e senha (password).

Como funciona o processo de autenticação do Apache?

O processo de autenticação segue a seguinte seqüência:

  1. O cliente faz uma requisição
  2. O Apache identifica que a requisição é sobre um recurso protegido por uma autenticação básica e envia como resposta um header de código 401 Authentication Required indicando que o cliente deve fornecer as credenciais do usuário
  3. O cliente (por exemplo, o firefox) pede ao usuário para fornecer o nome do usuário e a senha e repassa para o Servidor;
  4. O Apache verifica se o nome fornecido de usuário está numa lista pré-aprovada e se a senha correspondente está correta, e só então libera o recurso requisitado.

Criando um Recurso Protegido por Autenticação Básica

O primeiro passo para exigir uma identificação é inserir na seção Location de acesso aos repositórios do Subversion a sub-seção que exige a autenticação básica:

<Location /svn>
        DAV svn
        SVNParentPath /srv/svn

        # sub-seção referente à autenticação
        AuthType Basic
        AuthName "Repositórios do Subversion"
        AuthUserFile /srv/svn/autenticacao
        Require valid-user
</Location>

Esta configuração do jeito que está permitirá o acesso à leitura e escrita a todos os usuários autenticados a todos os repositórios localizados a partir do diretório /srv/svn. Falta agora fornecer o arquivo de autenticação /srv/svn/autenticacao.

O arquivo de autenticação contém uma relação de nomes de usuários e senhas. Na verdade, não são as senhas que são armazenadas, e sim o hash da senha. Isso torna o arquivo mais seguro pois o processo de hash é unidirecional e impossibilita descobrir o conteúdo original a partir do código gerado.

A verificação é feita usando a senha fornecida para gerar o hash novamente. Caso o hash seja o mesmo que o registrado, então a senha está correta.

O Próprio Usuário Gerando Seu Login e Senha

Para gerar e manter um arquivo com nomes de usuários e suas respectivas senhas criptografadas, utiliza-se o comando htpasswd. O nome do usuário e a senha são passados como parâmetros pela linha de comando ou digitados quando a execução do comando solicita. O inconveniente é que o usuário ou não pode escolher seu login e senha ou precisa estar presente para fornecer a senha desejada. Se o desenvolvedor está em São Paulo e a equipe de suporte está no Rio de Janeiro, por exemplo, a situação fica mais complicada ainda.

Minha sugestão é usar um jeito que o próprio desenvolvedor possa enviar ao pessoal do suporte o login e a senha que deseja. Para isso, deve:

  1. Visitar o site: http://aspirine.org/htpasswd_en.html
  2. Criar a senha desejada senha;
  3. Copiar e mandar palavra criptografada ao encarregado de adicionar a linha ao arquivo de autorização lá no servidor.

Pronto! Simples e prático!

Considerações Finais

A autenticação básica funciona muito bem para empresas com um número pequeno de desenvolvedores pois é fácil e rápido de configurar e resolve bem o problema, sem dores de cabeça para o pessoal do suporte técnico.

Só a autenticação não é tudo. Ainda falta configurar a parte de autorização, mas isso fica pra outra oportunidade…

Lançado o Subversion 1.5.0 rc7

May 28th, 2008

Foi lançado o Subversion 1.5.0-rc7. As correções dessa versão candidata (que promete ser a última) são mínimas e relacionadas com documentação do código e pequenos bugs. Se nenhum bug sério aparecer, a versão 1.5.0 final deverá ser lançada em 10 dias.

O termo “release candidate” significa que os desenvolvedores do Subversion acreditam que esta release está estável e pronta para uso em produção, de modo que encorajam que todos a testem. A Collabnet disponibiliza os binários para algumas plataformas para os testes.