1. Integração Contínua
Ester Lima de Campos
Projeto Capacitar – GPE
Setembro 2011

2. Realidade
• Estranho, mas comum…
– Que por um longo tempo, durante o processo de
desenvolvimento, a aplicação não está funcional.
• A Razão? É fácil de entender…
– Ninguém tenta usar a aplicação como se esta
estivesse no ambiente de produção.

3. Realidade, ainda…
• A maioria dos projetos agenda fases para
integração ao final do desenvolvimento
– Tempo para Integração pode ser extremamente
longo.
– Não há como prever o tempo.

4. Integração Contínua
• Toda vez que alguém “commita” alguma
mudança, toda a aplicação é construída (build) e
um conjunto expressivo de testes automatizados
são executados a fim de testá-la.
• Se o build ou os testes falham toda a equipe para
o que quer que estejam fazendo e acertam os
problemas imediatamente.
• Software em estado funcional a todo o tempo.

5. Origem
• Primeiramente escrito
sobre, no livro Extreme
Programming Explained
(Kent Beck 1999).

6. Conceitos que justificam
• Se a integração do código está funcionando,
por que não fazê-la a todo instante?
• Mudança de paradigma:
– Sem a integração contínua seu software está
quebrado até que alguém prove o contrário.

7. Vantagens
• Equipes que adotam a IC são capazes de
efetivamente entregar software mais rápido e
com menos bugs.
• Bugs são detectados previamente, quando são
baratos de serem solucionados, provendo
menos gastos de custo e tempo.

8. O que é preciso antes de iniciar?
1. Controle de Versão
– Repositório de tudo do projeto:
código, testes, scripts de BD, build, scripts de
deployments e o que mais for preciso para:
criar, instalar, rodar e testar a aplicação.

9. O que é preciso antes de iniciar?
2. Build Automático
– Deve ser possível iniciar o build pela linha de
comando. Razão?
• Deve ser possível compilar a aplicação de forma
automática do ambiente de IC, para quando algo der
errado que seja possível de ser auditado.
• Seu script de build tem que ser como o código do
projeto. Deve ser testado e constantemente
refatorado, para estar sempre arrumado e
compreensível. Importante à medida que o projeto
vai se tornando mais complexo.

10. O que é preciso antes de iniciar?
3. Combinado entre todos os membros da
equipe
• Integração contínua é uma prática e não uma
ferramenta.
• Requer um grau de comprometimento e disciplina dos
membros da equipe.
• É preciso que todos “comitem” frequentemente
pequenos incrementos/mudanças.
• A tarefa de maior prioridade é consertar qualquer
mudança que tenha quebrado a aplicação.

11. Sistema Básico para IC
• Hudson e CruiseControl (open source)
• Pré-condições para iniciar o uso.
– Informar onde encontrar o código no repositório.
– Que script executar para compilar o projeto.
– Que script executar para rodar os testes.
– Como informar a equipe que a última mudança
quebrou o software.

12. Processo IC
1. Verifique se o build ainda está rodando. Em caso positivo aguarde o término. Se
falhar, trabalhe com a equipe para fazê-lo passar antes de dar o check-in.
2. Quando tiver terminado e os testes tiverem passados, atualize o código no seu
ambiente de trabalho
3. Rode o script de build e testes na sua máquina para ter certeza que tudo está
funcional no seu ambiente de trabalho, ou alterantivamente use sua ferramente de
IC pessoal.

13. Processo IC
4. Se o seu build local passar, check seu código para o controle de versão.
5. Espere a ferramente de IC executar o build com suas mudanças
6. Se falhar, conserte o problema imediatamente no seu ambiente de trabalho e
volte ao passo 3.
7. Se o build passar, alegre-se e mova para a próxima tarefa.

14. Pré-requisitos para IC
• Check-in no trunk regularmente.
– As alterações serão menores, menos provável de
quebrar o build.
– Significa que há uma versão do SW funcional
recente a ser revertida se você fizer algum erro.
– Ajuda a equipe a ser mais disciplinada com seus
refactorings.
– Garantir que mudanças que alteram muitos
arquivos são menos prováveis de dar conflito com
o trabalho de outros da equipe.

15. Pré-requisitos para IC
1. Check-in no trunk regularmente.
– Permite o desenvolvedor explorar mais
alternativas, experimentando ideias e as
descartando, revertendo a versão para a anterior.
– Força a pausas regulares para esticar os músculos
ajudando a evitar a síndrome do carpo.
– E se algo de catastrófico acontecer, ninguém
perde um grande trabalho.

16. Pré-requisitos para IC
• O check-in deve ser feito no trunk, pois não é
aconselhável trabalhar com branches.
• É impossível fazer IC usando branches, porque
por definição, se estiver trabalhando em
branches seu código não está sendo integrado
com o de outros desenvolvedores.

17. Pré-requisitos para IC
2. Criar uma suite de testes automatizados
– É essencial ter um nível de testes automatizados
para fornecer confiança de que seu software está
funcionando.
• Testes unitários
• Testes de componente
• Testes de aceitação

18. Pré-requisitos para IC
• Testes Unitários
– Testa partes pequenas e isoladas da aplicação
(método, função, ou interação entre alguns deles).
– Não se conecta o banco de dados, arquivos de
sistema ou a sua rede.
– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.
– Devem rodar rapidamente, toda a suíte em mais
ou menos 10 minutos.

19. Pré-requisitos para IC
• Testes de Componente
– Testa o comportamento de vários componentes
da aplicação.
– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.
– Conceta-se ao banco de dados, arquivos de
sistema ou a sua rede.
– Tipicamente demoram a ser executado.

20. Pré-requisitos para IC
• Testes de Aceitação
– Testa se a aplicação atende aos critérios definidos
pelo negócio para aceitação, incluindo
funcionalidade e também características como:
capacidade, disponibilidade, segurança, etc.
– Preferencialmente executados num ambiente que
simule o de produção.

21. Pré-requisitos para IC
3. Mantenha o build e o processo de teste
unitário curto. 10 minutos é o tempo limite
– Equipe deixará de fazer esse processo na sua
área de trabalho e teremos mais builds
quebrados.
– IC vai levar também tanto tempo que multiplos
commits irão ocorrer e não será possível detectar
qual check-in quebrou.
– Equipe fará check-in com menos frequência.

22. Pré-requisitos para IC
4. Administre sua área de trabalho
– Cada membro da equipe deve ser capaz de rodar
o build, executar os testes automatizados e fazer o
deploy da aplicação em um ambiente sobre o seu
controle.

23. Usando Software de IC
• Operações Básicas
– Executar um simples worflow em intervalos
regulares
– Prover uma forma visual de analisar os resultados
• Chamando a atenção
– Enviar o status do build mais recente para outro
dispositivo.
• Indicadores com lâmpadas, som, falando nome do
desenvolvedor que quebrou o build…

24. Boas Práticas
1. Não dar check-in em um build quebrado.
2. Sempre executar localmente os testes antes
de commitar.
3. Esperar os testes serem executados antes de
mover adiante.
4. Nunca ir para casa se um build quebrar.

25. Práticas Essenciais
5. Sempre estar preparado para reverter a uma
versão anterior.
6. Estabelecer um timebox antes de reverter.
7. Não “comentem” os testes que falharam.
8. Assuma a responsabilidade de todos os
testes que quebrarem pelo resultado de uma
mudança sua.
9. TDD.

26. Estratégia de Testes
• Testar é uma atividade que deve
– Envolver toda a equipe
– Ser feita continuamente desde o início do projeto.
• Construir qualidade significa escrever testes
automatizados em diversos níveis e executá-
los como parte do pipeline de deployment.
• Testes manuais também são essenciais para
construir a qualidade do software.

27. Estratégia de Testes
• Testers colaboram com desenvolvedores e
usuários para escrever os testes
automatizados.
• Os testes devem ser escritos antes de ser
iniciado o desenvolvimento de uma história

28. Tipos de Testes
Business facing
Automated Manual
Support Programming Showcases
Functional acceptance
Usability testing
Critique Project
test
Exploratory testing
Unit tests Nonfunctional
Integration tests acceptance tests
System tests (capacity, security,…)
Automated Manual/Automated
Technology Facing
Brian Marick

29. Suporte a Tecnologia e
Desenvolvimento
• Responsabilidade exclusiva
dos desenvolvedores
– Unitários
Support Programming
– Integração / Componente
– Deployment / Sistema
Unit tests
Integration tests
System tests
Automated
Technology Facing

30. Teste de Integração
• Se refere a testes que garantem que cada
parte independente da aplicação funciona
corretamente com serviços dos quais
dependam.
• Podem ser escritos como são os testes de
aceitação

31. Teste de Integração
• Devem ser executados em dois contextos:
1. Interfaceando com os sistemas externos dos quais
dependem ou com replicas controladas pelo
provedor
2. Interfaceando com equipamentos de testes
desenvolvidos como parte do código base.

32. Suporte ao Negócio e
Desenvolvimento
Business facing
Automated
• Responde as perguntas:
Support Programming
Functional acceptance
test
– Como eu sei que está done?
(para desenvolvedor)
– O done é o que eu realmente
queria?
(para usuário)
• Preparando o teste
– Dado [] quando[], então[]

33. Negócio e Desenvolvimento
Business facing
Automated
• Preparando o teste
Support Programming
Functional acceptance
test
– Dado [1] quando[2], então[3]
1. Importantes características
do estado do sistema.
2. O usuário executa algumas
ações específicas.
3. Importantes características
do novo estado do sistema.

34. Processo – Teste Aceitação
• No início de cada iteração reunir
cliente, analistas e testers para levantar o
cenário de maior prioridade a ser testado.
• Usar ferramentas para escrever em linguagem
natural os testes e que permitam depois criar
o código para fazer os testes serem
executados. Exemplos:
– Cucumber / Jbehave / Concordion / Twist

35. Processo – Teste Aceitação
• Refatoração no código de teste implica em
atualização da especificação do teste.
• Usar uma linguagem específica do domínio
(DSL) para testar, isso permite que os critérios
de aceitação entrem em DSL também.

36. Processo – Teste Aceitação
• Testers e desenvolvedores se reunem antes do
início do desenvolvimento da história para
discutir os testes de aceitação.
– Isso permite aos desenvolvedores terem uma boa
visão da história e entenderem qual o cenário mais
importante.
– Reduz o ciclo de feedback entre desenvolvedores e
testers que pode acabar acontecendo ao final do
desenvolvimento.
– Ajuda a reduzir tanto funcionalidades não
implementadas, quanto o número de bugs.

37. Suporte ao Negócio e Projeto
Business facing
Manual
• Não apenas valida se a
Showcases
aplicação atende a Usability testing
Critique Project
especificação, mas se a Exploratory testing
especificação está correta.
• Desenvolvimento de software
é um processo iterativo.

38. Suporte ao Negócio e Projeto
Business facing
Manual
• Showcases
– Equipe ágeis com produto após Showcases
iteração. Usability testing
Critique Project
• Exploratory Exploratory testing
– Controla a criação dos testes
enquanto sendo executados e usa os
resultados são usados para criar
novos testes automatizados
• Usability
– Descobre quão fácil é para o usuário
alcançar seus objetivos com o SW.

39. O que testar? Novo Projeto
• Iniciar escrevendo testes de aceitação
automatizados. Para isso:
– Escolher uma plataforma e uma ferramenta de
teste
– Set up o build automático
– Trabalhar em histórias que sigam os princípios
INVEST
(Independent, Negotiable, Valuable, Estimable, Sm
all, and Testable)

40. O que testar? Novo Projeto
• Processo
– Cliente, analistas e testers definem os critérios de
aceitação
– Testers trabalham com os desenvolvedores para
automatizar os testes de aceitação baseado nos
critérios definidos
– Desenvolvedores codificam o comportamento
para atender os critérios de aceitação
– Se os testes falharem, prioridade em acertar o
código.

41. O que testar? Projeto em
Andamento
• Começar pelo caso de uso mais comum,
importante e de maior valor da aplicação.
– Conversa com o cliente para identificar onde o
valor do negócio está centrado.
– Automatizar o fluxo básico que cobre esse cenário
de alto-valor.
– Em adição, maximizar o número de ações que
esses testes cobrem.

42. Referência:
• Dave Farley
• Jez Humble
Sobre os autores…

43. www.gpetec.com.br
Obrigada!
Ester Lima de Campos
@estercasado
esterlima@gpetec.com.br
www.myscrumhalf.com