integração contínua

Integração ContínuaEster Lima de Campos

Projeto Capacitar – GPESetembro 2011

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.

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.

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.

Origem

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

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0201616416

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.

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.

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.


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.


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.

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.

http://hudson-ci.org/

http://cruisecontrol.sourceforge.net/

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.

Processo IC4. 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.

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.


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.


• 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.


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


• 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.


• 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.


• 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.


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.


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.

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…

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.

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.

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.

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

Tipos de Testes

Brian Marick

Functional acceptance test

ShowcasesUsability testing

Exploratory testing

Nonfunctional acceptance tests

(capacity, security,…)

Unit testsIntegration tests

System tests

Manual/Automated

Manual

Automated

Automated

Supp

ort P

rogr

amm

ing

Critique Project

Technology Facing

Business facing

Suporte a Tecnologia e Desenvolvimento

• Responsabilidade exclusiva dos desenvolvedores– Unitários– Integração / Componente– Deployment / Sistema

Unit testsIntegration tests

System tests

Automated

Supp

ort P

rogr

amm

ing

Technology Facing

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

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.

Suporte ao Negócio e Desenvolvimento

• Responde as perguntas:– 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[]


Automated

Supp

ort P

rogr

amm

ing

Business facing

Negócio e Desenvolvimento

• Preparando o teste– 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.


Automated

Supp

ort P

rogr

amm

ing

Business facing

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

http://cukes.info/

http://jbehave.org/introduction/

http://concordion.org/Technique.html

http://www.thoughtworksstudios.com/agile-test-automation/


• 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.


• 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.

Suporte ao Negócio e Projeto

• Não apenas valida se a aplicação atende a especificação, mas se a especificação está correta.

• Desenvolvimento de software é um processo iterativo.


Exploratory testing

Manual

Critique Project

Business facing

Suporte ao Negócio e Projeto

• Showcases– Equipe ágeis com produto após

iteração.• Exploratory

– 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.


Exploratory testing

Manual

Critique Project

Business facing

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, Small, and Testable)

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.

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.

Referência:

• Dave Farley

• Jez Humble

Sobre os autores…

http://continuousdelivery.com/about/






www.myscrumhalf.com

www.gpetec.com.br

Obrigada!Ester Lima de Campos@[email protected]