Murilo de Oliveira Santos RA: 0909350095
INTRODUÇÃO
Este trabalho tem como objetivo apresentar de forma simples e teórica a ferramenta Trac – controle de mudanças – e o Subversion – controle de versão de softwares.
A integração das duas ferramentas é muito útil no desenvolvimento de um projeto, pois há o acompanhamento da evolução do mesmo, o versionamento das mudanças ocorridas e ajuda para fazer a documentação.
TRAC
O QUE É?
Trac é uma ferramenta, open source e de interface web para controle de mudanças em projetos de desenvolvimento de software. O objetivo do software é ajudar o desenvolvedor a rastrear essas mudanças, entender o porquê de cada uma e qual o seu impacto no projeto como um todo. Faz o gerenciamento de projetos, rastrear requisitos/falhas. Fornece um Wiki integrado, uma interface para os sistemas de controle de versão, e várias maneiras de ficar atualizado com os eventos e mudanças que ocorrem em um projeto.
As marcações wiki são efetuadas nas descrições do problema e mensagens de commit, criando links e referências entre erros, tarefas, conjunto de alterações, arquivos e páginas wiki. Um “timeline”, ou linha do tempo, mostra todos os eventos, correntes e já ocorridos, dos projetos, de forma ordenada, tornando uma tarefa fácil o acompanhamento do projeto.
O software foi desenvolvido na linguagem de programação Python.
BENEFÍCIOS
Alguns dos benefícios de se utilizar o Trac são: a melhoria da qualidade do produto final, esse sem dúvida é muito importante, o acompanhamento sobre tudo que ocorreu durante o ciclo de vida do projeto, assim os profissionais envolvidos podem adquirir experiência para futuros projetos e a melhoria na documentação, através do Wiki criado pelo Trac.
COMO FUNCIONA
O Sistema de ticket do Trac
A base de dados de publicações do Trac fornece um simples, mas eficaz, sistema de rastreamento de publicações e bugs dentro do projeto.
Como o principal elemento da gerência do projeto do Trac, tickets são usados pararelatórios de bug, requisição de características, suporte de publicações do software e tarefas do projeto.
Esse subsistema tem sido projetado com o objetivo de fazer com que o usuário contribuia e participe da forma mais simples possível. Ele deverá ser o mais fácil possível para reportar bugs, fazer perguntas e sugerir melhorias.
Uma publicação é associada a uma pessoa na qual deverá resolver a tarefa ou reassociar o ticket para outra pessoa. Todos tickets podem ser editados, anotados, associados, priorizados e discutidos a qualquer momento.
Nota: Para fazer uso total do sistema de tickets, use ele como buffer, ou seja, para armazenar idéias e tarefas do seu projeto, ao invés de apenas para relatar bugs ou falhas. A seguir na integração do Trac com o subversion, será mencionado exemplos de uso de ticket.
A partir dos tickets também é possível obter diversas informações sobre o andamento do projeto, como será mostrado mais à frente.
Figura 1: Trecho do ticket #1547 do projeto do Trac.
Após a criação do ticket, ele passa a receber anotações complementares e sofrer diversas mudanças de estado de acordo com o andamento de sua avaliação (e.g. new, assigned, closed). Todas essas anotações e mudanças são mantidas, formando um histórico da evolução do ticket.
Figura 2: Exemplo de histórico de mudanças de um ticket.
Relatar um erro
Relatar um bug ajuda os desenvolvedores dos softwares a corrigir de forma mais rápida um comportamento não desejado. O sistema de Tickets do Trac é uma das possibilidades para coordenar a correção de bugs. Antes de abrir um ticket, é recomendado que se faça algumas verificações:
1. Verifique se o bug já não foi relatado com outro ticket;
2. Não crie um ticket caso já exista um para o bug (mesmo que a descrição seja um pouco diferente). Caso queira acrescentar alguma informação sobre o bug que possa ser útil, crie um comentário no ticket já existente;
3. Verifique nos fóruns da comunidade se existe algo parecido. Pode ser que você tenha esquecido algum passo na instalação ou na configuração;
4. Nunca use o sistema de tickets para solicitar suporte. Use o fórum específico para esse propósito.
Ao fazer os passos acima e não encontrar nada semelhante ao que achou, você pode ter se deparado com um bug. Preencha o formulário de novo ticket e siga as seguintes orientações:
- Use o campo Breve resumo para descrever o objetivo do seu ticket;
- Selecione o tipo de ticket apropriado (defect para bug, enhancement para pedidos de melhorias/funcionalidades e task para tarefas de projeto);
- Seja o mais descritivo possível: informe o seu sistema operacional, a linguagem de programação e sua versão, banco de dados, bibliotecas auxiliares, e outros componentes relevantes;
- Descreva o contexto ao qual o bug fora identificado: os passos para reproduzir o erro (página inicial, páginas intermediárias e página do erro e o que foi digitado, quando bug ocorrer em um formulário);
- Informe o navegador (e a versão) e anexe um printscreen(captura de tela) da página com erro caso seja de layout;
- Caso já tenha um patch criado, anexe-o no ticket e prefixe o Breve resumo com [PATCH].
Relatar uma falha de segurança
Falhas de segurança são tratadas de forma diferente de outros bugs. Recomenda-se não utilizar o sistema de tickets para reportá-la, ou seja, não tornar a falha pública. Normalmente o software possui instruções para tais casos, como por exemplo, instruir o usuário a enviar um e-mail para um grupo privado de desenvolvedores que irão analisar o caso, para confirmar ou não a falha. Se confirmado, o usuário será informado sobre o andamento do caso, a release ou patch de correção disponibilizado e mais detalhes sobre como proceder com a atualização.
Criar um patch
Para contribuir com um patch, que pode ser para correção de um bug ou melhoria de um trecho de código, certifique-se que seu código está em conformidade com os padrões de codificação do software.
Rastreamento de Mudanças
As mudanças solicitadas e as alterações correspondentes realizadas no software são rastreadas através das amarrações feitas pelos links criados através da formatação Wiki.
Para o controle de mudanças, existe um elemento chamado ticket que pode conter registros de defeitos (ou bugs), pedidos de melhoria e tarefas do projeto, sendo útil para obtenção de informações sobre a construção do projeto.
Todas as anotações complementares e mudanças feitas após a criação do ticket são mantidas, formando um histórico da evolução do mesmo.
Dessa forma, as mudanças que foram solicitadas e as alterações feitas no software a partir delas são rastreadas por amarrações feitas pelos links criados através da formatação Wiki.
No sistema de controle de versão, geralmente o SVN (será mencionado após a explicação do Trac), a amarração é entre o conjunto de mudanças (ChangeSet), que é publicado no repositório, e o ticket (ou outros elementos do Trac) por meio de mensagens de log.
Na figura 2, aparecem algumas palavras em vermelho que são links para outros elementos do trac: [1169] é um link para uma determinada revisão no Subversion #786 e #869 são links para tickets. O link para o ticket #786 aparece riscado pois o ticket se encontra no estado "fechado". NewWorkflow é um link para outra página wiki Do lado do controle de versão, a amarração é feita entre o conjunto de mudanças (changeset) que é publicado no repositório e o ticke (ou outros elementos do trac) através das mensagens de log (Figura 3).
Figura 3. Conjunto de mudanças (changeset) publicado no Subversion cuja mensagem de log indica o ticket que está sendo resolvido.
Wiki
Uma das características mais interessantes do Trac é a utilização de um mecanismo Wiki para documentação colaborativa do projeto e também para a referência cruzada entre todos os elementos mantidos pelo Trac.
Wiki é um mecanismo para edição colaborativa do conteúdo de um documento que fica disponível a qualquer momento através de um navegador web. O texto wiki possui uma sintaxe diferente e mais simples que HTML (figura 4), o que encoraja as pessoas a anotarem e contribuírem para o conteúdo dos textos.
A rede de links formada pelo wiki entre os elementos do Trac fornece uma visão abrangente de todo o projeto. E este é um dos diferenciais mais importantes do Trac em relação a outros softwares similares.
Figura 4. Texto com marcação wiki no momento da sua edição.
Após confirmadas as alterações, é produzido um texto formatado em html como saída, conforme mostra a figura a seguir:
Figura 5. Texto final gerado em html após confirmadas as alterações.
Comparando o exemplo ilustrado nas figuras 4 e 5, nota-se a seguinte relação entre a sintaxe Wik e o resultado produzido em termos de formatação e criação de links:
= Database Backend = tornou-se o Heading 1 do texto
[http://www.sqlite.org SQLite] virou um link para um site externo
#126 é um link para o Ticket 126. O link aparece "riscado" porque o estado do ticket é fechado.
== Existing Proposals and Implementations == corresponde a um Heading 2
Um espaço seguido de * indica um item de uma lista não numerada
{{{ % create dbname }}} é mostrado como texto pré-formado
Observação: Existem algumas outras sintaxes wiki que podem ser usadas no texto, mas a análise de cada uma delas foge ao escopo deste artigo.
O exemplo anterior apresentou a criação de um link para uma página externa e outro para um ticket. Entretanto, é possível criar uma rede de hiperlinks entre entidades do Trac (tickets, relatórios, changesets, páginas Wiki, milestones e arquivos-fonte) em qualquer lugar onde se use formatação wiki. Esta característica é um dos diferenciais mais importantes do Trac em relação a outros softwares de controle de mudança.
SUBVERSION
O QUE É?
Subversion é um sistema de controle de versão livre/open-source. Isto é, o Subversion gerencia arquivos e diretórios, e as modificações feitas neles ao longo do tempo. Isto permite que você recupere versões antigas de seus dados, ou que examine o histórico de suas alterações. Devido a isso, muitas pessoas tratam um sistema de controle de versão como uma espécie de “máquina do tempo”.
O Subversion pode funcionar em rede, o que lhe possibilita ser usado por pessoas em diferentes computadores. Em certo nível, a capacidade de várias pessoas modificarem e gerenciarem o mesmo conjunto de dados de seus próprios locais é o que fomenta a colaboração. Progressos podem ocorrer muito mais rapidamente quando não há um gargalo único por onde todas as modificações devam acontecer. E como o trabalho está versionado, você não precisa ter medo de que seu trabalho perca qualidade por não ter essa via única para modificações—se os dados sofrerem alguma modificação indevida, apenas desfaça tal modificação.
Alguns sistemas de controle de versão também são sistema de gerenciamento de configuração (GC). Estes sistemas são especificamente desenvolvimento para gerenciar árvores de código-fonte, e possuem muitos recursos específicos para o desenvolvimento de software omo identificação nativa de linguagens de programação, ou ferramentas de apoio para compilação de software. O Subversion, no entanto, não é um sistema desse tipo. É um sistema de caráter geral que pode ser usado para gerenciar quaisquer conjuntos de arquivos. Estes arquivos podem ser código-fonte, outros podem ser qualquer coisa, desde listas de compras de supermercado a arquivos de edição de vídeo, e muito mais.
- O objetivo do projeto Subversion é construir um sistema de controle de versão que seja um substituto para o CVS. O Subversion é liberado sob a licença Apache/BSD-style.
- Com o controle de versões podemos gravar o histórico de todos os nossos arquivos. Com o controle de versões podemos restaurar facilmente as versões antigas para ver exatamente qual mudança gerou tal problema.
- O Subversion armazena todas as versões de uma forma inteligente, guardando apenas as diferenças entre as versões. O que é muito mais vantajoso.
- Podemos realizar o controle de versão para todo tipo de arquivo. Não apenas para arquivos de código fonte, mas qualquer tipo de arquivo, incluindo arquivos binários.
O Subversion iniciou-se no começo do ano 2000, a CollabNet, Inc. (http://www.collab.net) começou a procurar desenvolvedores para desenvolver um substituto para o CVS. A CollabNet já tinha uma suite colaborativa chamada CollabNet Enterprise Edition (CEE) cujo um de seus componentes era o controle de versão.
Apesar de o CEE usar o CVS como seu sistema de controle de versão inicial, as limitações do CVS ficaram evidentes desde o princípio, e a CollabNet sabia que eventualmente teria que procurar por algo melhor. Infelizmente, o CVS havia se firmado como um padrão de fact no mundo open source principalmente porque não havia nada melhor, pelo menos sob licença livre. Então a CollabNet decidiu desenvolver um novo sistema de controle de versão a partir do zero, mantendo as idéias básicas do CVS, mas sem os bugs e seus inconvenientes.
Em Fevereiro de 2000, eles contactaram Karl Fogel, o autor de Open Source Development with CVS (Coriolis, 1999), e perguntaram se ele gostaria de trabalhar neste novo projeto. Coincidentemente, no momento Karl já estava discutindo o projeto para um novo sistema de controle de versão com seu amigo Jim Blandy. Em 1995, os dois iniciaram a Cyclic Software, uma empresa que mantinha contratos de suporte para o CVS, e apesar de terem vendido a empresa posteriormente, eles ainda usavam o CVS todos os dias em seus trabalhos. Suas frustrações com o CVS levou Jim a pensar cuidadosamente sobre melhores maneiras para gerenciar dados versionados, no que ele não apenas já tinha pensado no nome “Subversion”, mas também com o projeto básico para armazenamento de dados do Subversion. Quando a CollabNet chamou, Karl concordou imediatamente em trabalhar no projeto, e Jim sugeriu à empresa em que trabalhava, Red Hat Software, essencialmente a cedê-lo para o projeto por um período de tempo indefinido.
A CollabNet contratou Karl e Ben Collins-Sussman, e um projeto detalhado de trabalho começou em Maio. Com a ajuda e o bem-vindo incentivo de Brian Behlendorf e Jason Robbins da CollabNet, e de Greg Stein (à época, um desenvolvedor independente trabalhando no processo de especificação do WebDAV/DeltaV), o Subversion rapidamente atraiu uma comunidade ativa de desenvolvedores. Detectou-se que muitas pessoas também tinham as mesmas experiências frustrantes com o CVS, agora satisfeitas com a oportunidade de finalmente fazer algo sobre isso. A equipe do projeto original determinou alguns objetivos simples. Eles não queriam romper com a metodologia existente para controle de versão, eles apenas queriam corrigir o CVS. Eles decidiram que o Subversion deveria ser compatível com as características do CVS, e manter o mesmo modelo de desenvolvimento, mas não reproduzir as falhas mais óbvias do CVS. E mesmo que o novo sistema não fosse um substituto definitivo para o CVS, ele deveria ser suficientemente semelhante a este para que qualquer usuário do CVS pudesse migrar de sistema com pouco esforço.
Depois de quatorze meses de desenvolvimento, o Subversion tornou-se “auto-gerenciável” em 31 de Agosto de 2001. Ou seja, os desenvolvedores do Subversion pararam de usar o CVS para gerir seu próprio código-fonte, e começaram a usar o próprio Subversion no lugar.
Embora a CollabNet tenha iniciado o projeto, e ainda patrocine uma grande parte dos trabalhos (ela paga os salários de alguns poucos desenvolvedores do Subversion em tempo integral), o Subversion é mantido como a maioria dos projetos open source, gerenciado por um conjunto de regras transparentes e de senso-comum, fundamentadas na meritocracia. A licença adotada pela CollabNet é perfeitamente compatível com Definição Debian de Software Livre (DFSG). Em outras palavras, qualquer pessoa é livre para baixar o código do Subversion, modificá-lo, e redistribuí-lo conforme lhe convier; não é necessário pedir permissão à CollabNet ou a quem quer que seja.
BENEFÍCIOS
Open Source, funciona nas plataformas Windows e Linux. Funciona localmente. “Versionamento” de diretórios. Acesso via http.
INTEGRAÇÃO FERRAMENTA TRAC COM SUBVERSION
O Trac também funciona como um browser do repositório do Subversion, permitindo a visualização de diretórios, logs de mudanças, diferenças entre revisões e revisões específicas dos arquivos armazenados.
Estrutura de diretórios /trunk do projeto Trac na revisão 2341.
Log das revisões mais recentes do diretório trunk.
Diferenças entre duas revisões de um determinado arquivo.
Visualização da revisão específica de um arquivo.
A interface para o repositório é, por si só, um ótimo motivo para se usar o Trac num projeto, mesmo que outro software seja escolhido para o controle de mudança.
Acompanhamento da Evolução do Projeto
Além de todas as funcionalidades apresentadas até agora, o Trac também possibilida o acompanhamento da evolução do projeto. Essa informação é obtida principalmente através da análise dos tickets (número, estado, associação com milestones etc.) e disponibilizada em diversas formas.
Roadmap
O TracRoadmap apresenta uma barra de progresso para cada marco do projeto (milestones) indicando a relação entre os tickets ativos e resolvidos do marco.
TracRoadmap mostra uma barra de progresso projeto por milestone.
TIMELINE
O TracTimeline apresenta uma lista de eventos (relacionados a páginas wiki, tickets, mudanças no repositório e marcos de projeto) em ordem cronológica, uma breve descrição de cada evento e a pessoa responsável. Cada evento possui um link para uma descrição mais detalhada do evento específico.
Pode-se acompanhar a evolução de alguns tipos de elementos do Trac através de RSS.
Relatórios
O Trac possui um módulo de criação de relatórios para fornecer diversas informações sobre os tickets do projeto. Os relatórios são baseados em SQL SELECT e algumas convenções de nome, o que permite grande flexibilidade e algumas formatações tais como de cores e quebras de linha.
Exemplo de relatório oferecido pelo Trac.
Relatórios customizados podem ser criados e mantidos na relação de relatórios disponíveis.
ARQUITETURA DO SUBVERSION
“Arquitetura do Subversion” ilustra uma visão em “alto nível” da estrutura do Subversion.
Em uma ponta encontra-se um repositório do Subversion que mantém todos os seus dados versionados. No outro extremo está o seu programa cliente Subversion, que gerencia cópias locais de partes desses dados versionados (chamadas de “cópias de trabalho”). Entre esses dois extremos estão múltiplas rotas por entre várias camadas de Acesso ao Repositório (RA). Algumas dessas rotas partem das redes de computadores até os servidores de rede, de onde então acessam o repositório. Outras desconsideram a rede completamente e acessam diretamente o repositório.
PORQUE UTILIZAR O CONTROLE DE VERSÃO:
- Registro histórico dos arquivos dos projetos ao longo do tempo.
- Permite que desenvolvedores trabalhem juntos sem que um atrapalhe o outro.
- Não é apenas para equipes de desenvolvedores.
- Pode rodar localmente com muita eficiência.
- Existem opções totalmente gratuitas, como neste caso, o Subversion.
- Segurança total na manipulação e alteração do código.
- Backup automático do código fonte (quando usado em computador separado).
- Recuperação fácil do estado anterior do código quando se faz algo que não ficou bom.
- Compartilhamento de código totalmente suave e sem dores de cabeça.
- Diferentes versões em paralelo (branches).
- Consultar qualquer versão de um arquivo.
- Você não precisa mais gritar pelo corredor para saber se alguém está usando o arquivo que você quer editar.
BIBLIOGRAFIA
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=17411
http://rapidsvnprovab1passos.googlecode.com/files/Subversion.doc
http://labase.nce.ufrj.br/cursos/laboo/2005/trabalhos/subversion/Ox20quex20xc3xa9x20SubVersion.html
http://svnbook-pt-br.googlecode.com/svn/snapshots/1.4/svn.intro.whatis.html
http://pt.wikipedia.org/wiki/Trac
http://www.softwarepublico.gov.br/4ctecbr/wiki/tag/trac?popular=1
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/trac.php?pagNum=0
www.cefetrn.br/~placido/disciplina/pgp/aulas/trac.pdf
http://rapidsvn.tigris.org/
http://pt.wikipedia.org/wiki/Sistema_de_controle_de_versão
http://subversion.tigris.org/
Nenhum comentário:
Postar um comentário