Programa de Mestrado em Ciência da Computação
IN1149 – Qualidade, Processos e Gestão
Integração Contínua
Rafael Vanderlei de Souza
[email protected]
13/10/2008
Universidade Federal
de Pernambuco
Agenda






Introdução
Princípios
Reduzindo Riscos
Ferramentas
Conclusões
Referências
Universidade Federal
de Pernambuco
2
Introdução
Universidade Federal
de Pernambuco
3
Motivação

Consideremos o seguinte processo típico de
desenvolvimento:
◦
◦
◦
◦
◦
◦
◦
◦
◦
◦
Desenvolvedor baixa código da baseline
Código é implementado e compilado
Base de dados é ajustada
Testes unitários são executados
Desenvolvedor sobe código para a baseline
Testes de integração são executados
Código integrado é inspecionado
É gerado um executável
Testes de sistema são executados
Partes interessadas são informadas dos resultados
Universidade Federal
de Pernambuco
4
Motivação

Alguns possíveis problemas:
◦ Desenvolvedor demora para subir o código e outro
desenvolvedor já alterou o mesmo código
◦ Desenvolvedor esqueceu de subir algum arquivo
◦ Na hora de gerar um executável, o desenvolvedor
esqueceu de realizar algum passo (alguma
configuração de ambiente)
◦ Os testes encontraram bugs. O desenvolvedor precisa
ajustar os dados e executar os testes manuais
novamente?
◦ O testador esqueceu de notificar o desenvolvedor
sobre o bugs encontrados.
◦ Algum padrão de codificação passou despercebido.
Universidade Federal
de Pernambuco
5
Motivação

Solução:
◦ Não podemos demorar para integrar o código
◦ Precisamos
processo
automatizar
muitas
◦ Não podemos correr tantos riscos
◦ Precisamos de Integração Contínua
Universidade Federal
de Pernambuco
6
das
etapas
do
Definição
“Integração contínua é uma prática de desenvolvimento
de software onde os membros de uma equipe integram
seu trabalho freqüentemente (pelo menos uma vez por
dia). Cada integração passa por um processo de build
automatizado (incluindo testes) para detectar erros de
integração o mais cedo possível.”
Martin Fowler.
Universidade Federal
de Pernambuco
7
Objetivos

Aumentar a qualidade do software
◦ Testes automatizados
◦ Inspeção automatizada

Reduzir riscos do projeto
◦
◦
◦
◦

Ter sempre um executável
Descobrir e corrigir erros rapidamente
Automatizar processos repetitivos e sujeitos a falhas
Ter visibilidade do projeto facilmente
Tornar a integração um “nonevent”
◦ Dedicar o tempo para tarefas mais importantes
Universidade Federal
de Pernambuco
8
Objetivos
Se integrar fosse tão simples assim...
Universidade Federal
de Pernambuco
9
Visão Geral

Cenário típico usando CI:
◦ O desenvolvedor implementa código e efetua o commit
◦ Um servidor de CI percebe que o repositório do controle de versão
sofreu alguma alteração, baixa a versão mais atual da baseline e
executa um script de build, que integra o software
◦ Em seguida, o servidor de CI gera uma notificação de feedback
para os membros interessados e continua verificando se houve
mudança no repositório
Universidade Federal
de Pernambuco
10
Visão Geral
Processo típico de CI...
Universidade Federal
de Pernambuco
11
Visão Geral
A mágica por trás do botão Integrate...
Universidade Federal
de Pernambuco
12
Princípios
Universidade Federal
de Pernambuco
13
Princípios



Integração Contínua possui um conjunto de princípios
que nos permitem fazer mudanças no código com
maior confiança
Praticando CI, sabemos que se alguma mudança
quebrar o código, receberemos feedback imediato e
teremos tempo para corrigir e fazer ajustes mais
rapidamente.
Princípios:
◦ Efetuar commit freqüentemente
◦ Não subir código quebrado
◦ Rodar private builds
◦ Escrever testes unitários automatizados
◦ 100% dos testes e inspeções precisam passar
◦ Consertar builds quebrados imediatamente
Universidade Federal
de Pernambuco
14
Commits Freqüentes



Esperar muito tempo para subir código pode tornar a
integração muito trabalhosa e ainda pode fazer com
que outros desenvolvedores trabalhem com código
desatualizado.
Faça pequenas mudanças. Tente não modificar muitos
componentes de uma vez. Escolha uma tarefa pequena,
escreva código e testes e efetue o commit.
Procure sempre efetuar o commit após a realização de
cada tarefa
Universidade Federal
de Pernambuco
15
Não Subir Código Quebrado



Evitar que subamos código quebrado pode não ser uma
tarefa fácil.
Não podemos assumir que todos os desenvolvedores
terão o cuidado de não subir código quebrado.
Para
evitar
isso,
é
recomendado
que
cada
desenvolvedor rode um private build antes de subir seu
código.
Universidade Federal
de Pernambuco
16
Rodar Private Build




Necessário para evitar que subamos código quebrado.
Um private build consiste de emular uma integração
completa, com o código atual que encontra-se no
repositório antes de subir o código para o repositório.
Algumas ferramentas possuem facilidades que
permitem o desenvolvedor baixar o código e rodar o
build local já com as mudanças que ele efetuou.
Outras ferramentas executam o build imediatamente
antes de as mudanças serem consagradas no
repositório.
Universidade Federal
de Pernambuco
17
Testes Automatizados



O processo de
automatizado.
build
precisa
ser
totalmente
Para tanto, é possível utilizar ferramentas que fornecem
a capacidade de executar testes de maneira
automatizada.
Com testes automatizados, podemos executar testes de
regressão para garantir que caso bugs antigos voltem a
acontecer, eles serão detectados no próximo build.
Universidade Federal
de Pernambuco
18
Todos os Testes e Inspeções
Devem Passar



É muito fácil aceitar o fato de que código só funciona se
compilar.
Porém, algumas pessoas não percebem que, em termos
de funcionamento, 100% dos testes precisam passar
para que o código seja considerado funcional.
Já uma falha em uma regra da inspeção pode não afetar
o funcionamento do código, porém, para que o código
tenha boa qualidade, também é de extrema importância
que o build não tenha sucesso caso as inspeções
falhem.
Universidade Federal
de Pernambuco
19
Consertar Builds Quebrados
Imediatamente



Um build quebrado pode ser conseqüência de um erro
de compilação, ou de uma falha em um teste ou
inspeção.
Se não corrigirmos a baseline logo, desenvolvedores
podem passar muito tempo trabalhando com código
quebrado e os erros serão replicados, dificultando as
correções posteriormente.
Algumas empresas definem culturas de motivação para
corrigir rapidamente builds quebrados:
◦ O desenvolvedor que quebrou o código deposita uma quantia de
dinheiro a cada fração de tempo que o código permanece
quebrado.
Universidade Federal
de Pernambuco
20
Reduzindo Riscos
Universidade Federal
de Pernambuco
21
Reduzindo Riscos



Algo sempre vai dar errado em um projeto.
Praticando CI, é possível descobrir o que está errado
mais rapidamente, tornando mais fácil avaliar e reportar
a saúde do projeto com base em evidências concretas.
Alguns riscos que podem ser reduzidos praticando CI:
◦ Falta de um executável pronto para implantar a qualquer momento
◦ Descoberta tardia de defeitos
◦ Falta de visibilidade do projeto
◦ Baixa qualidade do software
Universidade Federal
de Pernambuco
22
Falta de Implantável

A equipe terminou a implementação muito próximo da
data de entrega. Porém, ainda é necessário passar mais
algumas horas para integrar, testar, inspecionar e gerar
o executável.
◦ Se demorarmos para integrar, pode ser que o tempo restante não
seja suficiente, fazendo com que percamos marcos críticos no ciclo
de vida.
Solução: Integrando várias vezes por dia, o esforço e o
tempo gastos para gerar um executável são reduzidos.
Universidade Federal
de Pernambuco
23
Falta de Implantável

O processo de geração do build de integração é
realizado na máquina de um único desenvolvedor,
iniciado a partir de uma IDE e ainda exige alguns
passos manuais.
◦ O desenvolvedor precisa estar disponível
◦ Para gerar o build a partir de outra máquina, é preciso que a IDE
esteja configurada corretamente
◦ O desenvolvedor pode esquecer de executar algum passo manual
Solução: O script de build precisa ser independente de
IDE e precisa automatizar todos os passos manuais
repetitivos.
Universidade Federal
de Pernambuco
24
Falta de Implantável

A última versão enviada para teste não está
funcionando
adequadamente,
embora
esteja
funcionando
perfeitamente
na
máquina
do
desenvolvedor.
Solução: É preciso utilizar uma máquina dedicada para
fazer a integração. Tudo que seja necessário para a
integração (scripts de banco, testes, regras de
inspeção, etc.) precisa estar no repositório.
Universidade Federal
de Pernambuco
25
Descoberta Tardia de Defeitos

Os testes executados sobre a última versão enviada
detectaram erros que já haviam sido corrigidos 2 meses
atrás.
Solução: Antes de subir o código, é preciso fazer uma
integração na máquina do desenvolvedor. Para que
erros previamente corrigidos não se repitam no código
que está no repositório, é preciso que existam testes
automatizados para viabilizar a execução de testes de
regressão.
Universidade Federal
de Pernambuco
26
Descoberta Tardia de Defeitos

Todos os testes executaram com sucesso e nenhum
bug foi encontrado. Porém, o cliente reclamou de
dezenas de erros.
Solução: Quando o desenvolvedor achar que já escreveu
os testes para seu código, é importante que ele execute
uma ferramenta de cobertura de código testado. Assim,
ele encontrará, com maior facilidade, pontos críticos do
código que não estavam sendo testados.
Universidade Federal
de Pernambuco
27
Falta de Visibilidade

O líder de testes passou uns dias fora da empresa e
agora está aguardando que uma versão seja liberada
para iniciar uma bateria de testes. Por acaso, ele
descobre que a versão já foi liberada 2 dias atrás.
Solução: Utilizando um servidor de CI, é possível
configurá-lo para enviar notificações sempre que um
build é realizado (com ou sem sucesso). As notificações
podem ser enviadas por email, ou até mesmo por SMS.
Universidade Federal
de Pernambuco
28
Falta de Visibilidade

Um novo membro entra na equipe e precisa de
diagramas UML para ter uma visão geral da arquitetura
do sistema. Porém, talvez por questões de cronograma
ou de bem entendimento entre os membros da equipe
atual, os diagramas deixaram de ser atualizados.
Solução: Utilizando um servidor de CI, é possível
configurá-lo para executar ferramentas de geração de
documentação e diagramação de código. Fazendo essa
geração parte do processo de build, para cada versão
sempre haverá uma versão atualizada dos diagramas.
Universidade Federal
de Pernambuco
29
Baixa Qualidade

A equipe está sentindo dificuldade em ler o código de
um novo membro da equipe, que não leu o documento
de 30 páginas sobre os padrões de codificação e vem
adotando seus próprios padrões.
Solução: Ao invés de escrever um documento de 30
páginas, é possível criar uma classe que contém todos
os padrões de codificação e que é utilizada por uma
ferramenta que garante a aderência aos padrões
executando inspeção automática.
Universidade Federal
de Pernambuco
30
Baixa Qualidade

Um desenvolvedor precisa implementar um trecho
complexo de código, encontra um trecho parecido em
outra funcionalidade, copia-o e cola-o no seu método e
faz alguns pequenos ajustes. Esse processo é repetido
por outros desenvolvedores e o código já se repete em
15 pontos da aplicação. Porém, agora é necessário
fazer um ajuste crítico nesse trecho de código...
Solução: É possível utilizar ferramentas de inspeção de
código que encontram possíveis duplicações de código
e fazer com que essa inspeção torne-se parte do
processo de integração. Na primeira vez que o código
duplicado é identificado, a equipe pode desenvolver um
componente e usar sua interface quando necessário.
Universidade Federal
de Pernambuco
31
Ferramentas
Universidade Federal
de Pernambuco
32
Ferramentas

Servidores de CI:
◦ Cruise Control, Apache Continuum, LuntBuild, Hudson, Bamboo,
Pulse, Gauntlet

Build:
◦ Maven, Ant, NAnt, Rake

Controle de Versão
◦ Subversion, CVS, ClearCase, VSS, StarTeam

Banco de dados
◦ Oracle, SQL Server, PostgreSQL, MySQL, HSQLDB

Teste
◦ JUnit, NUnit, DbUnit, HtmlUnit, Selenium, TestNG

Inspeção
◦ Checkstyle, FindBugs, Cobertura, EMMA, FxCop

Feedback
◦ Ambient Device, Jabber, Gtalk
Universidade Federal
de Pernambuco
33
Conclusões
Universidade Federal
de Pernambuco
34
Conclusões



Integração Contínua nos permite reduzir trabalho
repetitivo e sujeito a erros, automatizando os processos
de compilação, integração da base de dados, execução
de testes, realização de inspeção, geração de
executável e mecanismos de feedback.
Com isso, é possível reduzir alguns riscos durante o
desenvolvimento e aumentar a qualidade do software.
Como vimos, existe uma
ferramentas que auxiliam
Integração Contínua.
Universidade Federal
de Pernambuco
35
grande quantidade
na implementação
de
da
Conclusões
E você? Já está fazendo integração contínua?






Está usando um repositório de controle de versão e
guardando todos os artefatos necessários para gerar
build neste repositório?
Seu processo de build é automatizado e repetível? O
build ocorre inteiramente sem intervenção humana?
Está escrevendo e executando testes automatizados?
Como você garante que padrões de codificação e de
projeto estão sendo seguidos?
Os mecanismos de feedback estão automatizados?
Está usando uma máquina dedicada para fazer a
integração?
Universidade Federal
de Pernambuco
36
Referências
Universidade Federal
de Pernambuco
37
Referências

Fowler, Martin. Continuous Integration.
◦ Disponível em http://martinfowler.com/articles/continuousIntegration.html .
◦ Último acesso em 12 de outubro de 2008.


Duvall, Paul. Continuous Integration – Improving
Software Quality and Reducing Risk. Addison-Wesley,
2007.
XP Practice: Continuous Integration
◦ Disponível em http://agilesoftwaredevelopment.com/xp/practices/continuousintegration.
◦ Último acesso em 12 de outubro de 2008.

Cruise Control Home
◦ Disponível em http://cruisecontrol.sourceforge.net/.
◦ Último acesso em 12 de outubro de 2008.
Universidade Federal
de Pernambuco
38
Programa de Mestrado em Ciência da Computação
IN1149 – Qualidade, Processos e Gestão
Integração Contínua
Obrigado!
Rafael Vanderlei de Souza
[email protected]
Universidade Federal
de Pernambuco