Riopro Blog

Como já escrevemos no outro post, a Riopro agora usa o Redmine. Usavamos o Trac para controle do desenvolvimento dos nossos projetos mas, ao optar pelo Git para controle de versões dos nossos softwares, não tivemos saída a não ser a mudança. Pouco mais de 1 mês após a implementação definitiva, a satisfação é grande e o controle dos projetos muito maior. Muito mesmo. Não que o Trac não fosse bom, mas seguramente o Redmine é mais completo, mais focado em Gerenciamento de Projetos.

Vamos então ao que interessa: funcionalidades!

De cara a primeira mudança com a chegada do Redmine é que a adminstração de todos os projetos passou a ser feita em apenas um lugar. Antes que me digam que isso deveria ser óbvio para um programa de gerenciamento de projetos (ênfase no s), isso não era possível no Trac. O Trac exigia configurações individuais. Era necessário configurar uma nova aplicação para cada projeto desenvolvido. Por isso tinhamos que manter uma página com o links para todos os projetos. Pouco prático, não é?

Além disso, o Redmine tem como característica ser customizável (veja a imagem abaixo). Vários produtos do gênero são (inclusive o Trac). As duas características que ressaltam no Redmine são a profundidade de customização e a simplicidade da mudança. A parte administrativa do Redmine permite que você crie projetos, usuários e permissões.

Além desses, e aí começa a parte legal, o Redmine permite que você defina:

• Status de tickets (issue statuses)
• Crie ou gerencie campos personalizados (custom fields)
• Personalize o comportamento do Redmine (settings)

Em Status de tickets podemos definir quais são os status possíveis para o seu sistema (como Novo, Atribuído, Resolvido, Fechado ou o que tiver em mente) e informe quais deles o Redmine deve considerar como um status que fecha o ticket.

Aqui na Riopro usamos 3 status como fechad0: Fechado,  Rejeitado e Resolvido. Os dois primeiros são intuítivos. O último serve para aqueles tickets (issues) que um desenvolvedor terminou, mas ainda não podemos dar por encerrado (falta a verificação de escopo).

A parte de criação de campos personalizados também é bastante completa. Além de cadastrar um campo e dizer qual o tipo e se o mesmo é ou não obrigatório, você pode definir se esse campo estará presente em apenas um projeto ou se deve estar presente em todos os projetos ou mesmo se podemos realizar buscas usando esse campo ou não. Bem útil, por exemplo para criar sub-categorias (tratamos aqui as categorias como os entregáveis) ou gerencia responsável pelo ticket (o campo pode ser do tipo lista também).

Deixei por último a parte de personalização de comportamento do Redmine (settings). Dentre os destaques, procure na aba Repositories o item Referencing and fixing issues in commit messages. Nesses campos você poderá configurar a interação do Redmine com o repositório do seu projeto. Você pode se estabelecer que palavras o Redmine deve procurar nos seus commits para colocar no log do ticket. Mais ainda, você pode definir palavras que definem que seu ticket pode ser fechado (como fechado, resolvido,…).Um exemplo. Configuramos nosso Redmine para toda vez que escrevermos Ticket #234 ele colocar o log no ticket definido (ou seja vincula).  E toda vez que colocarmos Fecha #234 ele fecha o ticket #234, ajustando o valor do percentual de conclusão para 100%.

Outras características que podem ser configuradas e que merecem destaque são:

• em que situação mandar e-mails para os usuários (ticket mudado, ticket fechado, ticket que acompanho,…);
• Se necessita senha ou se é aberto para consulta (útil para projetos open source);
• Se permite a criação de usuários ou se só o administrador vai poder cadastrar;

Bom, por enquanto é isso. Também fizemos alguns patches para o Redmine, mas só um tem alguma relevância (para ressaltar no calendário e no gráfico Gantt os tickets já fechados, bem útil). Para quem se interessar (são 2 linhas de mudança apenas), colocamos um patch no próprio gerenciador do Redmine, no ticket #1127.