Dispositivos de Extreme Feedback são objetos que chamam a atenção da equipe de desenvolvimento para alguma métrica ou processo importante. Há vários artigos disponíveis sobre o uso destes dispositivos e equipes que os experimentaram observaram um aumento do comprometimento do time com o processo que está sendo monitorado. Além de, é claro, deixar o ambiente de desenvolvimento bem mais divertido.
Dispositivos para monitorar builds são cada vez mais comuns. Existem lâmpadas que mudam de cor, robozinhos, ursos iluminados... Enfim, basta usar a imaginação e obter um objeto que permita algum tipo de programação para criar um dispositivo de Extreme Feedback.
A ferramenta de integração contínua Hudson já possui integração com diversos dispositivos de extreme feedback, como o TuxDroid e o Nabaztag. A verdade é que é muito simples integrar o Hudson com um destes disposivos. Basta que eles sejam capazes de acessar a internet para se comunicar com o servidor e recuperar os dados necessários.
Neste artigo, você vai aprender como criar o seu dispositivo de Extreme Feedback para monitorar os seus builds no Hudson. Embora a técnica que será apresentada possa ser usada em diversos dispositivos, o exemplo deste artigo mostra como foi desenvolvida o widget Hudson Monitor para o Chumby. O Chumby é um pequeno dispositivo, parecido com um rádio relógio, que possui Wi-fi e é capaz de executar aplicações feitas em flash. Existem diversas aplicações para o Chumby: widgets que que mostram a previsão do tempo, posts do Twitter, notícias, jogos, e muito mais. Então, por que não usar o Chumby para avisar quando uma build quebrou? Basta um pouco de programação em flash e mais um dispositivo de extreme feedback estará disponível.
Uma técnica comum e fácil para detectar se uma build terminou com falha é consultar um dos feeds RSS disponibilizados pelo Hudson. O link dos feeds RSS podem ser facilmente encontrados na página principal do Hudson, como mostra a figura 1. Nesta figura, a seta mostra onde encontrar os feeds RSS do Hudson.
Figura 1 - links para os RSS do Hudson
Para desenvolver um dispositivo de extreme feedback, provavelmente o RSS mais adequado é o que aparece no link "apenas as últimas construções". Este RSS contém o resultado dos últimos builds, tanto os que falharam quanto os que tiveram sucesso. Se você preferir, você pode usar também o RSS que contém somente os builds que falharam, mas usando o RSS que contém os últimos builds você consegue dar tanto um feedback positivo quanto um feedback negativo, o que em geral é melhor.
Observando o conteúdo da RSS para os últimos builds, é possível notar que a sua estrutura é bastante simples. Veja:
<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>All last builds only</title>
<link href="http://sampleserver/hudson/" rel="alternate" type="text/html"/>
<updated>2010-08-11T00:01:42Z</updated>
<author>
<name>Hudson Server</name>
</author>
<id>urn:uuid:903deee0-7bfa-11db-9fe1-0800200c9a66</id>
<entry>
<title>Hard-Project #16 (FAILURE)</title>
<link href="http://sampleserver/hudson/job/Hard-Project/16/" rel="alternate" type="text/html"/>
<id>tag:hudson.dev.java.net,2008:http://sampleserver/hudson/job/Hard-Project/</id>
<published>2010-08-11T00:01:42Z</published>
<updated>2010-08-11T00:01:42Z</updated>
</entry>
<entry>
<title>Hudson Test Build #336 (SUCCESS)</title>
<link href="http://sampleserver/hudson/job/Hudson%20Test%20Build/336/" rel="alternate" type="text/html"/><id>tag:hudson.dev.java.net,2008:http://sampleserver/hudson/job/Hudson%20Test%20Build/</id>
<published>2010-08-10T16:01:42Z</published>
<updated>2010-08-10T16:01:42Z</updated>
</entry>
</feed>
Note que cada build é representada pela tag <entry>. Para saber se um determinado build quebrou, é necessário parsear a string contida na tag entry/title. Se você encontrar a palavra "FAILURE", o build quebrou. Se encontrar "SUCCESS", o build terminou com sucesso. O nome do projeto também é obtido da tag entry/title, assim como o número do build que falhou. Por isso, a estratégia é iterar por todas as tags entry do RSS, parseando o conteúdo da tag entry/title para obter os dados de cada build.
A figura 2 mostra a interface da aplicação do Chumby para um build quebrado e para um build de sucesso. No Chumby, como a tela é pequena, a estratégia foi mostrar o resultado de um build por tela e ir alternando as telas até que todas as builds sejam apresentadas. Se você está usando outro dispositivo de extreme feedback, você pode escolher outra forma de apresentar os resultados.
Figura 2 - A interface do Chumby para uma build quebrada e uma build com sucesso
Embora a estratégia de ler o RSS seja simples de implementar, existem dois problemas que podem dificultar o uso desta técnica. O primeiro problema vem do fato de a aplicação do Chumby ser feita em flash. Por limitações de segurança, uma aplicação em flash só pode acessar um domínio diferente daquele em que ela está sendo executada se o servidor permitir o acesso através de um arquivo "crossdomain.xml". Você pode ler mais sobre o assunto nestes dois links:
- External data not accessible outside a Macromedia Flash movie's domain
- Security Changes in Macromedia Flash Player 7
Se você estiver desenvolvendo uma aplicação de extreme feedback em flash, lembre-se que você precisa colocar um arquivo crossdomain.xml na raiz do seu servidor web para permitir o acesso da aplicação ao seu servidor Hudson. Como um exemplo, o crossdomain.xml usado para a aplicação do Chumby pode ser visto aqui.
O segundo problema pode ocorrer se você estiver usando o seu servidor Hudson com autenticação e com HTTPS, o que é extremamente recomendável em projetos privados. Se você está usando HTTPS, algumas aplicações podem ter dificuldade em acessar o seu servidor. Aplicações em flash que são executadas em ambientes HTTP, por exemplo, não podem acessar dados externos através de HTTPS. A necessidade de autenticação também pode ser um impeditivo para o seu dispositivo acessar o RSS.
A aplicação do Chumby possui estes dois problemas: o Chumby executa em HTTP e não pode acessar um RSS em HTTPS. Além disso, o Chumby não consegue se autenticar em um servidor Hudson com controle de acesso.
Uma forma de contornar este problema é publicar uma cópia do RSS em uma área que não requer autenticação e que possa ser acessada via HTTP. Se a informação contida no RSS não for sensível para você, esta é uma boa solução.
Existem várias formas de publicar uma cópia não segura do RSS, mas uma boa alternativa é usar o próprio Hudson para fazer isso: crie um novo build no seu Hudson que seja executado de tempos em tempos ou que seja executado automaticamente após cada build concluído. No campo "commands" deste build, coloque o seguinte:
wget --no-check-certificate --save-cookies /temp/hudson-authentication-cookie \
--output-document "-" \
'https://your.server.com/hudson/j_acegi_security_check?j_username=a_user&j_password=a_password&remember_me=true' >/dev/nullwget --no-check-certificate --load-cookies /temp/hudson-authentication-cookie \
-O /var/www/rss/rssLatest https://your.server.com/hudson/rssLatest
O primeiro comando vai se autenticar no Hudson, guardando o cookie de autenticação em um diretório temporário. O segundo comando vai usar este cookie para recuperar o RSS e gravá-lo em um diretório onde ele poderá ser recuperado via HTTP sem necessidade de autenticação. Obviamente você precisa adaptar estes comandos para o seu ambiente, colocando o seu servidor, diretórios, usuário e senha.
O código fonte do Hudson Monitor para o Chumby está disponível no site do projeto e você pode usá-lo como exemplo para criar seu próprio dispositivo.
Caso você não possua nenhum dispositivo programável para usar como Extreme Feedback, você pode usar um computador antigo, colocar a tela em um lugar visível, e deixar a sua aplicação de Extreme Feedback rodando nele. Como exemplo, a mesma aplicação em flash do Chumby tem uma versão que pode ser usada assim disponível aqui. Se você decidir usá-la, no entanto, não esqueça que como é uma aplicação em flash você precisa se preocupar em configurar o crossdomain.xml, liberando o acesso para o site em que ela está hospedada.
Além da técnica de acessar o RSS, uma outra alternativa é criar um plugin para o Hudson e fazer este plugin enviar as informações necessárias para o dispositivo de Extreme Feedback. Mas esta técnica é um pouco mais complicada e depende do dispositivo utilizado suportar este tipo de comunicação.
E você? Já usou um dispositivo de Extreme Feedback? Qual foi o resultado?