TRAC no Fedora em 5 passos

You are able to see this post in english too.

Olá!

O artigo deste mês mostrará como realizar uma instalação limpa e descomplicada do TRAC no Fedora.

O TRAC é a melhor ferramenta de SCM de natureza open source que conheço. O Fedora GNU/Linux é uma distribuição amplamente utilizada em todo mundo.

No fim do artigo há um adendo sobre como utilizá-lo junto com o GIT, transformando-o também num gerenciador de versão de código.

 

Mão na massa!

  1. Instalação dos pacotes:
    • su -
    • yum update
    • yum install wget python python-devel python-setuptools python-genshi python-docutils python-pygments policycoreutils-python
    • yum install httpd httpd-tools mod_python
    • yum install python-offtrac trac trac-accountmanager-plugin trac-customfieldadmin-plugin trac-doxygen-plugin trac-iniadmin-plugin trac-privateticketsplugin trac-ticketdelete-plugin trac-tracnav-plugin trac-xmlrpc-plugin
  2. Criação do ambiente TRAC no filesystem. Chamaremos a base de trabalho de seu projeto de BASE_DIR (que pode ser por exemplo, /var/www/html/nome_projeto/scm). Os comandos semanage e restorecon servem para dar aos arquivos do TRAC o mesmo contexto do Apache no SeLinux. Obviamente, pode ignorá-los se seu SeLinux está desabilitado:
    • trac-admin BASE_DIR initenv
    • chown -R apache.apache BASE_DIR
    • semanage fcontext -at httpd_sys_content_t "BASE_DIR(/.*)?"
    • semanage fcontext -at httpd_sys_content_rw_t "BASE_DIR/attachments(/.*)?"
    • semanage fcontext -at httpd_sys_content_rw_t "BASE_DIR/conf(/.*)?"
    • semanage fcontext -at httpd_sys_content_rw_t "BASE_DIR/db(/.*)?"
    • semanage fcontext -at httpd_sys_content_rw_t "BASE_DIR/log(/.*)?"
    • chown -R apache:apache BASE_DIR
    • restorecon -R BASE_DIR
  3. Criação do usuário que administrará o projeto. Chamaremos este usuário de ADMIN_USER:
    • htpasswd -c BASE_DIR/conf/trac.htpasswd ADMIN_USER
    • trac-admin BASE_DIR
    • permission add ADMIN_USER TRAC_ADMIN
  4. Alterar a configuração do Apache. Primeiro adicionaremos um alias e uma diretiva para o diretório base do TRAC (ScriptAlias e Directory). Depois, configuraremos as diretivas específicas para o ambiente do projeto (Location). Lembrando que estas diretivas, se necessário, podem estar dentro de um container VirtualHost:
    • ScriptAlias /trac/ "BASE_DIR/"
      <Directory "BASE_DIR">
      AllowOverride None
      Options None
      Order allow,deny
      Allow from all
      </Directory>
      
      <Location /trac>
      SetHandler mod_python
      PythonHandler trac.web.modpython_frontend
      PythonOption TracEnv BASE_DIR
      PythonOption TracUriRoot /trac
      SetEnv PYTHON_EGG_CACHE /tmp
      PythonInterpreter trac
      </Location>
      
      <Location /trac/login>
      AuthType Basic
      AuthName "Nome do projeto"
      AuthUserFile BASE_DIR/conf/trac.htpasswd
      Require valid-user
      </Location>
  5. O último passo é reiniciar o Apache:
    • service httpd restart

Aponte seu browser para a instalação do TRAC (pode ser http://localhost/trac/) e divirta-se.

 

Git

Caso queira utilizar o GIT junto com o TRAC, faça também os passos abaixo:

  • Instale o GIT e seu plugin para o TRAC:
    • yum install git GitPython
    • yum install trac-git-plugin
  • Altere o arquivo BASE_DIR/conf/trac.ini da seguinte forma:
    • A linha repository_dir para o local do arquivo HEAD de seu repositório (normalmente REPO_DIR/.git);
    • Adicione as linhas abaixo ao fim do arquivo:
      • [components]
      • tracext.git.* = enabled
  • O diretório dos fontes deve ter suas permissões de leitura e escrita atribuídas ao Apache.

Os 5 passos acima lhe darão um ambiente TRAC pronto para uso. Para melhorá-lo e adaptá-lo às suas necessidades, visite o website TracHacks onde há muitos plugins para download.

Até 😉

Priorização de demandas por voto

You are able to see this post in english too.

Nossa área de desenvolvimento realizou uma experiência interessante para eleger as demandas mais críticas, aquelas que precisavam ser construídas primeiro. Para isso, criamos uma planilha que, apesar de ser nossa criação, pegou idéias de outras planilhas que vimos “voando” por aqui na empresa.

Aproveitamos um fórum que aconteceu entre cerca de 30 pessoas, todas heavy-users do software mantido por nós. Nele, nossa principal ferramenta foi uma planilha eletrônica (link no fim do artigo), cujas abas seguem descritas abaixo:

  • DEMANDAS: Uma listagem simples das demandas de melhorias requisitadas pelos usuários. Ela é fruto de meses de conversas informais, e-mails, telefonemas, etc. Possui uma coluna ID para facilitar o lookup, um título e uma descrição breve. Esta planilha foi impressa uma única vez, e ficou comigo durante todo o trabalho;
  • FICHA_VOTO: Uma ficha como à da planilha DEMANDAS, mas com uma coluna vazia onde cada participante preencherá seu voto. Foi impressa em quantidade suficiente para ter uma para cada participante;
  • VOTOS: As linhas, novamente, são as demandas. Cada coluna representa uma pessoa presente. A intersecção é o voto de cada um para a demanda. Solicitamos aos participantes uma nota de 1 a 10, respectiva ao tamanho do benefício que ela trará para sua área, caso venha a ser implementada. A última coluna desta planilha é uma média simples dos votos entre 1 e 10. Assim, se a demanda está fora do escopo de trabalho do participante, ele pode votar 0 (zero) para que seu voto seja desconsiderado na média;
  • CÁLCULO: Aqui está o “pulo do gato”. Dias antes deste fórum, fizemos o mesmo trabalho acima mas com os desenvolvedores. Nesta planilha está computada somente as médias dadas por eles a cada demanda. Só que os desenvolvedores deram notas de 1 a 10 respectiva ao tamanho do esforço que a demanda teria para ser desenvolvida. Então, aplicamos uma minúscula parte de IA (fuzz/defuzz) para qualificar o esforço entre “Baixo” e “Alto”. As outras duas colunas fazem o mesmo com o atributo votado pelos participantes do fórum. A primeira só replica a média calculada na planilha VOTOS e a segunda qualifica a média em “Pouco” e “Muito”;
  • GRÁFICO: É um quadrante que por fórmulas simples agrupa as demandas de acordo com seu benefício e esforço, como abaixo:

Gráfico exemplo

Para preencher a planilha de votos, pausamos a apresentação por uma hora, dando tempo para que outra apresentação fosse realizada.

O resultado deste trabalho é o melhor possível. É o cruzamento do que seus usuários mais querem/precisam, com aquilo que seus desenvolvedores dizem ser mais fácil de construir primeiro. Ou seja, nos quadrantes da planilha, você observará claramente quais demandas trazem muito benefício com pouco esforço, por exemplo. Adicionará valor ao desenvolvimento, ao relacionamento com o cliente, e aqui, trouxe mais ânimo e satisfação aos desenvolvedores.

Agora procuro opiniões sobre em que fase do processo esta planilha traria mais valor. Aqui a utilizamos já em fase de manutenção. Acredito que em novos projetos, o maior ganho viria na fase de transição do produto, ponto onde há um certo nivelamento de conhecimento entre fornecedor e cliente.

A planilha está publicada em formato XLS e funcionará normalmente no OpenOffice Calc. Está hospedada no GitHub, e pode obtê-la clicando aqui.

Até 😉