Simtecce 2011 Integracao Continua

935 visualizações

Publicada em

Apresentação realizada no Simtecce (Simpósio de Tecnologia e Ciências Exatas) 2011, na Universidade São Judas Tadeu.

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
935
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Simtecce 2011 Integracao Continua

  1. 1. Aplicação de Integração Contínua na melhoria da qualidade do desenvolvimento de software Prof. Msc Rogério Augusto Rondini rarondini.paradygma@gmail.com 1
  2. 2. Qualidade● Visão simplista – Para o cliente → o sistema funciona ? – Para o fornecedor → deu lucro ? – Para o programador → o código compila ??● Uma definição de qualidade – Convergência entre requisitos completos, código correto e mínimo de defeitos 2
  3. 3. Qualidade É preciso mudar a forma de se trabalhar ● Programar, apesar de divertido, não é brincadeira ● Se as falhas são inevitáveis, melhor antecipá-las● Quanto maior o retrabalho, maior o stress (e seu final de semana já era...) ● Fatores críticos: Automação, Testes, Monitoração Constante 3
  4. 4. Qualidade Nosso Foco Nosso FocoConvergência – requisitos completos, código correto e mínimo de defeitos. 4
  5. 5. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 5
  6. 6. Distribuição de Software● Parte do processo de desenvolvimento que engloba – Empacotamento – Testes – Validações – Entrega ou Implantação (deployment)Em desenvolvimento profissional, nãobasta o desenvolvedor exportar o .WAR pelo eclipse. 6
  7. 7. Distribuição de Software● Tarefa algumas vezes “esquecida“ ou de pouca importância no processo de desenvolvimento● Quando mal organizada, pode causar inúmeros problemas – Falhas na execução – Atrasos e Retrabalho... Utilizando um procedimentoautomatizado, a tendência é minizar os problemas 7
  8. 8. Distribuição de Software● Antes, é preciso entender... – Build ● Versão empacotada do sistema ● Pode ser incompleta, mas deve ser estável (e.g Build Snapshot ) – Release ● Associadas a marcos do projeto ● Internas ou Externas 8
  9. 9. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 9
  10. 10. Automação de Build● Build manual é um processo demorado e propenso a erros – Dificuldade em saber a versão correta de um artefato – Dificuldade para gerenciamento de dependências● Necessidade de uso de ferramentas apropriadas para automação – Ex: Maven 10
  11. 11. Maven● Acumulador de conhecimento● Objetivos – Distribuição de Software – Automação de atividades repetivtivas – Gerenciamento de Dependência ● Aplicações JavaEE são formadas por diversos componentes (.jar) 11
  12. 12. Maven● Exemplo de dependência – Spring 3.0.5 – spring-core-3.0.5.jar depende de commons-login-1.1.1.jar ● ● spring-asm.jar● Algum desses componentes podem depender de outros● Adicionalmente, tem o controle da versão do componente Árvore de dependências aumenta com a complexidade do projeto 12
  13. 13. Maven● Repositórios – Remoto http://repo2.maven.org/maven2/ http://mirrors.ibiblio.org/pub/mirrors/maven2/ http://repository.jboss.com/maven2/ pom.xml 13
  14. 14. Maven● Repositórios – Local Diretório padrão Uma pasta de componente (groupId = aspectjrt) Versão do componente (version = 1.5.3) componente (artifactId) 14
  15. 15. Maven● POM – Project Object Model <project xmlns="....">   <groupId>usjt.scm</groupId>   <artifactId>exemplo01</artifactId>   <packaging>war</packaging>   <version>1.0.1­SNAPSHOT</version>   <name>Exemplo Maven Webapp</name>   <dependencies>     <dependency>       <groupId>aspectjrt</groupId>       <artifactId>aspectjrt</artifactId>       <version>1.5.3</version>       <scope>compile</scope>     </dependency>   </dependencies>   <build>     <finalName>exemplo01</finalName>   </build> </project> 15
  16. 16. Maven● Plugin Eclipse 16
  17. 17. Maven● Permite integração com servidores de aplicação através de plugins específicos – Jboss → jboss-maven-plugin http://mojo.codehaus.org/jboss-maven- – Tomcat → tomcat-maven-plugin http://mojo.codehaus.org/tomcat-maven – Websphere → was6-maven-plugin http://mojo.codehaus.org/was6-maven- – Weblogic → weblogic-maven-plugin http://mojo.codehaus.org/weblogic-mav 17
  18. 18. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 18
  19. 19. Controle de Versão● Cenários típicos de ambiente sem controle – Sim, fui eu que alterei o código, mas já faz tanto tempo que nem me lembro o motivo. – Eu alterei este programa, mas esta já era a vigésima alteração no mesmo programa, e este erro que apareceu não é meu. – Eu alterei ontem, mas não sabia que você também estava alterando. Qual a última versão ? 19
  20. 20. Controle de Versão● Sistema para armazenar artefatos de projeto, tipicamente documentação e código fonte● Armazenamento centralizado● Responsabilidade de manter histórico de todas as alterações realizadas● Responsabilidade de controlar alterações 20
  21. 21. Controle de Versão● Subversion – Integração com Eclipse – Histórico de alterações – Operações ● Checkin e Checkout ● Merge ● Branching e Tagging 21
  22. 22. Controle de Versão● Branch/Merge principal Cliente A Cliente B merge merge 22
  23. 23. Controle de Versão● Visão plugin eclipse 23
  24. 24. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 24
  25. 25. Análise de Código● Atividade que visa garantir – Aderência aos padrões definidos pela empresa – Boas práticas de desenvolvimento● Ferramentas – PMD → procura por potenciais defeitos – Checkstyle → ajuda a manter padrões estabelecidos 25
  26. 26. Análise de Código● Tanto PMD quanto Checkstyle podem ser – configuradas no Eclipse (ou Netbeans) – incorporadas ao processo de automação de build (e.g Maven) 26
  27. 27. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 27
  28. 28. Teste Unitário● Implementado com base no menor elemento testável do software● Testa estrutura interna (abordagem caixa branca) e comportamentos observáveis (abordagem caixa preta)● Deve-se buscar a maior cobertura possível● Objetivos – Isolar partes do sistema – Mostrar que partes isoladas funcionam 28
  29. 29. Teste Unitário● Benefícios – Facilita manutenção ● Validação das mudanças ● Garantia de funcionamenot pós alteração – Simplifica integração entre componentes● Uso de ferramentas para execução de testes, e.g Junit e Cobertura 29
  30. 30. Teste Unitário ● Exemplo public class TestCadastrarEscala extends TestCase { public void testValidarHorarioTrabalhoHorarioValido() throws Exception{ Horario hr = new Horario(1,"08:00","17:00"); boolean resultado = hr.validarHorarioTrabalho(); assertTrue("Resultado esperado deveria ser TRUE, pois os dados informados correspondem a 9 horas de trabalho",resultado); } } Maven irá executar os testesautomaticamente, basta identificar as classes de teste em uma pasta “test“, e seguir o padrão JUnit 30
  31. 31. Teste Unitário● É possível utilizar ferramenta para medir a cobertura dos testes – Quanto do código realmente está sendo coberto pelos testes unitários ● Em termos de métodos ● Linhas de código ● Branchs (if/else, switch/case...) – Abordagem caixa branca – Complexidade ciclomática 31
  32. 32. Teste Unitário ● Demonstração – Classe Escala com um método inserirHorario ● Regra: total horas mês <= 160 – Classe Horario com um método validarHorario ● Regra: total horas dia <= 12Os testes unitários devem prever todas as situações, válidas e inválidas 32
  33. 33. Teste Unitário● Plugin Eclipse 33
  34. 34. Agenda● Distribuição de Software● Automação de Build → Maven● Controle de Versão → SVN● Análise de código → PMD e Checkstyle● Testes Unitários → Junit e Cobertura● Integração Contínua → Hudson 34
  35. 35. Integração Contínua“Prática de desenvolvimento de softwareonde os membros integram seu trabalho frequentemente. Cada integração éverificada por um processo automatizado para detectar erros o mais rápido possível.” Martin Fowler 35
  36. 36. Integração Contínua● Estratégia aplicada ao controle de qualidade de software – Mudança de paradiga onde o controle de qualidade passa a ser aplicado durante o desenvolvimento, e não apenas após a conclusão do desenvolvimento 36
  37. 37. Integração Contínua● Desenvolvimento Iterativo e Incremental – Alterações frequentes 37
  38. 38. Integração Contínua● Tarefas distribuídas entre a equipe CR-0002 – Compra (erro ao calcular valor total itens) – Código compartilhado entre os desenvolvedores Efetuar pgto boteto – Maior probabilidade de Efetuar pgto cartão falhas CR-0001 Cadastro de produto 38
  39. 39. Integração Contínua● Teve início com o desenvolvimento ágil de software – Uma das práticas do XP (eXtreme Programming) Execução da Integração Contínua 39
  40. 40. Integração Contínua● Automação – Compilação – Análise de Código – Geração de build (empacotamento) – Execução de testes ● Unitários ● Cobertura ● …● Relatórios 40
  41. 41. Integração Contínua Repositório Máquina de Central Integração Download da última versão Tarefas agendadas do código-fonte Feedback Commit diário - métricas de cobertura de teste - relatórios de falhas - relatórios de compilação ... ... Equipe do projetoEfetuar pgto Efetuar pgto CR - 0001 CR - 0002 cartão boleto 41
  42. 42. Integração Contínua● Algumas práticas recomendadas – Cultura de testes deve fazer parte da equipe de desenvolvimento – Repositório central de código – Manter uma build auto-testável – Checkin frequente (diário) 42
  43. 43. Integração Contínua● Apesar de ter sido criada para atender a uma necessidade das metodologias ágeis de desenvolvimento (principalmente XP), vem sendo adotada também em empresas que não utilizam metodologias ágeis. 43
  44. 44. Integração Contínua● Pontos-Chave – Automação no processo de geração de build – Garantia de qualidade de código desenvolvido – Atendimento aos padrões de desenvolvimento – Cobertura de testes 44
  45. 45. Integração Contínua● Algumas vantagens – Problemas são encontrados e corrigidos frequentemente, evitando “last-minute chaos“ ao se aproximar da data de entrega – Constante disponibilidade de um pacote de software para teste, demonstração ou entrega – Medição constante da qualidade do desenvolvimento 45
  46. 46. Não se limite a fazer apenas o que lhe pedem: estude, pense, proponha mudanças. Sugestão de Leitura:Fearless Change: Patterns for introduce new ideas Linda Rising Prof. Msc Rogério Augusto Rondini rarondini.paradygma@gmail.com 46
  47. 47. Referências● Ferramentas – CruiseControl (http://cruisecontrol.sourceforge.net/) – Hudson (http://hudson-ci.org/) – Continuum (http://continuum.apache.org) – Microsoft TeamFoudationBuild / Visual Studio Team System – Maven (http://maven.apache.org/) – Junit (http://www.junit.org/) – PMD (http://pmd.sourceforge.net/) – Checkstyle (http://checkstyle.sourceforge.net/) 47

×