Blog Pronus

Agora você já pode contribuir diretamente no projeto do Trac com sua opinião, votando nas funcionalidades mais desejadas. Com essas informações, vai ser mais fácil ouvir a comunidade de desenvolvedores, administradores e usuários do Trac e atender esses desejos.

Atenção: antes de votar, é preciso se registrar com nome e e-mail no site. Use a página de preferências do projeto do Trac para isto. Votações anônimas não serão contabilizadas.

A votação não é simplesmente acessar um formulário de enquete, escolher uma opção e clicar. Há duas maneiras de votar:

1. Existe esta página reservada para receber votos. Para demonstrar sua preferência em determinado Plugin ou funcionalidade que gostaria que fosse incorporado ao núcleo central do Trac, é necessário editar manualmente e incrementar o contador para um plugin já registrado, ou cadastrar a funcionalidade desejada.
   A edição é manual mesmo, e é preciso saber um pouco de formatação wiki para mexer. Se precisar de alguma ajuda para mexer na página, entre em contato conosco.
2. Votar em um ticket já cadastrado que descreve a funcionalidade desejada ou o problema a ser resolvido. Vá para a página do ticket e use as setas que estão no canto superior direito da página (veja a figura abaixo). A lista dos tickets mais votados está disponível através deste relatório.

Fazendo um Lobby )

Na página reservada para receber votos eu votei/sugeri no seguinte:

• IniAdminPlugin: Este plugin permite editar o arquivo de configuração do Trac (trac.ini) diretamente pela interface web.
• Tags: Permite associar tags às páginas wiki. O que facilita muito depois organizar as páginas de maneiras diferentes. Temos usado muito nas nossas consultorias, na definição dos processos de Gerência de Configuração.
• Wygiwys (What you get is what you see): Torna a criação e edição de páginas wiki mais fácil através de um editor visual mais amigável.
• Usage Statistics: Mostra gráficos de atividade no projeto. Produz informação gerencial interessante.

As outras opções sugeridas também são muito interessantes.

Os tickets que eu votei são:

• #710 – Rastreamento de tempo. Pedido para registrar tempo gasto/estimado de cada ticket.
• #130 – Suporte a vários projetos. Usar um Trac só para controlar vários projetos ao mesmo tempo.
• #31 – Mostrar a relação e/ou dependência entre tickets. É possível fazer isso usando TracLinks, mas seria melhor deixar isso automático.
• #1 – Mostrar um resumo do projeto com tickets abertos, milestones, tickets associados ao usuário logado etc.

Participe você também!

Depois de muito tempo de espera, finalmente está lançado oficialmente o Trac 0.11. Houve várias novas funcionalidades, correções e melhorias internas e externas. Já adiantando o final da história, para quem ainda não atualizou, vale a pena a migração para esta nova versão.

As principais mudanças foram:

• Configuração do fluxo de trabalho (workflow) que permite que o ciclo de vida do ticket seja ajustado de acordo com a necessidade da equipe e/ou do projeto.
• Controle mais apurado das permissões de acesso.
• WebAdmin passa a ser parte integrante do Trac, facilitando a tarefas de administração do ambiente do projeto. Antes, o WebAdmin precisava ser instalado como um plugin. Devido ao seu sucesso e utilidade, foi incorporado diretamente ao núcleo central do Trac. Outros plugins disponíveis vão ser incorporados também nas próximas versões do Trac.
• Uso do Pygments como padrão para colorir sintaxe de código fonte (usado na visualização do conteúdo de repositório e em outras partes do Trac). Pygments é uma biblioteca totalmente feita em Python (o Trac também é feito em Python), fácil de usar e estender que as opções anteriores (SilverCity e Enscript).
• Melhoria da visualização do repositório.
• Novo mecanismo de template para as páginas (Genshi).

Nos próximos posts, vou comentar em mais detalhes algumas dessas novas funcionalidades e mudanças. Mas para quem já quer pesquisar um pouco mais, as notas dessa nova revisão estão disponíveis (em inglês) na página http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11

Instalação

O modo de instalar o Trac mudou. Antes, era necessários usar os pacotes de instalação específico do sistema operacional e da versão. A instalação no Windows era particularmente trabalhosa pois envolvia a instalação de um conjunto de pacotes em uma determinada ordem.

A partir da versão 0.11, o Trac é instalado através do setuptools. Isso significa que basta usar o comando:

easy_install Trac

Todas as dependências do Trac serão instaladas automaticamente e na ordem correta.

Lembre-se que antes de atualizar a instalação, é sempre prudente fazer um backup de todos os ambientes do Trac.

Suporte Técnico

A Pronus oferecer serviço de suporte técnico especializado em Trac e Subversion para tarefas de:

• Implantação
• Configuração
• Atualização e migração
• Diagnósticos
• Solução de problemas e dúvidas

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.

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.

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

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/
       ...

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:

• Módulo Básico | 01 e 02 de julho de 2008
• Módulo Avançado | 03 de julho 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

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…