Este documento discute a integração contínua com o Hudson/Jenkins. Descreve Hudson/Jenkins como um servidor de integração contínua que executa builds de projetos periodicamente e valida o código através de testes e outras validações. Também discute como configurar projetos no Hudson/Jenkins para suportar dependências entre projetos, builds distribuídos em vários nós, e notificações de resultados de builds.

1. Integração Contínua
com Hudson
Portugal GTUG

2. Quem sou eu
• Director de I&D na YUNIT
• Certified Scrum Master (Actualmente Product Owner)
• Trabalhou, Trabalha ou Envolvido em
• Desenvolvimento Web - HTML, JS, CSS, Canvas, SVG, etc.
• Java (Stack Web + JDBC) + RMI + Sistemas Distribuídos > J2EE
• Ruby / Ruby on Rails
• Visualização: Processing / Java2D / JOGL
• Computação Física: Arduino / Luzes / Cenas, Man
2

3. Integração Contínua
• 1 das 12 práticas do Extreme Programming
• Periodicamente* pegar na ultima versão do
código no controlo de versões e validar**
• Periodicamente:
• Diariamente, “Horariamente”, ou, melhor ainda, por triggers
no Controlo de Versões
• Validar:
• Dependendo do tipo de projecto: validar ficheiros de
configuração, compilar código, executar testes
3

4. Integração Contínua
• Sincronização da equipa
• Forma Simples e Eficaz™ de garantir que
alterações individuais não invalidam o
conjunto
• Testes
• Divida Técnica
• Michael Feathers, Working Effectively with
Legacy Code
4

5. Como começar ?
• Num novo projecto
• Assim que houver um mecanismo de build
• Num projecto já existente:
• Garantir que o código compila
• Garantir que o código é empacotado
• Correr testes
• Acrescentar outras validações
• Aplicar STFUDD o mais possível !! 5

6. Hudson/Jenkins
• Servidor de Integração Contínua
• Trabalha à base de projectos/jobs
• Extensível com plugins
• Distribuído
• Desenvolvimento muito activo
• Apelativo / Fácil de usar (Destronou o
Cruise Control por estas razões)
6

7. Projectos
• Trigger
• Baseado em Tempo (=crontab), via Polling ou VCS Hook
• Setup
• Pull do controlo de versões, fetch de artefactos, scripts de
inicialização
• Build
• Script, Ant, Maven, Rake (em vários passos)
• Post-Build
• Notificações, relatórios, publicação de artefactos, plugins 7

8. Builds Distribuídos
• Os slaves podem ser arrancados de várias
formas (serviço windows, java webstart, ssh,
script local) ou podem ser VMs em máquinas
remotas.
• Cada nó pode ser marcado com etiquetas (db,
mac, linux, app, ...)
• Podem-se lançar slaves em serviços como o
EC2
• Podem-se criar slaves por pxeboot (pen USB) 8

9. Projectos com
Dependências
• Um projecto pode ser configurado para
publicar artefactos para uso por outros.
Neste caso, também se despoletam builds
dos segundos projectos
• Exemplos:
• Geração de JARs com bibliotecas de
integração / código comum
9

10. Aplicações Enterprisey
• Pode ser preciso colocar código num container para o
poder testar, eg, EJBs, web apps
• Nestas situações pode ser preciso usar uma base de dados
dedicada, um container num ambiente dedicado, etc.
• Os projectos têm de passar a:
• Compilar código, limpar e popular BD, limpar container,
lançar código, correr testes, [lavar a louça...]
• STFUDD é muito importante aqui: Mais vale um sistema
complicado e lento a funcionar do que um perfeito em
lado nenhum
10

11. Uso como Crontab
• O Hudson também pode ser usado como
crontab.
• Tem as vantagens:
• Gestão fácil
• Contenção de carga
• Garantia de serialização de tarefas
11

12. Notificações / Output
• As notificações dos resultados dos builds podem ser
dadas por:
• IRC
• XMPP
• Mail
• A melhor solução consiste num radiador de informação
bem visível:
• Plugin “Radiator View”
• Luzes / Sirenes
12

13. Hudson
• Obrigado,
• Querem ver as luzes ?
• Q&A
13