relatório - ferramentas de issue tracker
Post on 20-Feb-2016
230 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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';
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
$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 = 'username@gmail.com';
$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."
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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:
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
$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
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
# 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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
'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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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';
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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):
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
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.
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
Felipe Cordeiro Alves da Silva | 2011082320 | 10 de Outubro de 2015
top related