Simtecce 2011 Integracao Continua

Aplicação de Integração Contínua na
melhoria da qualidade do
desenvolvimento de software

Prof. Msc Rogério Augusto Rondini
rarondini.paradygma@gmail.com

1

Qualidade

● Visão simplista
– Para o cliente → o sistema funciona ?
– Para o fornecedor → deu lucro ?
– Para o programador → o código
compila ??
● Uma definição de qualidade
– Convergência entre requisitos
completos, código correto e mínimo
de defeitos

2

Qualidade
É preciso mudar a forma de se
trabalhar
● Programar, apesar de divertido, não é
brincadeira
● Se as falhas são inevitáveis, melhor
antecipá-las
● Quanto maior o retrabalho, maior o stress
(e seu final de semana já era...)
● Fatores críticos: Automação, Testes,
Monitoração Constante
3

Qualidade

Nosso Foco
Nosso Foco

Convergência – requisitos completos, código correto e mínimo de defeitos.

4

Agenda

● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson

5

Distribuição de
Software
● Parte do processo de desenvolvimento que
engloba
– Empacotamento
– Testes
– Validações
– Entrega ou Implantação (deployment)

Em desenvolvimento profissional, não
basta o desenvolvedor exportar o .WAR
pelo eclipse.
6

Distribuição de
Software
● Tarefa algumas vezes “esquecida“ ou de
pouca importância no processo de
desenvolvimento
● Quando mal organizada, pode causar
inúmeros problemas
– Falhas na execução
– Atrasos e Retrabalho...

Utilizando um procedimento
automatizado, a tendência é minizar os
problemas
7

Distribuição de
Software
● Antes, é preciso entender...
– Build
● Versão empacotada do sistema
● Pode ser incompleta, mas deve

ser estável (e.g Build
Snapshot )
– Release
● Associadas a marcos do projeto
● Internas ou Externas

8

Agenda


9

Automação
de Build
● Build manual é um processo demorado e
propenso a erros
– Dificuldade em saber a versão correta
de um artefato
– Dificuldade para gerenciamento de
dependências
● Necessidade de uso de ferramentas
apropriadas para automação
– Ex: Maven

10

Maven

● Acumulador de conhecimento
● Objetivos
– Distribuição de Software
– Automação de atividades repetivtivas
– Gerenciamento de Dependência
● Aplicações JavaEE são formadas
por diversos componentes
(.jar)

11

Maven
● Exemplo de dependência – Spring 3.0.5
– spring-core-3.0.5.jar depende de
commons-login-1.1.1.jar
●

● spring-asm.jar

● Algum desses componentes podem depender
de outros
● Adicionalmente, tem o controle da versão do
componente

Árvore de dependências aumenta com a
complexidade do projeto
12

Maven

● Repositórios
– Remoto http://repo2.maven.org/maven2/

http://mirrors.ibiblio.org/pub/mirrors/maven2/

http://repository.jboss.com/maven2/

pom.xml

13

Maven

● Repositórios
– Local
Diretório padrão
Uma pasta de componente
(groupId = aspectjrt)

Versão do componente
(version = 1.5.3)

componente
(artifactId)

14

Maven

● POM – Project Object Model
<project xmlns="....">
  <groupId>usjt.scm</groupId>
  <artifactId>exemplo01</artifactId>
  <packaging>war</packaging>
  <version>1.0.1SNAPSHOT</version>
  <name>Exemplo Maven Webapp</name>
  <dependencies>
    <dependency>
      <groupId>aspectjrt</groupId>
      <artifactId>aspectjrt</artifactId>
      <version>1.5.3</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
  <build>
    <finalName>exemplo01</finalName>
  </build>
</project>

15

Maven
● Plugin Eclipse

16

Maven
● Permite integração com servidores de
aplicação através de plugins específicos
– Jboss → jboss-maven-plugin
http://mojo.codehaus.org/jboss-maven-
– Tomcat → tomcat-maven-plugin
http://mojo.codehaus.org/tomcat-maven
– Websphere → was6-maven-plugin
http://mojo.codehaus.org/was6-maven-
– Weblogic → weblogic-maven-plugin
http://mojo.codehaus.org/weblogic-mav
17

Agenda


18

Controle de Versão
● Cenários típicos de ambiente sem controle
– Sim, fui eu que alterei o código, mas já
faz tanto tempo que nem me lembro o
motivo.
– Eu alterei este programa, mas esta já
era a vigésima alteração no mesmo
programa, e este erro que apareceu
não é meu.
– Eu alterei ontem, mas não sabia que
você também estava alterando. Qual a
última versão ?

19

Controle de Versão
● Sistema para armazenar artefatos de
projeto, tipicamente documentação e
código fonte
● Armazenamento centralizado
● Responsabilidade de manter histórico de
todas as alterações realizadas
● Responsabilidade de controlar alterações

20

Controle de Versão

● Subversion
– Integração com Eclipse
– Histórico de alterações
– Operações
● Checkin e Checkout
● Merge
● Branching e Tagging

21

Controle de Versão

● Branch/Merge principal

Cliente A

Cliente B

merge merge

22

Controle de Versão
● Visão plugin eclipse

23

Agenda


24

Análise de Código

● Atividade que visa garantir
– Aderência aos padrões definidos pela
empresa
– Boas práticas de desenvolvimento
● Ferramentas
– PMD → procura por potenciais
defeitos
– Checkstyle → ajuda a manter padrões
estabelecidos
25

Análise de Código

● Tanto PMD quanto Checkstyle podem ser
– configuradas no Eclipse (ou
Netbeans)
– incorporadas ao processo de
automação de build (e.g Maven)

26

Agenda


27

Teste Unitário
● Implementado com base no menor
elemento testável do software
● Testa estrutura interna (abordagem caixa
branca) e comportamentos observáveis
(abordagem caixa preta)
● Deve-se buscar a maior cobertura possível
● Objetivos
– Isolar partes do sistema
– Mostrar que partes isoladas
funcionam
28

Teste Unitário

● Benefícios
– Facilita manutenção
● Validação das mudanças
● Garantia de funcionamenot pós

alteração
– Simplifica integração entre
componentes
● Uso de ferramentas para execução de
testes, e.g Junit e Cobertura

29

Teste Unitário
● Exemplo
public class TestCadastrarEscala extends TestCase {

public void testValidarHorarioTrabalhoHorarioValido()
throws Exception{
Horario hr = new Horario(1,"08:00","17:00");
boolean resultado = hr.validarHorarioTrabalho();

assertTrue("Resultado esperado deveria ser TRUE, pois
os dados informados correspondem a 9 horas de
trabalho",resultado);
}
}
Maven irá executar os testes
automaticamente, basta identificar as classes
de teste em uma pasta “test“, e seguir o
padrão JUnit
30

Teste Unitário
● É possível utilizar ferramenta para medir a
cobertura dos testes
– Quanto do código realmente está
sendo coberto pelos testes
unitários
● Em termos de métodos
● Linhas de código

● Branchs (if/else, switch/case...)

– Abordagem caixa branca
– Complexidade ciclomática

31

Teste Unitário
● Demonstração
– Classe Escala com um método
inserirHorario
● Regra: total horas mês <= 160
– Classe Horario com um método
validarHorario
● Regra: total horas dia <= 12

Os testes unitários devem prever todas as
situações, válidas e inválidas

32

Teste Unitário
● Plugin Eclipse

33

Agenda


34

Integração
Contínua

“Prática de desenvolvimento de software
onde os membros integram seu trabalho
frequentemente. Cada integração é
verificada por um processo automatizado
para detectar erros o mais rápido
possível.”

Martin Fowler

35

Integração
Contínua
● Estratégia aplicada ao controle de
qualidade de software
– Mudança de paradiga onde o controle
de qualidade passa a ser aplicado
durante o desenvolvimento, e não
apenas após a conclusão do
desenvolvimento

36

Integração
Contínua
● Desenvolvimento Iterativo e Incremental
– Alterações frequentes

37

Integração
Contínua
● Tarefas distribuídas
entre a equipe CR-0002 – Compra
(erro ao calcular valor total itens)
– Código
compartilhado
entre os
desenvolvedores Efetuar pgto boteto

– Maior
probabilidade de Efetuar pgto cartão

falhas
CR-0001
Cadastro de produto

38

Integração
Contínua
● Teve início com o desenvolvimento ágil de
software
– Uma das práticas do XP (eXtreme
Programming)

Execução da Integração Contínua

39

Integração
Contínua
● Automação
– Compilação
– Análise de Código
– Geração de build (empacotamento)
– Execução de testes
● Unitários
● Cobertura
● …
● Relatórios
40

Integração
Contínua
Repositório Máquina de
Central Integração

Download da
última versão Tarefas agendadas
do código-fonte

Feedback
Commit diário - métricas de cobertura de teste
- relatórios de falhas
- relatórios de compilação
...
...

Equipe do projeto

Efetuar pgto Efetuar pgto CR - 0001 CR - 0002
cartão boleto

41

Integração
Contínua
● Algumas práticas recomendadas
– Cultura de testes deve fazer parte da
equipe de desenvolvimento
– Repositório central de código
– Manter uma build auto-testável
– Checkin frequente (diário)

42

Integração
Contínua
● Apesar de ter sido criada para
atender a uma necessidade das
metodologias ágeis de
desenvolvimento (principalmente
XP), vem sendo adotada também em
empresas que não utilizam
metodologias ágeis.

43

Integração
Contínua
● Pontos-Chave
– Automação no processo de geração de
build
– Garantia de qualidade de código
desenvolvido
– Atendimento aos padrões de
desenvolvimento
– Cobertura de testes

44

Integração
Contínua
● Algumas vantagens
– Problemas são encontrados e corrigidos
frequentemente, evitando “last-minute
chaos“ ao se aproximar da data de
entrega
– Constante disponibilidade de um pacote
de software para teste, demonstração
ou entrega
– Medição constante da qualidade do
desenvolvimento

45

Não se limite a fazer apenas o
que lhe pedem: estude,
pense, proponha mudanças.

Sugestão de Leitura:
Fearless Change: Patterns for introduce new ideas
Linda Rising

Prof. Msc Rogério Augusto Rondini
rarondini.paradygma@gmail.com

46

Referências
● Ferramentas
– CruiseControl (http://cruisecontrol.sourceforge.net/)
– Hudson (http://hudson-ci.org/)
– Continuum (http://continuum.apache.org)
– Microsoft TeamFoudationBuild / Visual
Studio Team System
– Maven (http://maven.apache.org/)
– Junit (http://www.junit.org/)
– PMD (http://pmd.sourceforge.net/)
– Checkstyle (http://checkstyle.sourceforge.net/)
47

Simtecce 2011 Integracao Continua

Mais conteúdo relacionado

Mais procurados

Semelhante a Simtecce 2011 Integracao Continua

Simtecce 2011 Integracao Continua