Upload
jeffmor
View
639
Download
6
Embed Size (px)
DESCRIPTION
Qual software não é "doente"? Todos são ou serão! Não é incrível como todos são sujeitos a alguns "vírus" e remédios errados? Essa palestra irá mostrar evolução nas técnicas e a evolução para diagnosticar problemas e verificar a qualidade em softwares, do conceito a prática com a utilização de ferramentas para automatização;Tópicos:Histórico e MitosControle de VersãoProcesso de Integração ContínuaTestesInspeção e PráticasServidoresFeedback
Citation preview
Integração ContínuaCuidando de Sistemas Doentes
Quem sou eu• Jefferson Moreira - www.jeffmor.com• Ciência da Computação / Engenharia de
Software OO• Desenvolvedor e Coordenador Qualidade de
Software da Agence Consultoria. • Desenvolvedor desde 2002 (PHP, Delphi, C++)• Com Java desde 2003• Instrutor do SENAC• Coordenador do JUG-MS
Objetivo• Gerar Software funcionando :D• Confiança no produto• Diagnosticar problemas• Verificar a qualidade do Software.• Redução de Riscos• Automatização de processos repetitivos• Prática dos conceitos.
Agenda
• Histórico • Mitos• Testes• Controle de Versão• Processo de Integração Contínua• Servidores• Inspeção e Práticas• Feedback
Histórico – 80
Histórico – 80
• Anos 80 - década da “caverna”• Ausência de metodologias de
desenvolvimento[9]
• Programação procedural e estruturada. [9]
• Dificuldade de simular relações entre entidades em processos de negócios. [9]
Histórico – 90
Histórico – 90[9]
• Linguagem UML.• Processos Unificados (UP).• Metodologias Orientadas a Objetos.• Fases bem definidas e controladas.• “Igual” a Engenharia Civil.• Concepção, Elaboração, Construção e
Transição.
Processo Unificado[9]
• Código complexo.• Manutenção difícil.• Baixa produtividade.• Cronograma sempre atrasado.• Insatisfação de todos.• Documentação defasada, excessiva e
ilegível.• Fracasso no projeto.
Metodologia Ágil [1]
• Satisfação do Cliente como prioridade máxima, através da entrega contínua de valor agregado
• A principal medida de progresso é software funcionando
• Equipes auto-gerenciáveis, indivíduos motivados, comunicação e simplicidade são valores importantes
• Melhoria Contínua para maximizar a produtividade e excelência da equipe
Agenda• Histórico
• Mitos• Testes• Controle de Versão• Integração Contínua• Servidores• Inspeção e Práticas• Feedback
Bombeiros?
Bombeiros?
• Será que desenvolvedores tem que ficar sempre apagando incêndios?
• Será que não estamos desrespeitando os nossos sistemas com essa atitute?
Sistemas Doentes
• Já viu algum sistema “doente”?• Alguns sistemas são muito dodóis• Já viu algum sistema ser infectado por
algum vírus (Desenvolvedor)?
Sistemas como PACIENTES!
Vacina ajuda!
Mas o negócio é T-E-S-T-AR
Escrevendo testes!
Depois eu escrevo o teste
O prazo está apertado. Vamosdeixar os testes para a próxima fase!
Na minha máquina funcionou!
Sendo médico
A verdade!• Repleto de Best Practices• Muito se fala• Raramente se faz• Casos de teste sempre são deixados para
depois• Quanto mais pressão você sofre, menos
testes você escreve.
Agenda• Histórico• Mitos
• Testes• Controle de Versão• Integração Contínua• Servidores• Inspeção e Práticas• Feedback
Testes
• Essencial para análise de desempenho• Aumento de produtividade dos
desenvolvedores• Essencial para refactoring
Ferramentas de teste
• JUnit• Selenium, httpUnit, WebDriver (aplicações
web)• Cactus (aplicações EJB)• jemmy e Abbot (aplicações Desktop)
Agenda• Histórico• Mitos• Testes
• Controle de Versão• Integração Contínua• Servidores• Inspeção e Práticas• Feedback
Controle de Versão
• CVS• Subversion• ClearCase• Perforce• StarTeam• Git• PVCS, VSS e MKS e etc...
Agenda• Histórico• Mitos• Testes• Controle de Versão
• Integração Contínua• Servidores• Inspeção e Práticas• Feedback
Integração Contínua
• Integração contínua consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de código permaneça consistente ao final de cada integração.
Demonstração do processo
Agenda• Histórico• Mitos• Testes• Controle de Versão• Integração Contínua
• Servidores• Inspeção e Prática• Feedback
Impraticável rodar todos os testes a cada alteração
Servidores• Hudson• Cruise Control• Continuum• Luntbuild• Anthill• Pulse• Build Forge• Damage Control• Team City• Gump
• Disponibilizado como Open Source pela ThoughtWorks
• Implementado em Java• Administração Desktop• Interface um pouco confusa.• Suporte a Java apenas, mas com uma
versão dedicada a .NET
[5 ]
• Open Source desenvolvido pela Apache Fundation
• Desenvolvido em Java• Administração via WEB• Suporte nativo a ANT, Maven 1 e 2 e Shell Script
para outras linguagens
[5 ]
• Disponibilizado como Open Source pela Sun.
• Facilidade de instalação e utilização.• Muitos plugins.• Suporte 8 idiomas inclusive o Português.
Agenda• Histórico• Mitos• Testes• Controle de Versão• Integração Contínua• Servidores
• Inspeção e Prática• Feedback
Go Go Go
Agenda• Histórico• Mitos• Testes• Controle de Versão• Integração Contínua• Servidores• Inspeção e Prática
• Feedback
Paciente tratado
Feedback• Difícil enxergar se você é o único
desenvolvedor da equipe.• Fundamental para testar.• A grande maioria dos bugs se manifestam
já no mesmo dia em que são comitados.• Aumento de produtividade.• Métricas de qualidade aferidas.• Paciente tratado!
Referências[1]http://w w w .martinfow ler.c om/artic les /c ontinuous Integ ratio
n.htm l[2]http://w w w .improveit.c om.br/xp/pratic as /integ rac ao[3]http://w w w .james s hore.c om/B log /C ontinuous -Integ ration-
on-a -Dolla r-a -Day.html[4]http://jayflow ers .c om/joomla /index.php? option=c om_c onten
t& tas k=view & id=26[5]http://blog .urubatan.c om.br[6]http://rfiume.blog s pot.c om/2007/03/tes tes -de-ac eitao-em-
aplic aes -s w ing .html[7] Java M ag azine – C ons truç ão e Tes tes Automatizados . Ano
4 E diç ão 62[8]http://w w w -
128.ibm.c om/developerw orks /ra tiona l/library/s ep05/lee/[9]http://w w w .milfont.org[10]http://ma lditac omedia .blog s pot.c om
Dúvidas?
Licença• Este material está licenciado sob a Licença Creative-Commons
Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 2.5 Brasil
• Você pode:– Copiar, distribuir, exibir e executar a obra– Criar obras derivadas
• Sob as seguintes condições:– Atribuição. Você deve dar crédito ao autor original, da forma especificada
pelo autor ou licenciante. – Uso Não-Comercial. Você não pode utilizar esta obra com finalidades
comerciais.– Compartilhamento pela mesma Licença. Se você alterar, transformar,
ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta.