Rastreamento distribuído de bugs

Distributed bug tracking

Autor original: Jonathan Corbet

Publicado originalmente no: https://lwn.net/

Tradução: Roberto Bechtlufft

Não é exagero dizer que os sistemas de gerenciamento distribuído de código fonte estão dominando o mundo. Ainda há muitos sistemas centralizados em uso, mas hoje são raros os projetos que preferem adotar um sistema de gerenciamento de código (ou SCM) centralizado. Os desenvolvedores já se acostumaram à idéia de carregar todo o histórico do projeto em seus laptops, fazer alterações e executar o merge quando tiverem tempo.

Porém, ainda que qualquer desenvolvedor possa consolidar alterações em um projeto mesmo preso com um cinto de segurança a uma lata voadora atravessando o Pacífico, geralmente esse desenvolvedor não pode trabalhar simultaneamente com o banco de dados de bugs do projeto. Consolidar alterações e atualizar as informações de bugs são atividades que costumam andar de mãos dadas, mas os sistemas de rastreamento de bugs ainda estão fortemente fincados no modelo centralizado. Nosso desenvolvedor que vive cruzando os oceanos pode consolidar dezenas de alterações, mas só vai poder atualizar as informações de bug quando o avião pousar e ele conseguir uma conexão com a internet.

Há vários projetos por aí tentando mudar essa situação, trabalhando na criação de sistemas de rastreamento distribuído de bugs. O desenvolvimento desses programas ainda está engatinhando, mas o potencial deles – e suas limitações – é evidente.

Um dos projetos mais adiantados é o Bugs Everywhere, que mudou de casa há pouco tempo, e agora tem Chris Ball como mantenedor. O Bugs Everywhere, como os outros sistemas que investiguei, tenta trabalhar com um sistema de gerenciamento distribuído de código fonte embutido para gerenciar a criação e o rastreamento de entradas de bugs. O Bugs Everywhere em particular cria um novo diretório (chamado de .be) no topo da estrutura de diretórios do projeto. Os bugs são armazenados como diretórios cheios de arquivos de textos, e esses bugs são gerenciados pelo SCM embutido.

As vantagens dessa abordagem são óbvias. O banco de dados de bugs agora pode ser baixado junto com o código do projeto. Ele pode ser ramificado com o código; se uma ramificação em particular contém uma correção de um bug, pode conter também a entrada atualizada sobre o bug. Isso, por sua vez, garante que a informação atualizada sobre o bug chegará ao upstream ao mesmo tempo que a correção em si. Hoje em dia os projetos costumam ter muitos repositórios e ramificações, cada um contendo um conjunto diferente de bugs e correções; distribuir o banco de dados de bugs nesses repositórios só pode ajudar a manter o código e as informações de bugs consistentes em todo lugar.

Mas também há algumas desvantagens nesse esquema, pelo menos em sua forma atual. As mudanças nas informações de bugs não se tornam reais até serem consolidadas no SCM. Quando um bug é corrigido, consolidar a correção e a informação de bug atualizada faz sentido, mas quando só se quer acrescentar alguns comentários sobre um bug, a necessidade de fazer a consolidação acaba sendo trabalhosa. O fato de que, ao menos no git, é preciso adicionar explicitamente quaisquer arquivos novos criados pelo rastreador de bugs (e eles têm nomes como 12968ab9-5344-4f08-9985-ef31153e504f/comments/97f56c43-4cf2-4569-9ef4-3e8f2d9eb1fe/body) não ajuda muito.

Além disso, rastrear bugs dessa forma cria dois grupos independentes de metadados – a informação de bug em si e o que quer que o desenvolvedor tenha acrescentado ao consolidar as alterações. Ainda não existe uma maneira de unir esses dois cursos de metadados. E ainda há a questão do merge. O Bugs Everywhere parece ter pensado nesse problema; a maioria das alterações envolve a criação de arquivos novos e de nomes (aparentemente) aleatórios para que não haja conflitos ao realizar o merge. Mesmo assim, não demorou para que eu provasse que alterar a gravidade de um bug em duas ramificações diferentes e realizar um merge criava um conflito que só podia ser resolvido pela edição manual dos arquivos de rastreamento de bugs. Esses arquivos são de texto puro, mas são bem menos confortáveis de se trabalhar do que você pensa.

Tudo isso pode fazer parecer que o rastreamento distribuído de bugs dá mais trabalho aos desenvolvedores, o que certamente não o levará à dominação mundial. Parece que o que precisamos é de uma combinação de ferramentas mais avançadas e de uma maior integração com o SCM embutido. O Bugs Everywhere, ao tentar trabalhar com qualquer SCM, corre o risco de não ser fácil de usar com nenhum deles.

Um projeto que busca maior integração é o ticgit que, como você já deve ter imaginado, é baseado no git. O ticgit tem uma abordagem diferente: nenhum arquivo é adicionado à árvore de fontes do projeto, pelo menos não diretamente. Ao invés disso, o ticgit adiciona uma nova ramificação ao SCM e armazena lá a informação sobre os bugs. Isso permite que o banco de dados de bugs viaje com os fontes (desde que se tenha o cuidado de dar push e pull na ramificação do ticgit!) ao mesmo tempo em que mantém os arquivos associados fora do caminho. As operações do ticgit trabalham no diretório de banco de dados de objetos do git, por isso não é necessária uma operação separada de consolidação. Por outro lado, essa abordagem abre mão de oferecer uma visualização separada do banco de dados de bugs de cada ramificação; a conexão entre as correções de bug e as mudanças no bug acabou enfraquecida. Isso é algo que pode ser consertado, e parece (pelos comentários nos fontes) que lidar com ramificações está nos planos do autor.

O ticgit tem um claro potencial, mas uma integração ainda maior pode valer à pena. Não seria ótimo se um único comando git commit também associasse por tabela a entrada de bug associada no banco de dados? Desenvolvedores interessados poderiam visualizar uma consolidação que supostamente corrige um bug sem que ninguém precise copiar IDs de consolidação para lá e para cá. Reverter uma consolidação de correção de bug poderia automaticamente reabri-lo. E por aí vai. A longo prazo, é difícil imaginar como uma rastreamento distribuído de bugs verdadeiramente integrado pode ser implementado de forma independente do sistema de gerenciamento de código fonte.

Há outros projetos em desenvolvimento nessa área:

• O scmbug é um projeto relativamente avançado que pretende “resolver os problemas de integração de uma vez por todas.” Mas ele não é um autêntico sistema distribuído de rastreamento de bugs; ele depende de hooks no SCM que conversa com um servidor central. Apesar disso, o projeto pensou bastante em como os rastreadores de bugs e os sistemas de gerenciamento de código devem trabalhar juntos.
• O disTract é um rastreador distribuído de bugs que trabalha com uma interface web. Para isso, ele usa um monte de código JavaScript específico do Firefox para executar programas locais, escritos em Haskell, que manipulam entradas de bugs em um repositório Monotone. Confesso que não juntei todas as peças para que esta ferramenta funcionasse.
• O DITrack é um conjunto de scripts em Python que manipula informações de bugs em um repositório Subversion. Seu objetivo é implementar o modelo distribuído, e um dia trabalhar com qualquer backend, mas o uso que faz do Subversion limita o quão distribuído ele pode ser por enquanto.
• O ditz é um conjunto de scripts em Ruby que manipula informações de bugs em um sistema de gerenciamento de código fonte; ele não faz distinção entre SCMs.

Como se pode ver, não é pouco o trabalho nesta área, embora poucos destes projetos tenham alcançado um alto nível de usabilidade. Só o scmbug tem sido usado em grande escala até agora. Alguns desses projetos tem o potencial de mudar a forma como se desenvolve software, mas antes é preciso que vários problemas de integração e interface do usuário sejam resolvidos.

E ainda há um problema que não foi abordado por ninguém. Um rastreador de bugs funciona como uma espécie de lista de tarefas para os desenvolvedores, mas ele é mais do que isso. Ele é também um ponto focal de discussão entre desenvolvedores e usuários. A maioria dos usuários não ficará muito impressionada com uma mensagem do tipo “configure um repositório git e execute estes comandos para postar ou comentar um bug.” Em outras palavras, há valor em um sistema centralizado com uma interface web que torna o sistema de rastreamento de problemas acessível a uma ampla comunidade. Qualquer sistema distribuído de rastreamento que não facilite essa discussão vai acabar fracassando. Criar um rastreamento distribuído que também seja bom para os usuários pode ser o maior dos desafios.

Créditos a Jonathan Corbet – https://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>