Your SlideShare is downloading. ×
0
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Integração Contínua
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Integração Contínua

342

Published on

Projeto Capacitar de setembro de 2011. …

Projeto Capacitar de setembro de 2011.
Tema: Integração Contínua

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
342
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • - Nãoháinteresseemtentarexecutar a aplicação antes de tudoestar pronto.
  • - Para dar tempo a equipe de fazer merge, integrarostrabalhos e tornar a aplicaçãofuncionalparaos testes de aceitação.
  • - A todoinstante, significa, todavezquealguémcomitarqualquermudança no controlador de versão.- Com a integraçãocontínuaseu software é comprovadoquefunciona a cada nova mudança.
  • Controle de VersãoRepositório de tudo do projeto: código, testes, scripts de BD, build, scripts de deployments e o quemais for precisopara: criar, instalar, rodar e testar a aplicação.Build AutomáticoDeve ser possívelrodar o build de forma automática do ambiente de integraçãocontínua, de forma quepossa ser auditadoquandoalgodererrado.
  • Parececontrovérsia, uma fez quetemos IDEs sofisticadasparafazeresseprocesso, mashárazõespara a IC,quesão:
  • Transcript

    • 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 IC1. 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ças6. 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 IC1. 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 IC2. 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 IC3. 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 IC4. 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áticas1. 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 Essenciais5. 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 ManualSupport 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áriosSupport 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 testeSupport 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.brObrigada!Ester Lima de Campos@estercasadoesterlima@gpetec.com.br www.myscrumhalf.com

    ×