Em um projeto ágil, uma equipe de desenvolvimento gasta seu tempo basicamente fazendo três tipos de tarefa: análise e design, codificação e configuração/atualização do ambiente e das ferramentas de trabalho. Este último tipo, em especial, envolve a interação do desenvolvedor com ferramentas de apoio, como o repositório de código-fonte, o tracking de tarefas e outras. Pode não ser muito perceptível na maioria dos projetos, mas, na medida em que o projeto cresce em tamanho e complexidade, este tipo de atividade pode passar a ser um grande inconveniente para a agilidade da equipe.

Por exemplo, aqui na nossa equipe, um desenvolvedor precisaria executar os seguintes passos sempre que fosse começar a trabalhar em uma nova tarefa:

 - Fazer um check-out do código-fonte no branch adequado;
 - Criar um diretório virtual;
 - Abrir o projeto na IDE;
 - Remover páginas web desnecessárias (para diminuir o tempo de build)
 - Compilar todos os assemblies;
 - Rodar testes de unidade;
 - Apontar a aplicação para o banco de dados correto;
 - Rodar um programa para checagem/atualização da estrutura do bd em uso;
 - Rodar a aplicação;
 
Com certeza, muita coisa... por incrível que pareça, cada passo desse tem sua importância e não fazer um deles na ordem correta pode levar a ainda mais desperdício de tempo.

Para tentar agilizar esse processo, nós criamos uma ferramenta onde o desenvolvedor pode centralizar e disparar essas ações de forma a perder o menor tempo possível. Chamamos essa ferramenta de “Console do Desenvolvedor”, ou simplesmente DevConsole e sua aparência pode ser conferida na Figura 1.

Figura 1: Visão geral do DevConsole

Como pode ser observado na Figura 1, o console permite que o desenvolvedor tenha acesso rápido às situações de build da integração contínua e aos itens de trabalho que estão em desenvolvimento. Há links para visualizar os detalhes de cada build ou work item e links para acesso às releases geradas pela integração contínua em cada branch ativo.

Essa visão é interessante, porém não é suficiente para o desenvolvedor. Ele precisa executar operações de montagem e configuração de ambiente para cada “work item” pendente. Assim, ao criar o DevConsole nós tivemos três objetivos em mente:

 1: Automatizar a execução de tarefas repetitivas e que precisam ser realizadas fora da IDE, muitas vezes, com a utilização de mais de uma ferramenta de apoio;
 2: Isolamento do ambiente de desenvolvimento por tarefa. Cada tarefa deve ter o seu próprio ambiente e os desenvolvedores devem ser capazes de alternar entre várias tarefas de maneira rápida e fácil;
 3: Manter a equipe sintonizada e informada dos eventos que vão ocorrendo no dia-a-dia de trabalho.

Vamos ver como isso ocorre a seguir.

Objetivo 1: Automação de tarefas repetitivas do desenvolvedor

Devido ao nosso método de trabalho, o desenvolvedor precisa alternar - sem esforço de configuração - entre diversas tarefas durante o dia em uma mesma máquina. Dessa maneira, nossa primeiro desafio, foi permitir que o ambiente de trabalho configurado para cada work item fosse completamente isolado um do outro. Clicando-se com o botão direito sobre um item do DevConsole, este exibe um menu de opções conforme é apresentado nas figuras 2a, 2b e 2c.

Figura 2a: Opções para configuração de ambiente

A opção Environment contém algumas das opções utilizadas para montagem e configuração de ambiente, caso estas precisem ser executadas de forma isolada. Mas, a opções mais utilizada é primeira “Inicializar Ambiente”. Esta opção executa todos os procedimentos listados no início deste artigo (check-out, compilação, checagens, etc). Ao final do processo, o desenvolvedor já tem a IDE e a aplicação pronta para uso. 

Figura 2b: Opções para recuperação de arquivo do repositório

Na opção Source Control, temos as ações de check-out e update, caso estas precisem ser executadas de forma isolada (o que é mais raro). Nesse caso, as vantagens de se usar o console ao invés dos clientes do cvs é, primeiro, não precisar abrir outra ferramenta e, segundo, já se ter definido o contexto de pasta onde essas operações serão executadas de forma automática.

Figura 2c: Opções de integração com a IDE

Já as opções de integração com a IDE (figura 2c) são mais frequentemente utilizadas. Elas permitem, por exemplo, que o desenvolvedor crie apenas os projetos que serão afetados no trabalho desse item. Como nós temos mais de 10 projetos, abri-los todos de uma vez torna a IDE e o processo de compilação lentos. Assim, o desenvolvedor monta uma solução do Visual Studio apenas com o(s) projeto(s) que será(ão) alterado(s), os outros são referenciados via assemblies automaticamente pelo DevConsole.

Uma outra opção de integração com a IDE é o “Filtro de páginas web”. Nós temos, hoje, por volta de 700 páginas aspx para interface com o usuário. Trabalhar com a IDE compilando todas essas páginas em uma build é inviável. Assim, o desenvolvedor pode selecionar as páginas que ele quer que estejam presentes no projeto web (O Visual Studio permite que se faça isso pela IDE, mas, infelizmente, ainda não de modo eficiente).

Figura 2d: Atalhos para operações comuns

Por último, a opção Abrir do menu, permite criar atalhos para operações comuns do dia-a-dia, como abrir a pasta onde os arquivos de projeto estão localizados, abrir o work item no sistema de tracking e abrir a própria aplicação relacionada com o item no browser.

Objetivo 2 – Isolamento de tarefas em uma mesma máquina

Depois de finalizado o processo de configuração, as pastas com os arquivos relacionados a cada item ficam dispostas no disco separadas pelo branch associado ao “work item” (a informação de em qual branch aquele item deve ser trabalhado é indicada quando do report do “work item” na ferramenta de tracking (Mantis)). Além disso, os arquivos de solução na IDE ficam bem caracterizados para que o desenvolvedor saiba exatamente com o quê está trabalhando (Veja figuras 3a e 3b).

Figura 3a: O item que está sendo trabalhado fica bem destacado na IDE.

Figura 3b: Visão da disposição de pastas criada pelo DevConsole. Separação por Branch e Work Item.

Figura 3c: Diretório virtual configurado no IIS pelo DevConsole de forma isolada para cada work item, contribuindo para o isolamento entre tarefas em uma mesma máquina.

Repare que essa separação permite um maior controle de ambiente, principalmente quando o desenvolvedor precisa rapidamente alternar entre uma tarefa e outra, mesmo estas estando associadas a branches diferentes e rodando em configurações, diretórios virtuais e bancos de dados diferentes. O isolamento é feito criando imagens do código-fonte em pastas do disco diferentes e configurando toda a aplicação para que ela rode sem interferência com relação ao ambiente de um outro “work item”.

Objetivo 3 – Notificações do dia-a-dia

Uma das coisas que implementamos na ferramenta (em um segundo momento) foi o suporte a notificações que achamos importantes serem enviadas para toda a equipe. Principalmente, no que diz respeito ao controle de builds e avisos relacionados com o andamento das tarefas. Nós temos os seguintes tipos de notificação:

 - Situação geral de todas as builds:

Figura 4a

 - Quando uma build começa a ser executada:

Figura 4b

 - Quando uma build falha ou é executada com sucesso:

Figura 4c

 - Quando um novo item é colocado no sistema de tracking:

Figura 4d

 - Quando há uma mudança de “status” de algum item:

Figura 4e

 - Quando um commit é realizado:

Figura 4f

O próprio Cruise Control.Net oferece recursos para notificação das builds ainda de forma um pouco melhor que essa, mas achamos mais interessante centralizar todas as notificações em uma única ferramenta. Além disso, o CCNet dispõe de APIs muito simples de usar para checagem remota do servidor de builds. Não houve muito esforço para implementar essa opção no DevConsole.

As Operações são executadas com o NAnt

 Uma das idéias que nos permitiu desenvolver esta ferramenta de modo rápido foi a utilização de scripts NAnt ao invés da codificação direta das operações com C#.  Ou seja, cada opção de menu do DevConsole na verdade dispara um script NAnt que pode ser trabalhado de forma mais flexível (Veja figura 5).

Figura 5: Operação de Inicialização de ambiente sendo executada pelo NAnt.

Conclusão

Tirando de lado a própria adoção da ferramenta, que foi construída com base exclusivamente nas demandas que tínhamos para automação das nossas atividades, acho que o nosso principal ganho foi a incorporação de algumas práticas que se revelaram muito úteis para o trabalho do desenvolvedor. A padronização foi uma delas. Hoje o DevConsole direciona os desenvolvedores a assumirem um padrão de trabalho, que é compartilhado por todos da equipe.  Ganhamos também alguma flexibilidade para lidar com as limitações da IDE, principalmente no gerenciamento de uma grande quantidade de projetos e dos projetos web que, quando grandes demais, geram muitos transtornos. Por fim, encontramos na ferramenta um grande aliado no controle do ambiente do desenvolvedor, principalmente para a alternância de tarefas que, particularmente no nosso projeto, ocorre com certa frequência e precisa acontecer do modo mais rápido e suave possível.