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
Universidade Federalde Pernambuco
AgendaAgendaIntroduçãoPrincípiosReduzindo RiscosFerramentasConclusõesReferências
2
Universidade Federalde Pernambuco
IntroduçãoIntrodução
3
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
ObjetivosObjetivosSe integrar fosse tão simples assim...
9
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
Visão GeralVisão Geral
11
Processo típico de CI...
Universidade Federalde Pernambuco
Visão GeralVisão Geral
12
A mágica por trás do botão Integrate...
Universidade Federalde Pernambuco
PrincípiosPrincípios
13
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
Reduzindo RiscosReduzindo Riscos
21
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
FerramentasFerramentas
32
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
ConclusõesConclusões
34
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
ReferênciasReferências
37
Universidade Federalde Pernambuco
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
Universidade Federalde Pernambuco
Integração ContínuaIntegração Contínua
Obrigado!Rafael Vanderlei de Souza
Programa de Mestrado em Ciência da ComputaçãoIN1149 – Qualidade, Processos e Gestão
Top Related