Ao término do primeiro sprint, sua aplicação está andando muito bem e tem todas as histórias aprovadas enquanto no ambiente de testes. Passaremos então para a primeira tentativa de colocá-lo em produção/homologação, e logo descobre-se que o sistema não funciona corretamente nesse novo ambiente, e é gasto muita energia para adaptar diversos detalhes que já eram considerados “prontos”.

Após esse esforço, com a aplicação rodando em outra máquina diferente da de desenvolvimento, os clientes começam a utilizá-la e a quantidade de bugs específicos desse novo ambiente que aparecem sobrecarregam os desenvolvedores. O estranho de tudo isso é que o código original rodava na máquina do desenvolvedor sem problemas, inclusive com testes unitários e de aceite.

Em sistemas que não implementam testes end to end, mesmo que smoke tests e que não se planejam para deploys desde o começo do projeto, é comum encontrar um grande número de bugs no primeiro deploy de homologação, além de uma extrema dificuldade para realizar essa implantação inicial.

A equipe passa então a trabalhar para corrigir essas onda de bugs, fica incapaz de adicionar novas funcionalidades em um ritmo adequado e desanima rapidamente.

Enquanto o processo de deploy não for automatizado, cada nova tentativa de implantação é seguida por uma enchurrada de bugs novos, sempre com as mesmas consequências negativas.

A solução aqui é automatizar todo o processo de deploy desde o primeiro sprint, e para isso você precisa estruturar muito bem seu ambiente, de forma que ele seja perfeitamente replicável entre as máquinas de desenvolvimento, homologação e produção. Isso é bastante planfletado pelo movimento Devops.

Graças aos ciclos mais curtos de deploy, o cliente testa o seu software mais cedo e recebemos feedback mais rápido quanto a bugs existentes, portanto o número de bugs novos sai do zero muito mais cedo, diminuindo um possível susto.

Martin Fowler comentou recentemente sobre a estratégia de manter dois sistemas muito parecidos em paralelo e virar a chave de roteamento de um para o outro para efetuar a transição, processo que pode e deve ser automatizado por completo em aplicações de alta disponibilidade. Fábio Akita da Locaweb explica uma estratégia simples para deploy contínuo através do uso do git.

Tudo isso minimiza o acúmulo de bugs, resultando em um ritmo constante, mas menor, de aparição de problemas, inerentes a qualquer processo.

Com o deploy contínuo através de técnicas como a citada pelo Akita, cada commit terá não só suas baterias de testes rodados, mas entra em homologação. Os bugs aparecem mais cedo durante o desenvolvimento do projeto e o processo de deploy pode ser efetuado mais frequentemente.

Indo além, com um sistema blue-green, seu processo de deploy atinge um nível maior ainda de maturidade, com a possibilidade de um rollback robusto a qualquer instante.

Como você está tratando o seu deploy?

Em 2008 comentamos sobre a importância de integração contínua no processo de receber feedback rápido sobre suas mudanças em um sistema e depois sobre os problemas que surgem quando um sistema possui baterias de teste muito grandes e complexas.

Um das grandes vantagens da agilidade consiste em poder efetuar mudanças sem medo e receber as respostas rapidamente em relação aos bugs que introduzimos no sistema, evitando mais erros e, para atingir esse objetivo, um servidor de integração contínua deve integrar o nosso código com aquele existente e rodar a bateria de testes automatizados a cada commit, criando um relatório do que foi feito que pode ter quebrado a aplicação.

Existem diversos níveis de adoção de um servidor de integração contínua em um projeto, indo do mais básico que envolve a simples compilação de um projeto (quando a linguagem é compilada) e a execução de testes unitários, até cenários mais complexos. Uma das principais dores de cabeça que um cliente enfrenta, mesmo em empresas que adotam metodologias ágeis como XP e Scrum, está ligada ao produto ser colocado em produção e não funcionar: a famosa frase “mas no meu computador funcionou”.

Um cenário clássico envolve o desenvolvimento de testes unitários, que são rodados na máquina do desenvolvedor e no servidor de integração contínua. O desenvolvedor chama então o cliente para testar em sua máquina, que aprova a funcionalidade e depois de duas semanas é feito o deploy da aplicação quando, para a surpresa do cliente, ela não funciona como esperado.

Acontece que a máquina de desenvolvimento em geral não possui a mesma configuração – software de banco de dados, servidor, proxies, firewall ou até mesmo os dados contidos no banco – que o sistema em produção, e mudanças do gênero podem significar resultados completamente diferentes para o cliente que, no fim da iteração, não obtém o valor que esperava.

A solução está em criar um sistema de homologação e diversas empresas adotam essa prática. A dificuldade encontrada nessa etapa é a da não automatização do processo de réplica da estrutura e dados de produção para homologação. Dados antigos ou inadequados no ambiente de aprovação facilitam um aceite errôneo por parte do cliente no momento do teste. Na Caelum e em nossos clientes que possuem sistemas que efetuam deploy diversas vezes em um ano, para garantir a competibilidade da empresa, é comum automatizar o processo de deploy ao ponto de maximizar as semelhanças entre produção e homologação, e minimizar as idas e vindas de uma funcionalidade.

Passo a passo junto com o cliente, cada fase é incluída no pipeline de integração contínua. Primeiro o projeto é compilado, depois os testes unitários são executados. Essas duas fases do pipeline são padrão para linguagens compiladas como Java. Em algumas empresas devido ao código legado ter um acoplamento muito alto, essa primeira fase já envolve mudanças na maneira de trabalhar e na qualidade do código gerado pelos desenvolvedores.

As fases seguintes variam bastante de acordo com projeto, mas para melhorar o deploy que minimize o número de tentativas de aprovação é importante adicionar três fases: testes end-to-end automatizados, deploy para homologação e para produção em um clique.

Na primeira fase, os testes executam as funcionalidades como o cliente faria e cobrem a maior quantidade de funções plausíveis de automatização. Na segunda fase, os desenvolvedores podem optar por deployar para um sistema de homologação, onde o cliente aprovará com os dados copiados de produção (alterações ligadas a sigilo de dados devem ser aplicadas).

Por fim, quando o sistema está aprovado em homologação, com um clique o desenvolvedor efetua o deploy para produção. Nesse instante, os sistemas são restartados, de preferência com o uso de load balancers que permitem o restart sem a queda da aplicação, e o cliente está pronto para usar as funcionalidades novas.

Toda essa automatização tem um custo inicial de desenvolvimento que é compensado com a minimização de erros humanos no processo de deploy e na lentidão do mesmo. Muitas vezes o processo de deploy para qualquer um dos dois ambientes não é feito tão frequentemente devido ao processo ser demasiadamente complexo para ser executado manualmente. A chance de funcionar em produção é maximizada uma vez que a mesma foi testada em homologação com uma cópia mais fidedigna do sistema de produção possível: menos reclamações e tempo perdido pelo cliente.

Note que nenhuma ferramenta específica é necessária para adotar essa prática, basta mudar o método de trabalho.

Boa notícia: já estamos disponibilizando uma palestra do Falando em Agile 2008!

Quem fala é Danilo Bardusco, gerente de desenvolvimento de aplicações Web na Globo.com, com a palestra entitulada “Scrum na Globo.com: Derrubando Mitos“. Aproveitem!

Veja também outras palestras do Falando em Agile 2008:

• Scrum na Globo.com: Derrubando mitos, com Danilo Bardusco
• Agilidade de Tartaruga, com Danilo Sato e Francisco Trindade
• Contratação de projetos de Software, manutenção de sistemas e portfólio de projetos com Agilidade, por José Papo

“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler

Integração Contínua tornou-se muito importante na comunidade de desenvolvimento de software e isso provavelmente ocorreu devido ao grande impacto causado pelas metodologias ágeis. Em equipes que adotaram tais metodologias (eXtreme Programming, Scrum, entre outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do código estejam sendo alteradas ao mesmo tempo.

Mas porque fazer Integração Contínua ? Quais os benefícios que isso pode trazer ?

Basicamente, a grande vantagem da integração contínua está no feedback instantâneo. Isso funciona da seguinte forma: a cada commit no repositório, o build é feito automáticamente, com todos os testes sendo executados de forma automática e falhas sendo detectadas. Se algum commit não compilar ou quebrar qualquer um dos testes, a equipe toma conhecimento instantâneamente (através de email, por exemplo, indicando as falhas e o commit causador das mesmas). A equipe pode então corrigir o problema o mais rápido possível, o que é fundamental para não introduzir erros ao criar novas funcionalidades, refatorar, etc. Integração contínua é mais uma forma de trazer segurança em relação a mudanças: você pode fazer modificações sem medo, pois será avisado caso algo saia do esperado.

Mas porque eu não rodo pessoalmente os testes na minha máquina e só então faço o commit?
Simples: seu projeto pode ser tão grande, que os testes (em especial os de aceite) demoram um tempo considerável para serem executados e você não vai querer esperar todo esse tempo a cada commit pra poder continuar a trabalhar. Nesse caso, o recomendado é rodar os testes que envolvem as partes que você modificou e só então commitar, deixando para o servidor de integração contínua o trabalho de realizar todos os testes do sistema e garantir que tudo esteja funcionando. Além disso, não estamos falando apenas de testes, estamos falando de builds completos: a cada commit temos uma versão que teoricamente está pronta para entrar em produção, e isso pode envolver a realização de tarefas que não faríamos se estivessemos só testando, como por exemplo gerar um arquivo .war. O projeto pode ainda ser implantado automaticamente num servidor de desenvolvimento/homologação, e então com isso a cada commit temos o projeto rodando na web instantaneamente refletindo nossas mudanças!

Um outro exemplo interessante é o processo de geração das apostilas dos nossos cursos: a cada commit feito no repositório, o servidor faz o check-out, executa o Tubaina, que transforma o fonte em latex, convertendo o latex gerado em pdf e por fim copiando esse pdf num diretório interno, pronto para impressão na gráfica. Dessa maneira, garantimos que disponibilizamos para nossos alunos o material mais atualizado disponível.
Para tudo isso funcionar, no entanto, é preciso agarrar a idéia de commits pequenos. Fica mais fácil saber onde foi introduzido um erro quando o build quebrar se houveram pequenas mudanças, do que ter de verificar as ultimas 50 classes alteradas no ultimo commit. Outro ponto importante, é garantir ao menos um build limpo, com todos os testes passando, ao final de cada dia. Assim, teremos software pronto para entrar em produção tão cedo seja necessário.

Em outras palavras, podemos descrever Integração Contínua como integração automática com processo de build automático e que roda testes de forma automática e automaticamente detecta falhas em cada pedaço.

Abaixo as ferramentas que usamos aqui na Caelum:

• CruiseControl.rb: desenvolvida pela ThoughtWorks, é a aplicação de integração contínua. Capaz de constantemente verificar os repositórios em busca de novos commits, fazendo check-out e rodando tarefas pré-determinadas. O interessante dessa ferramenta é que ela trabalha com qualquer tipo de projeto: ruby, java, ou qualquer outro cujo build possa ser feito através da linha de comando. Além disso, tem sua interface extremamente simples e funcional .

CruiseControl.rb

CruiseControl.rb build report

• CCMenu, ou CCTray: permite acompanhar o build de cada projeto sem ter de entrar no site do CruiseControl.rb. Isso é feito através de um ícone alertando quais projetos estão com o build quebrado.
• Selenium: também desenvolvida pela ThoughWorks, provê maneira de realizar testes de integração em projetos Web, simulando a navegação do usuário pelas páginas do site, realizando diversas ações como clicar o mouse, prencher campos, etc… Usado para validar se o resultado de determinadas ações do usuario correspondem às que esperamos.
• Xvfb: Servidor X11 que permite realizar todas as operações gráficas em memória, não exibindo nada na tela. Com essa ferramenta, é possível rodas os testes com Selenium sem ter as janelas do Firefox pulando na tela do nosso servidor a cada teste. Além disso, podemos rodar os testes mesmo em ambientes sem X instalado (como é o caso de servidores, por ex).

Ainda usamos plugins Maven e Ant para a geração de relatórios de cobertura e testes, que publicamos a cada novo build. Assim, conseguimos além de garantir que o código está todo integrado, garantir que está com uma cobertura adequada; afinal, de que adianta ter o sistema sem testes falhando, se ele possui menos testes que o necessário?

JUnit Report

Cobertura Report

Por fim, pela experiência que temos no uso dessas ferramentas no desenvolvimento de aplicações internas, open source e em nossos clientes, podemos afirmar que elas de fato nos trazem uma produtividade antes inalcançável. Se você pensa em começar a utilizar alguma ferramentas de integracão contínua, vale a pena dar uma olhada nessas que indicamos. No entanto, existem várias outras disponíveis, e é questão de escolher a que melhor se adapta às suas necessidades. Não deixe de comparilhar suas experiências…

O Falando em Agile 2008 deixou saudades! Foi muito bom ver profissionais experientes não só em Agile, mas no mundo de software como um todo, discutindo durante dois dias sobre a difícil arte de fazer projetos darem certo, entregando software funcionando e com valor para o cliente. Foi muito bom ver profissionais de todos os mundo juntos: Java, .NET, Delphi, PMBok, Scrum, XP, FDD…em busca de um único objetivo!

Tivemos palestras abordando assunto para todos os gostos: cases de sucesso apresentados pela Dell, Aeronáutica e Globo.com; alertas sobre as dificuldades para a implantação de Agile; modelos para contratação de projetos ágeis; Scrum em ambientes PMBok; Kanban e muito mais. Foi realmente uma overdose!

UPDATE: Veja o vídeo de algumas das palestras.

Eu poderia neste post relatar cada uma das palestras, citar pontos positivos e negativos do evento, enfim, falar em detalhes do evento. No entanto a comunidade já está fazendo isto com maestria, então cito abaixo alguns posts sobre o Falando em Agile 2008:

Vitor Hugo Germano,
Daniel Wildt
André Faria Gomes
Fabricio Sousa
Inove
André Ferreira
Danilo Bardusco,
Guilherme Chapiewski
Antonio Carlos Silveira
Philip Calçado
Flickr do Antônio Carlos
Danilo Sato

Nós da Caelum agradecemos a todos os palestrantes, que tornaram o evento muito mais especial, e as empresas que patrocinaram e apoiaram o evento: Globo.com, Yahoo! Brasil, Borland, além da Heptagon, Sea Tecnologia, Locaweb, Scrum Alliance e ThoughtWorks. Vejo vocês
no Falando em Agile 2009, e aguardem a disponbilização de algumas palestras do evento!