Alisson Vale

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.

Esse post vai em especial para o colega Thiago Arrais que está conduzindo, em conjunto com outros parceiros, uma excelente iniciativa de implementação open-source de um portal para projetos de software: o Motiro.

Ano passado quando ministrei a disciplina de Gerência de Configuração em um curso de Pós-graduação em Projeto de Software aqui na Grande Vitória, utilizei esse texto como motivação para os alunos terem uma idéia de como um projeto poderia ser apoiado por boas práticas de gerência de configuração. O texto é uma adaptação da introdução do excelente livro "Portais Corporativos - A revolução na gestão do conhecimento" de José Cláudio Cyrineu Terra e Cindy Gordon. Preservei o nome do portal citado no livro, mas adaptei todas as cenas e personagens para um ambiente em uma empresa de software.  Acho que o texto pode dar boas idéias para o pessoal do Motiro e para todos aqueles que querem avançar no mundo da Gerência de Configuração e/ou dos Portais Corporativos. 

OBS: A história se passa em uma empresa que não trabalha com métodos ágeis. Alguém se propõe a adaptá-lo para um projeto XP?

Segue então o texto conforme eu passei para os alunos:

A seguir descreve-se uma série de cenas ocorridas – ou que poderão ocorrer? – em uma empresa que desenvolve produtos de software de médio ou grande porte. A área de gerência de configuração da empresa integrou seus processos através de um avançado portal de conhecimento corporativo: o Agente-C. O relacionamento verbal entre o Agente-C e os funcionários da empresa é propositalmente futurista para aumentar a dinâmica dos diálogos e para ajudar o leitor a entender os processos que estão em funcionamento em um ambiente controlado por uma área de gerência de configuração.

Inácio chega no escritório e liga seu computador

Inácio:       Bom dia, Agente-C!

Agente-C:     Bom dia, Inácio!

Inácio:       Alguma notícia relevante?

Agente-C:     Sim. Uma nova release do projeto Open-Source Gentle.Net foi liberada.

Inácio:       O Gabriel já sabe disso?

Agente-C:     Sim. Ele também assina e recebe as notícias sobre esse assunto nessa agência.

Inácio:       OK. Próxima.

Agente-C:     Uma desenvolvedora sênior chamada Bianca Lins ingressou ontem no nosso escritório em Recife. Ela tem uma experiência que é altamente relevante para o projeto Sinus.

Inácio:       OK. Me passe mais detalhes.

Agente-C:     Ela trabalhou por cinco anos como desenvolvedora da IBM, tem uma grande experiência com SQLServer e é especialista em tunning e performance nesse SGBD.

Inácio:       Isto é realmente interessante. Por favor, tente marcar uma reunião com áudio e vídeo com ela em qualquer horário amanhã pela manhã.

Agente-C:     Baseado no seu calendário on-line, ela está disponível para um encontro às 10 horas da manhã. Eu reservarei a hora, esperarei por confirmação e entrarei em contato em contato com você.

Inácio:       OK. Envie pra ela um link com nosso último relatório de performance no módulo de conciliação bancária.

Agente-C:     Link enviado. Convite para reunião virtual enviado.

Três horas depois no escritório de Inácio....

Inácio:       A Bianca mandou notícias?

Agente-C:     Sim. A reunião está confirmada. Ela te deixou uma série de links para artigos que ela escreveu anteriormente sobre tunning e performance.

Inácio:       OK. Eu preciso ir agora. Coloque os links nos meus favoritos e me lembre de consultá-los amanhã cedo.

No dia seguinte....

Agente-C:     Bom dia Inácio! Você tem uma reunião em vídeo conferência com Bianca Lins em 10 minutos. Ela já está on-line.

Inácio:       OK. Podemos começar a reunião.

Inácio:       Bom dia Bianca... Espero que esteja gostando dos seus primeiros dias na empresa.

Bianca:       Obrigada. Estou me sentindo em casa.

Inácio:       Bianca, você analisou nosso relatório de performance que o Agente-C te passou?

Bianca:       Sim, analisei e tomei a liberdade de colocar alguns comentários, anexando-os ao documento.

Inácio:       Ótimo, vou dar uma olhada. Há alguma forma de você nos ajudar a resolver esse problema?

Bianca:       Acho que há meios de melhorar. Preciso de acesso aos testes de unidade e também ao relatório de timing desses testes.

Inácio:       Agente-C, Por favor envie uma senha para a Bianca ter acesso ao nosso código-fonte. Bianca, faça um check-out da mainline. Você precisa de instruções sobre como compilar e executar os testes de unidade?

Bianca:       Sim, Inácio. Mas enquanto conversarmos fiz uma busca aqui no Agente-C, e já estou com um documento com instruções sobre isso. Há inclusive intruções de acesso ao repositório de código-fonte.

Inácio:       Certo, Bianca, muito obrigado pela ajuda. Fico aguardando novas notícias então. Até mais.

Bianca:       Até mais.

Agente-C:     Inácio, a equipe de testes noturnos mandou seu relatório de testes noturnos realizados no branch da versão 2.25 do Sinus. Gostaria de abrir?

Inácio:       Sim.

O Agente-C exibe na tela:

Sistema: Sinus

Branch: Sinus_RC_225

Inácio:       Certo. Como está a situação das correções?

O Agente-C exibe na tela:

Inácio:       Agente-C, por favor me inscreva para monitorar esses 3 issues.

Agente-C:     Inscrição realizada.

Agente-C:     Inácio, o Sr. Mauro Leme gostaria de lhe falar pelo canal de áudio. Você aceita o convite?

Inácio:       Sim.

Mauro:        Inácio, você já deu uma olhada no relatório da equipe noturna?

Inácio:       Sim, o Agente-C acabou de me mostrar.

Agente-C:     O usuário Mauro gostaria que você visualizasse o conteúdo do link que aponta para o Issue de número 0012099.

Inácio:       OK, Mauro, o Issue já está aberto aqui na minha frente.

Mauro:        A questão é a seguinte: Eles pedem que o workflow da solicitação de pagamento possa contemplar caminhos paralelos. Nosso subsistema de workflow ainda não permite isso.

Inácio:       Hummm... entendi. Agente-C, por favor, encaminhe o Issue de número 0012099 para a equipe do subsistema de workflow. Adicione uma referência à esta conversa que tive com o Mauro.

Agente-C:     Issue encaminhado.

Mauro:        OK Inácio. Os outros dois eu termino até o fim da manhã.

Inácio:       OK Mauro, até mais.

Algumas horas depois....

Agente-C:     Sr. Inácio, recebi relatório de Integração Contínua. Também tenho novas informações sobres os Issues 0012098, 0012099 e 0012100.

Inácio:       Ótimo. Primeiro os issues.

Agente-C:     Os issues 00120099 e 00120100 foram dados como resolvidos por Mauro Leme. Um novo comentário foi adicionado ao issue 00120098. Deseja visualizá-lo?

Inácio:       Sim.

Na tela do Agente-C:

              O issue 0012099 foi relacionado como duplicata do issue 0010265 que está no status “Em Fase de Análise”.

Inácio:       OK. Notifique a equipe de testes noturnos sobre isso.

Agente-C:     Usuários notificados.

Inácio:       Me mostre agora o relatório de Integração Contínua.

Na tela do Agente-C:

Tests run: 1089, Failures: 0, Not run: 6, Time: 16 min

Modifications since last build (2)

Inácio:       Agente-C, por favor reabra o Issue 0012100. Atribua-o para o usuário tania.fernandes. Preciso de uma ação anti-regressão nesse Issue.

Agente-C:     Issue reaberto e comentário adicionado.

Inácio:       Agora dispare o processo de build automatizada para gerar uma nova versão desse branch. Notifique as alterações para a equipe noturna.

Agente-C:     Build disparada. Deseja ser informado quando o processo for concluído?

Inácio:       Apenas me informe se houver algum problema. Preciso ir agora.

Giovana:      Bom dia Agente-C!

Agente-C:     Bom dia Giovana!

Giovana:      A equipe noturna retornou algum problema nas tarefas que eu finalizei ontem?

Agente-C:     Negativo. Nenhum retorno.

Giovana:      OK. Qual é a minha próxima tarefa?

Agente-C:     Issue 0012034. Diz respeito à integração dos movimentos importados com os procedimentos de conciliação financeira.

Giovana:      Certo. Por favor, prepare um ambiente local para que eu possa começar a trabalhar nesta tarefa. Enquanto isso vou buscar um café.

Agente-C exibe na tela:

Iniciando procedimento de configuração de ambiente

usuário: giovana.mendes

data: 2003-07-23 08:35:33

Issue 0012034

start check-out procedure

check-out branch sinus_rc_225 to
c:\ giovana.mendes\workingspace\sinus_rc_225\**

building application...

starting required services...

creating web application...