Programa de Mestrado em Cincia da Computao IN

  • Slides: 39
Download presentation
Programa de Mestrado em Ciência da Computação IN 1149 – Qualidade, Processos e Gestão

Programa de Mestrado em Ciência da Computação IN 1149 – Qualidade, Processos e Gestão Integração Contínua Rafael Vanderlei de Souza [email protected] ufpe. br 13/10/2008 Universidade Federal de Pernambuco

Agenda �Introdução �Princípios �Reduzindo Riscos �Ferramentas �Conclusões �Referências Universidade Federal de Pernambuco 2

Agenda �Introdução �Princípios �Reduzindo Riscos �Ferramentas �Conclusões �Referências Universidade Federal de Pernambuco 2

Introdução Universidade Federal de Pernambuco 3

Introdução Universidade Federal de Pernambuco 3

Motivação � Consideremos o seguinte processo típico de desenvolvimento: ◦ ◦ ◦ ◦ ◦

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

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

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

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 �

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

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

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

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 Universidade Federal de Pernambuco 13

Princípios Integração Contínua possui um conjunto de princípios que nos permitem fazer mudanças no

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

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

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

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. � Para tanto, é possível utilizar ferramentas

Testes Automatizados � O processo de automatizado. � 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 build 18 precisa ser totalmente

Todos os Testes e Inspeções Devem Passar � É muito fácil aceitar o fato

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

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 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 Universidade Federal de Pernambuco 21

Reduzindo Riscos � Algo sempre vai dar errado em um projeto. � Praticando CI,

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

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

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,

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

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

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

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

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

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

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 Universidade Federal de Pernambuco 32

Ferramentas � Servidores de CI: ◦ Cruise Control, Apache Continuum, Lunt. Build, Hudson, Bamboo,

Ferramentas � Servidores de CI: ◦ Cruise Control, Apache Continuum, Lunt. Build, Hudson, Bamboo, Pulse, Gauntlet � Build: ◦ Maven, Ant, NAnt, Rake � Controle de Versão ◦ Subversion, CVS, Clear. Case, VSS, Star. Team � Banco de dados ◦ Oracle, SQL Server, Postgre. SQL, My. SQL, HSQLDB � Teste ◦ JUnit, NUnit, Db. Unit, Html. Unit, Selenium, Test. NG � Inspeção ◦ Checkstyle, Find. Bugs, Cobertura, EMMA, Fx. Cop � Feedback ◦ Ambient Device, Jabber, Gtalk Universidade Federal de Pernambuco 33

Conclusões Universidade Federal de Pernambuco 34

Conclusões Universidade Federal de Pernambuco 34

Conclusões � Integração Contínua nos permite reduzir trabalho repetitivo e sujeito a erros, automatizando

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 grande quantidade de ferramentas que auxiliam na implementação da Integração Contínua. Universidade Federal de Pernambuco 35

Conclusões E você? Já está fazendo integração contínua? Está usando um repositório de controle

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 Universidade Federal de Pernambuco 37

Referências � Fowler, Martin. Continuous Integration. ◦ Disponível em http: //martinfowler. com/articles/continuous. Integration. html.

Referências � Fowler, Martin. Continuous Integration. ◦ Disponível em http: //martinfowler. com/articles/continuous. Integration. 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/continuous-integration. ◦ Ú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 IN 1149 – Qualidade, Processos e Gestão

Programa de Mestrado em Ciência da Computação IN 1149 – Qualidade, Processos e Gestão Integração Contínua Obrigado! Rafael Vanderlei de Souza [email protected] ufpe. br Universidade Federal de Pernambuco