Universidade Federal de Pernambuco Integração Contínua Rafael Vanderlei de Souza [email protected] 13/10/2008 Programa de Mestrado em Ciência da Computação

Universidade Federalde Pernambuco

Integração ContínuaIntegração Contínua

Rafael Vanderlei de [email protected]

13/10/2008

Programa de Mestrado em Ciência da ComputaçãoIN1149 – Qualidade, Processos e Gestão

mailto:[email protected]


AgendaAgendaIntroduçãoPrincípiosReduzindo RiscosFerramentasConclusõesReferências

2


IntroduçãoIntrodução

3


MotivaçãoMotivaçãoConsideremos 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


MotivaçãoMotivaçãoAlguns 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


MotivaçãoMotivaçãoSoluçã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


DefiniçãoDefiniçã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


ObjetivosObjetivosAumentar 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


ObjetivosObjetivosSe integrar fosse tão simples assim...

9


Visão GeralVisão GeralCená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


Visão GeralVisão Geral

11

Processo típico de CI...


Visão GeralVisão Geral

12

A mágica por trás do botão Integrate...


PrincípiosPrincípios

13


PrincípiosPrincí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


Commits FreqüentesCommits 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


Não Subir Código QuebradoNã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


Rodar Rodar Private BuildPrivate 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


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


Todos os Testes e Inspeções Todos os Testes e Inspeções Devem PassarDevem 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


Consertar Builds QuebradosConsertar Builds QuebradosImediatamenteImediatamente 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


Reduzindo RiscosReduzindo Riscos

21


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


Falta de ImplantávelFalta 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


Falta de ImplantávelFalta 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


Falta de ImplantávelFalta 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


Descoberta Tardia de DefeitosDescoberta 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


Descoberta Tardia de DefeitosDescoberta 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


Falta de VisibilidadeFalta 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.

28


Falta de VisibilidadeFalta 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


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


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


FerramentasFerramentas

32


FerramentasFerramentas 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


ConclusõesConclusões

34


ConclusõesConclusõ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


ConclusõesConclusõesE 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


ReferênciasReferências

37


ReferênciasReferências Fowler, Martin. Continuous Integration.

◦ Disponível em http://martinfowler.com/articles/continuousIntegration.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.

38

http://martinfowler.com/articles/continuousIntegration.html

http://agilesoftwaredevelopment.com/xp/practices/continuous-integration

http://agilesoftwaredevelopment.com/xp/practices/continuous-integration

http://cruisecontrol.sourceforge.net/


Integração ContínuaIntegração Contínua

Obrigado!Rafael Vanderlei de Souza

[email protected]

Programa de Mestrado em Ciência da ComputaçãoIN1149 – Qualidade, Processos e Gestão

mailto:[email protected]

Documents

Universidade Federal de Pernambuco Integração Contínua Rafael Vanderlei de Souza [email protected] 13/10/2008 Programa de Mestrado em Ciência da Computação