relatório - ferramentas de issue tracker

IssueTrackingTools

Tabela de Conteúdo

Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015

Tabela de Conteúdo1. Mantis Bug Tracking

1.1 Instalação e Configuração1.2 Integração1.3 Processos e Adaptabilidade

1.3.1 Níveis de acesso1.3.2 Ciclo de vida1.3.3 Fluxo de transições1.3.4 Customizações

2. Trac Bug Tracking System2.1 Instalação e configuração2.2 Integração2.3 Processos e Adaptabilidade

3. Redmine Issue Tracking3.1 Instalação e configuração

3.2 Integração3.3 Processos e Adaptabilidade

1. Mantis Bug Tracking

O MantisBT (Bug Tracking) é um sistema web para rastreamento de bugs e

issues, lançado em Novembro de 2000 e atualmente uma das mais populares

ferramentas Open Source para bug/issue tracking. Ele é desenvolvido em PHP e

com suporte aos seguintes bancos de dados: MySQL, MS SQL, PostgreeSQL e


BD2. Também, pode ser executado em diversos sistemas operacionais: Windows,

Linux, OS/2, Mac OS X, sistemas Unix, etc; sendo necessário ter o PHP

configurado.

A interface do programa é simples, para gerenciar usuários, projetos, campos

customizados, profile, plugins e configurações basta acessar a guia "Manage" e

selecionar a ação desejada. Os projetos têm suporte a sub-projetos, dentre os

campos para inserir informações sobre versão, visibilidade, categorias, usuários

responsáveis, descrição, dentre outros. Após criar o projeto, pode-se cadastrar

issues/bugs a ele, informando status, níveis de gravidade, prioridade, etc.

1.1 Instalação e Configuração

O download da última versão do MantisBT pode ser feito em sua página de

download. Como ele é um sistema web, utilizei o Apache Web Server para hospedá-

lo, o MySQL como banco de dados e o interpretador PHP. Visando a praticidade, fiz

o download do XAMPP, o qual é um servidor independente de plataforma, contendo

o Apache, MySQL, PHP e phpMyAdmin, dentre outros módulos.

Após a instalação, descompactei o MantisBT para a pasta htdocs do XAMPP,

renomeando-o para mantisbt, então o instalei através da seguintes URL: <

http://yoursite/mantisbt/admin/install.php >, no meu caso, <

http://localhost/mantisbt/admin/install.php >. Após acessar esse endereço, inseri as

configurações referentes ao tipo, hostname, usuário e senha do meu banco de

dados. O usuário informado tinha privilégios para executar as operações de

SELECT, INSERT, UPDATE e DELETE.

Em seguida, o script criou um banco de dados no MySQL e as tabelas

necessárias, gerando o arquivo de configuração config_inc.php, localizado na pasta

config, que está na raíz da pasta mantisbt, isso na versão 1.3.0-beta.3; nas

anteriores ele está na raiz da pasta mantisbt.

Inicialmente esse arquivo contém as seguintes informações:

# --- Database Configuration ---

$g_hostname = 'localhost';


$g_db_username = 'root';

$g_db_password = '';

$g_database_name = 'bugtracker';

$g_db_type = 'mysqli';

O valor do campo abaixo é a senha gerada para o usuário administrator, que

pode ser encontrada na tabela mantis_user_table.

# --- Security ---

$g_crypto_master_salt = '63a9f0ea7bb98050796b649e85481845';

Quando o banco de dados e as tabelas são criadas é necessário alterar a

senha do usuário administrator, ou, desabitá-lo. Além disso, como medida de

segurança, a pasta admin (localizada dentro da mantisbt) deve ser movida para

outro local inacessível através da rede.

Tais configurações são as básicas, no entanto, precisei configurar outras

para habilitar o envio de e-mail, necessário para permitir que os usuários criem

novas contas e habilitar o acesso anônimo. Ambas configurações não são

obrigatórias. Segue abaixo a outra parte do meu arquivo de configuração.

# --- Anonymous Access / Signup ---

$g_allow_signup = ON;

$g_allow_anonymous_login = ON;

$g_anonymous_account = 'administrator';

# --- Email Configuration ---

$g_phpMailer_method = PHPMAILER_METHOD_SMTP;

$g_smtp_host = 'smtp.gmail.com';

$g_smtp_username = '[email protected]';

$g_smtp_password = 'password';

$g_smtp_connection_mode = 'ssl';

$g_smtp_port = 465;

Caso essas ultimas configurações não sejam feitas, ao criar um usuário e

tentar autenticá-lo, será exibido o seguinte erro:

"Your account may be disabled or blocked or the username/password you entered is incorrect."


Tal erro é gerado, nesse cenário, porque a conta criada não foi confirmada;

ou seja, aós a conta ter sido criada, um e-mail de confirmação é enviado com um

link para ativar o usuário. No meu caso, utilizei o servidor SMTP da Google, mas e

possível usar outros além desse. Ainda sobre erros durante a criação de usuários,

verifiquei um bug na versão 2.18, relacionado com o captcha.

1.2 Integração

O MantisBT pode ser integrado a serviços com diferentes propostas.

Anteriormente, foi mencionado que é possível integrá-lo a uma conta de e-mail, a

qual normalmente utilizada para enviar e-mails de confirmação quando uma conta

de usuário é criada, dentre outras notificações e configurações disponíveis.

Além disso, ele tem integração a sistemas visando a autenticação de

usuários, embora não suporte autenticação híbrida, ou seja, parte dos usuários

autenticando de um modo e os demais por outro. O meio padrão para autenticação

é através do banco de dados, podendo ser modificado para utilizar a base de dados

do LDAP, ou, do Active Directory.

No que diz respeito a web services, o MantisBT pode ser integrado via API

SOAP, permitindo que os clientes realizem tarefas tais como: reportar issues,

executar buscas customizadas e consultas de anexos, dentre outras. A API é

habilitada por padrão e acessível através da WSDL disponível em <

http://localhost/mantisbt/api/soap/mantisconnect.php?wsdl >. As opções de controle

para acesso administrativo, leitura e escrita a API estão definidas na documentação.

É possível também integrá-lo nativamente a ferramentas de controle de

versão como o Subversion e GitHub. Através de plugins é possível integrá-lo ao

Maven e adaptá-lo a metodologia de desenvolvimento Scrum, utilizada por muitas

empresas.

Em relação ao gerenciamento de projetos há suporte para o controle de

mudanças, através do Change Log; a gerenciamento de tempo, habilitando o Time

Tracking e informações sobre o andamento do projeto via um Roadmap, onde e

possível setar prioridades, especificar desenvolvedores a issues, planejá-las e

visualizar suas portagens de conclusão, dentre outros recursos.


Há outras integrações interessantes, como as com ferramentas de

gerenciamento de testes (TestRail), integração contínua (Hudson) e análise de

dados (MantisStats).

1.3 Adaptabilidade a processos

Antes da adoção de uma ferramenta para gerenciamento de issues/bugs, é

importante saber da flexibilidade dela quanto a adaptação aos processos existentes.

1.3.1 Níveis de acesso

Os níveis de acessos disponíveis numa ferramenta de issue/bug tracking é

um ponto relevante a ser avaliado, pois nas empresas existem diferentes

hierarquias e pessoas autorizadas a fazes modificações nos projetos existentes.

De acordo com o Manual de Administração de Usuários, um usuário com

nível acesso inferior ao valor definido na variável $g_private_project_threshold não

terá, por padrão, acesso a projetos privados.

Além disso, o MantisBT fornece diferentes níveis padrões de acesso -

VIEWER, REPORTER, UPDATER, DEVELOPER, MANAGER e ADMINISTRATOR,

os quais podem ser customizáveis usando as variáveis de nível de acesso, como

por exemplo, a variável $g_report_bug_threshold, utiliza-se para definir quem pode

reportar issues, o valor padrão dela é REPORTER. É necessário que o usuário que

está reportando também tenha acesso ao projeto, do contrário, ele não terá

autorização para reporte.

Isso acontece porque existem o acesso global, definido a um usuário quando

a conta é criada e outro específico por projeto. Ou seja, caso um usuário tenha

acesso global como REPORTER, mas MANAGER para um determinado projeto,

nesse caso, REPORTER será sobrescrito por MANAGER. Caso tenha global

acesso MANAGER, esse poderá ser sobrescrito por VIEWER. O único nível de

acesso que não pode ser sobrescrito é o de ADMINISTRATOR.

Os níveis de acesso mencionados anteriormente são definidos através de

uma variável assinada como $g_access_levels_enum_string, que recebe os

seguintes valores: 10, para VIEWER; 25 para REPORTER; 40 para UPDATER; 55

para DEVELOPER; 70 para MANAGER e 90 para ADMINISTRATOR.


1.3.2 Ciclo de vida

Outro ponto relevante quanto a flexibilidade é o do ciclo de vida de uma

Issue. No MantisBT há a possibilidade de cada equipe definir suas respectivas

categorias para os status das issues. Tais categorias são mapeadas para os três

estágios padrões: Aberta, Resolvida e Fechada. A documentação sobre Status das

Issues, como exemplo, cita os seguintes status customizados: nova, feedback,

aceita, confirmada, atribuída, resolvida e fechada.

Sendo assim, a primeira fase desse nesse processo é a de criação da Issue,

a qual pode ser realizada através da interface do MantisBT, via SOAP, MantisBT

API, E-mail ou de forma direta ao banco de dados, a qual não é recomendada.

Seguindo o exemplo mencionado no parágrafo anterior, quando uma issue é criada,

pode-se atribuir a ela o status de nova, o qual permanece até ele ser modificado

para aceita, confirmada ou atribuída. Esses três possíveis estados após a criação

da issue são mapeados para o estágio padrão Aberta.

Em seguida, se a issue for marcada como aceita, significa que ela foi aceita

pela equipe de desenvolvimento, na sequência, o status de confirmada confere que

os desenvolvedores concordam com o que foi requisitado pela issue, sendo então

atribuída a um desenvolvedor.

Após a atribuição da issue a um desenvolvedor, ela pode ser modificada para

o status Resolvida, o qual é mapeado ao status padrão Resolvida. Nessa fase, as

resoluções podem estar relacionada com um feedback de correção, não correção,

issue duplicada, dentre outras possibilidades de resolvê-la. Num estado final,

quando nenhuma outra ação é requirida, a issue pode ser marcada como fechada,

status o qual é mapeado para o padrão Fechada.

1.3.3 Fluxo de transições

Além do ciclo do ciclo de vida, torna-se necessário definir como o fluxo de

transição de um estado a outro pode ocorrer. Isso pode ser feito através da página

"Manage > Manage Configurations > Workflow Transitions".

Outra alternativa é utilizar o arquivo config_inc.php para definir as

configurações de um fluxo de transições global, da seguinte forma:


$g_status_enum_workflow[NEW_]

='30:acknowledged,20:feedback,40:confirmed,50:assigned,80:resolved';

$g_status_enum_workflow[FEEDBACK] ='30:acknowledged,40:confirmed,50:assigned,80:resolved';

$g_status_enum_workflow[ACKNOWLEDGED]

='40:confirmed,20:feedback,50:assigned,80:resolved';

$g_status_enum_workflow[CONFIRMED] = '50:assigned,20:feedback,30:acknowledged,80:resolved';

$g_status_enum_workflow[ASSIGNED] = '80:resolved,20:feedback,30:acknowledged,40:confirmed';

$g_status_enum_workflow[RESOLVED] = '90:closed,20:feedback,50:assigned';

$g_status_enum_workflow[CLOSED] = '20:feedback,50:assigned';

A primeira linha da configuração acima diz que os próximos estágios para

issue marcada como NEW (nova) podem ser ACKNOWLEDGED, FEEDBACK e

assim por diante. É importante salientar que, respectivamente, os números antes

dos estados mencionados são os valores associados a essas constantes. Na seção

seguinte, tais enumerações serão explicadas. Outro ponto importante é que as

configurações mencionadas podem ser atribuídas a um único projeto, ou, de forma

global, a todos os existentes.

Quanto aos níveis de acesso padrão, é permitido ao administrador: definir os

status válidos para um próximo status; definir o status padrão para um status

seguinte; definir o nível de acesso mínimo necessário para transitar um status para

outro; definir o status padrão para novas issues; definir o status no qual uma issue é

considerada como resolvida; definir o status no qual issues atribuídas serão re-

abertas; definir o nível de acesso requerido para modificar a fluxo de transições.

Além disso, é possível definir variáveis de limiares através da tela "Manage >

Manage Configuration > Workflow Thresholds".

1.3.4 Customizações

Antes de explicar como as customizações são feitas, é necessário saber que o

MantisBT utiliza o conceito de Enumerations para representar um conjunto de

valores possíveis a um dado atributo, ou seja, utiliza-se da abstração de (chave,

valor). Sendo assim, na pasta core, dentro da mantisbt, há um arquivo com o nome

de constant_inc.php; no qual as constantes do sistema são definidas. A seguir

algumas constantes são exemplificadas:

# access levels


define( 'ANYBODY', 0 );

define( 'VIEWER', 10 );

define( 'REPORTER', 25 );

define( 'UPDATER', 40 );

define( 'DEVELOPER', 55 );

define( 'MANAGER', 70 );

define( 'ADMINISTRATOR', 90 );

define( 'NOBODY', 100 );

# NEW seems to be a reserved keyword

define( 'FEEDBACK', 20 );

define( 'ACKNOWLEDGED', 30 );

define( 'CONFIRMED', 40 );

define( 'ASSIGNED', 50 );

define( 'RESOLVED', 80 );

define( 'CLOSED', 90 );

Após definidas essas constantes, elas são atribuídas a variáveis existentes,

por exemplo, no arquivo config_defaults_inc.php, localizado dentro da pasta

mantisBT, da seguinte forma:

$g_access_levels_enum_string =

'10:viewer,25:reporter,40:updater,55:developer,70:manager,90:administrator';

Além disso, há como definir as strings locais através do arquivo em

lang/strings_portuguese.txt, por exemplo:

$s_access_levels_enum_string =

'10:Visualizador,25:Reportador,40:Atualizador,55:Desenvolvedor,70:Gerente,90:Administrador';

Outras constantes podem ser customizadas criando o arquivo

custom_constants_inc.php, permitindo assim, de forma modular, flexibilidade ao

atualizar o ManstisBT para outra versão. Por exemplo, caso eu queira adicionar uma

constante para um novo nível de acesso "desenvolvedor sênior", ou, um novo status

"testando" basta inserir as seguintes linhas no arquivo:

<?php


# Custom access level

define ( 'DESENVOLVEDOR_SENIOR', 60 );

# Custom status code

define( 'TESTANDO', 60 );

Após isso, é possível utilizar as novas constantes no arquivo config_inc.php

para atribuir valor a alguma variável, como na que define o limiar para criar e deletar

campos customizáveis, os status e a cor de cada um, respectivamente:

$g_manage_custom_fields_threshold = DESENVOLVEDOR_SENIOR;

$g_status_enum_string =

'10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:testando,80:resolved,90:closed';

$g_status_colors['testando'] = '#ACE7AE';

De forma semelhante existe um arquivo para customizar as strings de acordo com o idioma local, conhecido como custom_strings_inc.php.

<?phpswitch( $g_active_language ) {

default: # english$s_status_enum_string =

'10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:testing,80:resolved,90:closed';$s_testando_bug_title = 'Mark issue Ready for Testing';$s_testando_bug_button = 'Ready for Testing';$s_email_notification_title_for_status_bug_testando = 'The following issue is ready

for TESTING.'; $s_access_levels_enum_string =

10:Viewer,25:Reporter,40:Updater,55:Developer,60:Senior developer, 70:Manager,90:Administrator';

break;

}

As variáveis relacionadas aos status seguem o seguinte padrão, onde XXXX

é o nome do novo status:

s_XXXX_bug_title: título exibido na página de mudança de status

s_XXXX_bug_button: label do botão para submeter a mudança de status

s_email_notification_title_for_status_bug_XXXX: título para notificações via e-mail.


Como os status fazem parte do fluxo de transições é necessário especificar

os novos status apropriadamente, através da página "Manage Workflow

Transitions", ou pelo arquivo config_inc.php como exemplificado abaixo:

$g_status_enum_workflow[NEW_] =

'30:acknowledged,20:feedback,40:confirmed,50:assigned,80:resolved';

$g_status_enum_workflow[FEEDBACK] = '30:acknowledged,40:confirmed,50:assigned,80:resolved';

$g_status_enum_workflow[ACKNOWLEDGED] =

'40:confirmed,20:feedback,50:assigned,80:resolved';

$g_status_enum_workflow[CONFIRMED] = '50:assigned,20:feedback,30:acknowledged,80:resolved';

$g_status_enum_workflow[ASSIGNED]

='60:testando,20:feedback,30:acknowledged,40:confirmed,80:resolved';

$g_status_enum_workflow[TESTANDO] = '80:resolved,20:feedback,50:assigned';

$g_status_enum_workflow[RESOLVED] = '90:closed,20:feedback,50:assigned';

$g_status_enum_workflow[CLOSED] = '20:feedback,50:assigned';

2. Trac Bug Tracking SystemO Trac é um software Open Source baseado em web para gerenciamento de

projetos, tangendo mais especificamente seus processos e políticas. Então, com esse

objetivo ele provê um sistema para issue tracking e wiki.

2.1 Instalação e configuração

O Trac têm suporte aos bancos de dados SQLite, PostgreSQL e MySQL,

sendo necessário utilizar um deles, com suas respectivas bibliotecas para Python.

As outras dependências obrigatórios são o Python (versão >= 2.5 e < 3.0),

setuptools e Genshi. A instalação do Trac 1.0, em sistemas operacionais Linux e

MacOs, pode ser feita utlizando o comando pip install trac psycopg2, easy_install

Trac==1.0, ou, via download do código fonte. As instruções para outros sistemas

operacionais, versões e dependências estão disponíveis no site do projeto.

Visando instalar configurar a ferramenta para testar determinadas

funcionalidades, utilizei o sistema operacional MacOS 10.11.1 e as dependências

obrigatórias, mencionadas anteriormente. Após esses procedimentos, tentei criar

um projeto, através do comando trac-admin my-project-path initenv, no qual

identifiquei um bug reportado na versão 0.2 do Trac, ainda não corrigido na versão

1.0. Neste bug o erro "TypeError: unsupported operand type(s) for /: 'int' and


'NoneType'" é exibido como resultado de ter informado no processo de configuração

um banco de dados utilizando codificação em latin, em vez da utf8.

No processo de configuração, é possível não informar uma conexão com um

banco de dados específico, para então o Trac utilizar o SQLite, criado por padrão no

diretório do projeto. Alternativa essa escolhida por atender os meus propósitos de

estudo e pela simplicidade.

Em seguida, escolhi o modo de autenticação ao Trac; existe a opção básica e

outra via Digest, mais seguro. Escolhi o modo básico de autenticação, que utiliza um

arquivo htpasswd como validação dos usuários. Para criar esse arquivo utilizei os

seguintes comandos:

1 - permission add admin TRAC_ADMIN

2 - htpasswd -c /path/to/env/.htpasswd username

3 - tracd -p port --basic-auth="projectdirname,/fullpath/environmentname/.htpasswd,realmname"

/fullpath/environmentname

O primeiro comando acima é utilizando para dar privilégios de administrador

a um dado usuário, no caso, admin. O segundo, em seguida, adiciona o usuário

"usuername" e sua respectiva senha (criptografada em SHA-1, requisitada após o

comando) ao arquivo htpasswd. E, o último, inicia o serviço do Trac na porta

indicada, carregando o arquivo htpasswd para a validação dos usuários cadastrados

no projeto. Sendo assim, quando a opção para login é acionada, o usuário e senha

são informados e validados.

2.2 Integração

O Trac tem suporte nativo ao SVN e Git, dentre outros sistemas de controle de

versão. Para habilitar o SVN é necessário configurá-lo explicitamente para isso, habilitando

a seguinte variável:

[components]tracopt.versioncontrol.svn.* = enabled

O endereço do repositório é configurado através da guia Admin > Version

Control > Repositories. O Trac oferece uma interface para visualização do

repositório e análise das modificações feitas de um código para o outro.


Além disso, existem diversos plugins que podem ser integrados ao sistema,

tais como o LdapPlugin, para integração com o LDAP (em vez de configurar cada

usuário independentemente, como explicado anteriormente) e outros relacionados a

User Management; administração de Testes, Tempo de Projeto; suporte a múltiplos

projetos em único projeto (característica que o MantisBT tem nativamente);

Integração Contínua, Agile (plugin Agilo For Scrum), etc.

2.3 Processos e Adaptabilidade

No Trac as issues e bugs são reportados através de Tickets, contendo

informações sobre o autor do ticket (Reporter), tipo (Type), módulo ao qual pertence

(Component), versão do projeto (Version), palavras chaves (Keywords), a prioridade

(Priority), marco (Milestone), responsável (Assigned to / Owner), os usuários a

serem notificados (Cc), como o ticket foi solucionado (Resolution), atual status

(Status), resumo (Summary) e descrição (Description).

Tais Tickets, a partir da versão 0.11, possuem os estados: novo (new), aceito

(accepted), reaberto (reopened), atribuído (assigned) e fechado (closed) e as ações

de transição aceitar (accept), reatribuir (reassign), reabrir (reopen) e resolver

(resolve) associadas a eles.

Sendo assim, um ticket no estado novo pode transitar, unidirecionalmente,

para os estados aceito, atribuído ou fechado, através das transições de estado

aceitar, reatribuir e resolver, respectivamente. Da mesma forma, do estado aceito

para atribuído e fechado, através de reatribuir e resolver. Continuando, do estado

reaberto, para atribuído, aceito e fechado, via reabrir, aceitar e resolver. Do estado

atribuído, para resolvido e aceito, pelas ações resolver e aceitar. Finalmente, do

estado resolvido, para reaberto, através de reabrir.

Os campos existentes nos Tickets, mencionados anteriormente, assim como

os estados atribuídos a eles e seus workflows podem ser customizados, de acordo

com o processos existentes numa determinada empresa. Outras adaptações podem

ser feitas através de integração de plugins, conforme exposto na seção anterior.

As customizações são realizadas através de um arquivo de configuração,

conhecido como trac.ini, localizado em <projectenv>/conf. O Trac através de um

monitoramento de timestamp consegue detectar quando as configurações contidas

nesse arquivo são modificadas, aplicando as mudanças automaticamente, exceto


quando elas ocorrem nas seções [components] e [logging], exigindo que o web

server seja reiniciado, na [inherit] isso não é necessário na primeira atribuição.

No trac.ini, defini-se a seção [inherit] para atribuir um (ou mais) arquivo de

configuração global, do qual os demais herdam, evitando assim duplicação de

configurações. Os papéis e atributos possíveis das demais seções estão disponíveis

na documentação do Trac.

Nesse arquivo, a customização dos workflows é definida pela seção [ticket-

workflow], da seguinte maneira:

accept = new,accepted -> accepted

accept.permissions = TICKET_MODIFY

accept.operations = set_owner_to_sel

A primeira linha define que dos estados new e accepted é possível transitar

para accepted executando a ação accept. A segunda, refere-se a permissão exigida

para executá-la, e, na última linha, a operação realizada quando a ação accept é

executada. O Trac também possibilita associar novos estados a barra de progresso

(milestone), esse tópico é tratado na seção sobre [milestone-groups].

O campos dos Tickets podem ser customizados pela seção [ticket-custom],

seguindo a seguinte sintaxe:

FIELD_NAME = TYPE

(FIELD_NAME.OPTION = VALUE)

Os valores possíveis para TYPE são text, checkbox, select, radio e

textarea, explicado detalhadamente em na documentação sobre a seção [ticket-

custom].

Esta seção do relatório abordou dois dos principais processos do Track e

algumas das customizações possíveis, o próximo capítulo irá analisar a

ferramenta Redmine Issue Tracking.


3. Redmine Issue Tracking

O Redmine é uma ferramenta web de código aberto, utilizada para Issue

Tracking. Ela é desenvolvida utilizando o framework Ruby on Rails, tendo suporte a

diferentes sistemas operacionais e bancos de dados.

Caracterizando-se também por suportar múltiplos projetos e ter um sistema

flexível de issue tracking e controle de acesso, fornecendo também diagrama de

Gantt, calendário; administração de arquivos, documentos e notícias; fórum e wiki

por projeto; time tracking; customização do registro de horas (time-entries), de

campos, projetos e usuários; integração com ferramentas de controle de versão, tais

como SVN, CVS e Git; criação de issue via e-mail; autenticação via LDAP, dentre

outras. A seção seguinte, explicará a instalação e configuração do Redmine.

3.1 Instalação e configuração

O processo de instalação e configuração da última versão do Redmine é

simples e rápido, sem grandes surpresas, comparando-se aos do Trac e MantisBT,

o que sem dúvida é uma vantagem no processo de escolha para implantação de

uma ferramenta ao ambiente corporativo. Além disso, a documentação do Redmine

é completa e atualizada.

O procedimento de instalação e configuração em sistemas baseados em Unix

ocorre em 10 passos. O primeiro deles é fazer o download de uma das versões do

programa. Em seguida, criar no banco de dados a tabela e usuário que serão

utilizados pelos Redmine. Há suporte nativo ao MySQL, PostgreSQL e SQL Server.

Utilizei o MySQL, e, na própria documentação para a instalação há os comandos

necessários para configurar o banco de dados escolhido, no meu caso:

CREATE DATABASE redmine CHARACTER SET utf8;

CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'my_password';

GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';


No terceiro passo, é necessário setar as informações de acesso ao banco de

dados, no arquivo database.yml, localizado na pasta config, seguindo como base o

modelo do arquivo database.yml.example.

production:

adapter: mysql

database: redmine

host: localhost

username: redmine

password: my_password

O interessante é a possibilidade de nesse arquivo especificar todos os

bancos existentes no meio corporativo, inclusive qual é o de produção e

desenvolvimento. É importante também observar a modularidade da configuração,

ou seja, um único local para as configurações do banco de dados, ajudando no

processo de manutenção.

As dependências são instaladas através dos seguintes comandos: gem

install bundler e bundle install --without development test, sendo o último,

respectivamente, necessário executá-lo novamente quando as informação do

módulo de acesso ao banco de dados forem modificadas.

Em seguida é necessário configurar o modo como as dados de seção

serão codificados, escolhendo a opção padrão, o Redmine gera chaves

randomicamente para proteger essas informações, através do comando bundle

exec rake generate_secret_token. Após isso, cria-se o esquema do banco de

dados, executando RAILS_ENV=production bundle exec rake db:migrate e insere-

se os dados de configuração, através do comando RAILS_ENV=production

bundle exec rake redmine:load_default_data.

Finalizando, os três últimos passos são o de criar os subdiretórios files, log

e tmp/pdf e public/plugins_assets e dar acesso ao usuário que irá executar o

Redmine; executá-lo via bundle exec rails server webrick -e production e

autenticar usando o usuário admin e senha admin. Os demais detalhes estão na

documentação de instalação. A seção seguinte, avaliará algumas das integrações

que podem ser feitas no Redmine.


3.2 Integração

O Redmine tem integração nativa aos sistemas de controle de versão SVN,

Git, Git, Mercurial, Bazaar e Darcs. Permitindo associar cada repositório existente a

um projeto, navegação e visualização de mudanças. Além disso, é possível integrá-

lo as IDEs, através de palavras chaves de referências, tais como as padrões

refs,references,IssueID; utilizadas para referenciar uma issue existente no sistema,

por exemplo, caso um determinado commit contenha refs #número da issue, ele

será associada automaticamente a issue, pelo seu número de identificação.

Além disso, há integração com o LDAP, ou seja, para cada usuário existente

nesse diretório é criado uma conta no Redmine, característica extremamente

importante numa empresa com milhares de contas de usuário. É possível integrá-lo

também a um servidor SMTP, configurando-o no arquivo configuration.yml, localizado na pasta config, habilitando assim notificações sobre os projetos via

e-mail.

É possível integrar também o Redmine a outros sistemas utilizando a API

REST que ele disponibiliza, por meio da qual operações CRUD podem ser

realizavas nos seguintes resources: Issues, Projects, Projects Memberships, Users,

Time Entries, News, Issues Relations, Versions, Wiki Pages, Queries, Attachments,

Issues Statuses, Trackers, Enumerations, Roles, Groups e Custom Fields. Tais

operações podem ser realizadas tanto via XML, quanto JSON. Informações de

como utilizar os serviços (resources) estão disponíveis na documentação da API

REST. A seção a seguir tratará sobre os processos existentes no Redmine e a

flexibilidade deles a diferentes ambientes corporativos.

3.3 Processos e Adaptabilidade

O Redmine diferentemente do Trac e MantisBT tem um workflow e estados

simplificados, tal simplicidade também se aplica quando é necessário fazer

customizações.

Quando uma issue é criada, os campos Projetos, Tipo, Título, Situação e

Prioridade são obrigatórios, sendo opcionais os Atribuído para, Tarefa pai, Início,

Data prevista, Tempo Estimado, % Terminado, Tempo Gasto, Atividade,

Comentários, Notas, Anexos. A uma issue é possível atribuir os estados (situações):


Nova, Em Andamento, Resolvida, Feedback, Fechada e Resolvida, assim como os

níveis de prioridade Baixa, Alta, Normal, Urgente e Imediata.

O workflow, ou seja, transições possíveis entre os estados das issues, é

definido de acordo com os papéis existentes no sistema (Gerente, Desenvolvedor,

Informante, Não membro, Todos) e tipo de tarefa (Defeito, Funcionalidade, Suporte).

Por exemplo, dado o papel Desenvolvedor e o tipo de tarefa Funcionalidade, a partir

do estado Em andamento é possível transitar entre os estados Resolvida, Feedback

e Fechada, o estado Nova não é autorizado a esse papel. A mesma lógica se aplica

aos demais casos.

O acesso a todos os processos do Redmine são disponíveis ao administrador

através de uma interface web, sendo assim, não é necessário manusear arquivos

de configuração para criar novos fluxos de trabalho, papéis, tipos de tarefa, campos,

etc. Toda a customização pode ser feita através do menu de Administração >

Projetos, Usuários, Grupos, Papéis e Permissões, Tipos de Tarefas, Situações das

tarefas, Fluxo de Trabalho, Campos personalizados, Tipos e Categorias,

Configurações, Autenticação LDAP, Plugins, Informações. Também, é possível

criar mais de um projeto e atribuir subprojetos a eles.

Outros aspecto importante é o de adaptar o sistema a novas funcionalidades,

o que é possível fazer utilizando plugins. Muitas empresas que trabalham com

desenvolvimento de software utilizam metodologias ágeis, devido a isso o plugin do

Redmine para Agile se torna um dos principais, dentre outros disponíveis na

biblioteca de plugins.

Caso o processo de desenvolvimento de software utilize Integração Contínua

com Hudson, o plugin para Hudson permite adaptar o Redmine a esse

procedimento, exibindo nele a lista de jobs existentes, agregando issues a builds,

etc; o mesmo para Jenkis, através do Redmine Jenkis.

Outro interessante, é o Mantis2Redmine Migrator, que permite, como o

próprio nome sugere, migrar os dados existentes no MantisBT para o Redmine,

dentre outros 682 existentes oficialmente.

O processo de instalação de um plugin é simples, basta fazer o download do

arquivo e copiá-lo para a pasta plugins, caso seja necessário atualizar o banco de

dados, o seguinte comando é executado: rake redmine:plugins:migrate

RAILS_ENV=production, após isso, reinicia-se o serviço do Redmine e o plugin

estará disponível para uso.


relatório - ferramentas de issue tracker

Documents