Universidade Federal de Pernambuco Integração Contínua Rafael Vanderlei de Souza 13/10/2008 Programa de Mestrado em Ciência da Computação IN1149 – Qualidade, Processos e Gestão

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

Universidade Federal de Pernambuco Introdução 3

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

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

Universidade Federal de Pernambuco Motivação Solução: ◦ Não podemos demorar para integrar o código ◦ Precisamos automatizar muitas das etapas do processo ◦ Não podemos correr tantos riscos ◦ Precisamos de Integração Contínua 6

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

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

Universidade Federal de Pernambuco Objetivos Se integrar fosse tão simples assim... 9

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

Universidade Federal de Pernambuco Visão Geral 11 Processo típico de CI...

Universidade Federal de Pernambuco Visão Geral 12 A mágica por trás do botão Integrate...

Universidade Federal de Pernambuco Princípios 13

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

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

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

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

Universidade Federal de Pernambuco Testes Automatizados O processo de build precisa ser totalmente 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. 18

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

Universidade Federal de Pernambuco 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 que quebrou o código deposita uma quantia de dinheiro a cada fração de tempo que o código permanece quebrado. 20

Universidade Federal de Pernambuco Reduzindo Riscos 21

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

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

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

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

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

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

Universidade Federal de Pernambuco 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 , ou até mesmo por SMS. 28

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

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

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

Universidade Federal de Pernambuco Ferramentas 32

Universidade Federal de Pernambuco Ferramentas Servidores de CI: ◦ Cruise Control, Apache Continuum, LuntBuild, Hudson, Bamboo, Pulse, Gauntlet Build: ◦ Maven, Ant, NAnt, Rake Controle de Versão ◦ Subversion, CVS, ClearCase, VSS, StarTeam Banco de dados ◦ Oracle, SQL Server, PostgreSQL, MySQL, HSQLDB Teste ◦ JUnit, NUnit, DbUnit, HtmlUnit, Selenium, TestNG Inspeção ◦ Checkstyle, FindBugs, Cobertura, EMMA, FxCop Feedback ◦ Ambient Device, Jabber, Gtalk 33

Universidade Federal de Pernambuco Conclusões 34

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

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

Universidade Federal de Pernambuco Referências 37

Universidade Federal de Pernambuco Referências Fowler, Martin. Continuous Integration. ◦ Disponível em ◦ Último acesso em 12 de outubro de Duvall, Paul. Continuous Integration – Improving Software Quality and Reducing Risk. Addison-Wesley, XP Practice: Continuous Integration ◦ Disponível em integration. integration ◦ Último acesso em 12 de outubro de Cruise Control Home ◦ Disponível em ◦ Último acesso em 12 de outubro de

Universidade Federal de Pernambuco Integração Contínua Obrigado! Rafael Vanderlei de Souza Programa de Mestrado em Ciência da Computação IN1149 – Qualidade, Processos e Gestão