TWiki home XP > XP > ProcessoDeConstrucao (r1.1 vs. r1.5) XP webs:
Main | TWiki | Sandbox | Portugues
XP . { Bugzilla Últimas atualizações Busca Registro Sobre o TWiki }
 <<O>>  Difference Topic ProcessoDeConstrucao (r1.5 - 28 Nov 2004 - GuilhermeMartins)
Line: 1 77 to 1 78
Added:
>
>

META FILEATTACHMENT apresentacao.ppt attr="" comment="" date="1101682386" path="E:\ufsc\xp\apresentacao.ppt" size="76288" user="GuilhermeMartins" version="1.1"

 <<O>>  Difference Topic ProcessoDeConstrucao (r1.4 - 28 Nov 2004 - GuilhermeMartins)
Line: 1 5 to 1 5
Changed:
<
<
Segundo 1 os desenvolvedores devem integrar e liberar código no repositório freqüentemente, em intervalos de poucas horas, sempre que possível. Em nenhum caso, este intervalo deve exceder um dia. A integração contínua garante que o desenvolvimento não resulte em esforços fragmentados ou divergentes. O desenvolvimento deve ser feito sempre em cima da última versão.
>
>
Segundo 1 os desenvolvedores devem integrar e liberar código no repositório freqüentemente, em intervalos de poucas horas, sempre que possível. Cada par de programadores deve integrar o código desenvolvido sempre que um objetivo traçado seja alcançado, como: 100% dos testes passam ou uma funcionalidade esteja pronta.Em nenhum caso, este intervalo deve exceder um dia. A integração contínua garante que o desenvolvimento não resulte em esforços fragmentados ou divergentes. O desenvolvimento deve ser feito sempre em cima da última versão.
Line: 7 to 7
Changed:
<
<
O papel da integração contínua dentro da metodologia XP pode ser melhor entendido neste diagrama.
>
>
O papel da integração contínua dentro da metodologia XP pode ser melhor entendido no diagrama abaixo. Apesar de ser uma prática imcorporado por XP, pode ser aplicada em outros processos, com resultados que valem os custos da implementação e manutenção.
Line: 9 to 9
Changed:
<
<
Cada par de programadores deve integrar o código que desenvolvido sempre que um objetivo traçado seja alcançado, como: 100% dos testes passam ou uma funcionalidade esteja pronta. Apenas um par integra por vez. 1
>
>
code.GIF
Line: 12 to 11
Changed:
<
<

Objetivos

>
>
Para ser ter um processo automático de construção, necessita-se:
  • manter um repositório único de código, onde-se pode obter a última versão(e também anteriores) dos fontes;
  • automatizar o processo de construção, para que todos possam usar o mesmo processo;
  • automatizar os testes para que seja fácil realizá-los;
  • ter certeza que qualquer um posso ter um executável, e que este seja o melhor executável construído.
Line: 14 to 17
Changed:
<
<
O objetivo deste trabalho é identificar e testar, quando possível, as ferramentas disponíveis para a automatização da integração contínua. Focaremos em ferramentas para Java e em Java, mas não exclusivamente. Limitaremos as ferramentas aqui apontadas, àquelas com código aberto(conforme definidio OSI).
>
>

Benefícios

Line: 16 to 19
Changed:
<
<

Ferramentas

>
>
A integração estimula o trabalho em equipe e uma maior disciplina, já que é necessário um comprometimento de cada membro para que o processo como um todo funcione.
Line: 18 to 21
Changed:
<
<
Nesta seção apontamos as ferramentas encontradas, listando suas características, funcionalidades, vantagens e desvantagens.
>
>
Mas o maior benefícios é eliminar as longas sessões de caça a bugs de integração, que surgem quando não se compreende o trabalho feito por outros. Esses problema são enfatizados pelo tempo, pois a medida que passa, fica mais difícl descobrir a origem dos problemas.
Line: 20 to 23
Changed:
<
<

Controle de Versão

>
>
Com a integração contínua a maioria dos bugs aparece rapidamente. Também são mais fáceis de encontrar já que o escopo onde podem estar é bastante reduzido e as mudanças ainda estão frescas na memória do programador.
Line: 22 to 25
Changed:
<
<
Em primeiro lugar precisamos de um repositório com controle de versão. As duas ferramentas mais populares nessa área são o CVS e o Subversion.
>
>
Este aumento de produtividade justifica a adoção e a manutenção de um processo de integração contínua. Entretanto, essa prática não garante a ausência de erros de integração. Já que baseia-se em testes, e teste não provam a ausência de erros.
Line: 24 to 27
Changed:
<
<

CVS

>
>

Porque contínua?

Line: 26 to 29
Changed:
<
<
Concurrent Version System, ou popularmente CVS, é o sistema de controle de versão mais conhecido e utilizado. É um software de grande funcionalidade, estável, amplamente reconhecido e suportado pela indústria e pela comunidade.
>
>
Parece meio esquisito dizer que deve ser feito ainda mais frequentemente aquilo que menos se deseja fazer. Entretanto, o trabalho de integração cresce exponencialmente em relação ao intervalo entre as integrações.
Line: 28 to 32
Changed:
<
<
Maiores informações sobre CVS podem ser encontradas aqui.
>
>
A automatização permite um trabalho rápido e fácil, já que computadores são perfeitos em tarefas repetitivas, ao contrário dos desenvolvedores humanos. A freqüência será apenas limitada pelo tempo que leva para a construção de uma distribuição.
Line: 30 to 35
Changed:
<
<

Subversion

>
>
Este sistema oferece uma saída simples em relação a construção: falhou ou obteve sucesso. Em caso de sucesso você pode, com tranquilidade, iniciar sua próxima tarefa. Em caso de falha, você tem a change de caçar o erro antes que ele vire um pesadelo perdido no meio de outras atualizações dois dias antes de uma data importante.
Line: 32 to 37
Changed:
<
<
Subversion surgiu com a intenção de substituir o CVS, corrigindo alguns defeitos deste. As características e operações são similares, resultando em uma baixa curva de aprendizado na transição de uma ferramenta para outra. Muitos projetos tem iniciado já utilizando Subversion e outros estão efetuando a mudança.
>
>

O que é uma construção de sucesso ?

Line: 34 to 39
Changed:
<
<
Maiores informações sobre Subversion podem ser encontradas na página oficial.
>
>
Segundo 2 uma construção de sucesso ocorre quando:
  • Quando as mais recentes arquivos são obtidos do repositório;
  • Todo arquivo é compilado do zero;
  • Todos os objetos são são linkados e preparados para execução(por exemplo, no caso de Java, a criação de um Jar);
  • O conjunto de testes é rodado contra o sistema.
Se todos os passos executam sem erros e sem intervenção humana temos uma construção de sucesso.
Line: 36 to 45
Deleted:
<
<

Automatização da construção

Line: 38 to 47
Changed:
<
<
A segunda ferramenta necessária, é a de automatização de construção do software. São exemplos de tarefas desse tipo de ferramenta: compilação, resolução de dependências, execução de testes, geração documentação etc.
>
>

Ponto único de recursos

Line: 40 to 49
Changed:
<
<

Ant

>
>
O desenvolvedor deve poder ter acesso a todos os arquivos necessários para o desenvolvimento com um simples comando. Nada de ter que procurar em diversos lugares ou com cada desenvolvedor e ter que adivinhar onde cada parte se encaixa.
Line: 42 to 51
Changed:
<
<
Ant é o ferramenta padrão de facto da comunidade Java, equivalente a ferramenta make do universo C++/Unix.
>
>
A solução mais simples para este caso está na utilização de um sistema de controle de versões, como o CVS ou Subversion.
Line: 44 to 53
Changed:
<
<
Baseia-se na idéia de tarefas(tasks, na terminologia em inglês) que são arranjadas, de acordo com a necessidade do projeto, em um arquivo de descrição utilizando XML. Ant já vem com diversas tarefas em sua distribuição como: java, jar, javac, javadoc, rmic e outras. Há também outras criadas pela comunidade e amplamente usadas como: cvs, svn, j2me, pmd etc. E, se mesmo com o grande número de tarefas disponíveis, você não encontrar o que precisa, é possível através da linguagem Java criar as suas próprias tarefas.
>
>

Scripts de construção

Line: 46 to 55
Changed:
<
<
Maiores informações sobre Ant podem ser encontradas na página oficial.
>
>
Projetos muito simples podem apenas utilizar um simples javac * como construção. Mas a figura muda quando estamos falando de grandes projetos. Estes tipos de projetospodem levar algum tempo na construção, processando uma grande quantidade de arquivos e entradas, e gerando diversas saídas.
Line: 48 to 58
Changed:
<
<

Integração do processo

>
>
Uma boa ferramenta compatível com a tarefa é fundamental. Para cada tipo de projeto pode haver uma solução diferente, pode-se utilizar, por exemplo: linguagens de script(shell, Perl, Python), Make, Ant, Maven e CruiseControl.
Line: 50 to 62
Changed:
<
<

CruiseControl?

>
>

Conjunto de testes

Line: 52 to 64
Changed:
<
<

Maven

>
>
Para ter uma construção de sucesso, um conjunto de testes(unidades e/ou aceitação) também deve ser rodado para a validação. Os testes que rodam não são apenas os que garantem compatibilidade regressiva, mas também aqueles que acabaram de ser escritos para a verificação do código que se quer adicionar ao repositório, já que XP prega test a litle, code a litle.

Há também diversas que automatizam essa tarefa como, por exemplo, JUnit.

Conclusão

O segredo de ter um processo de integração contínua e automatizar toda tarefa possível. Assim erros de integração são encontrados rapidamente.

Line: 56 to 76
Added:
>
>

2 FOWLER, Martins Continuous Integration http://www.martinfowler.com/articles/continuousIntegration.html


 <<O>>  Difference Topic ProcessoDeConstrucao (r1.3 - 13 Oct 2004 - GuilhermeMartins)
Line: 1 3 to 1 2
Deleted:
<
<
TOC: No TOC in "XP.ProcessoDeConstrucao"
Line: 27 to 26
Added:
>
>
Concurrent Version System, ou popularmente CVS, é o sistema de controle de versão mais conhecido e utilizado. É um software de grande funcionalidade, estável, amplamente reconhecido e suportado pela indústria e pela comunidade.
Line: 31 to 32
Added:
>
>
Subversion surgiu com a intenção de substituir o CVS, corrigindo alguns defeitos deste. As características e operações são similares, resultando em uma baixa curva de aprendizado na transição de uma ferramenta para outra. Muitos projetos tem iniciado já utilizando Subversion e outros estão efetuando a mudança.
Line: 33 to 36
Added:
>
>

Automatização da construção

A segunda ferramenta necessária, é a de automatização de construção do software. São exemplos de tarefas desse tipo de ferramenta: compilação, resolução de dependências, execução de testes, geração documentação etc.

Ant

Ant é o ferramenta padrão de facto da comunidade Java, equivalente a ferramenta make do universo C++/Unix.

Baseia-se na idéia de tarefas(tasks, na terminologia em inglês) que são arranjadas, de acordo com a necessidade do projeto, em um arquivo de descrição utilizando XML. Ant já vem com diversas tarefas em sua distribuição como: java, jar, javac, javadoc, rmic e outras. Há também outras criadas pela comunidade e amplamente usadas como: cvs, svn, j2me, pmd etc. E, se mesmo com o grande número de tarefas disponíveis, você não encontrar o que precisa, é possível através da linguagem Java criar as suas próprias tarefas.

Maiores informações sobre Ant podem ser encontradas na página oficial.

Integração do processo

CruiseControl?

Maven


 <<O>>  Difference Topic ProcessoDeConstrucao (r1.2 - 28 Sep 2004 - GuilhermeMartins)
Line: 1 3 to 1 3
Changed:
<
<
-- GuilhermeMartins - 28 Sep 2004
>
>
TOC: No TOC in "XP.ProcessoDeConstrucao"
Line: 7 to 7
Changed:
<
<
Segundo [1] os desenvolvedores devem integrar e liberar código no repositório freqüentemente, em intervalos de poucas horas, sempre que possível. Em nenhum caso, este intervalo deve exceder um dia. A integração contínua garante que o desenvolvimento não resulte em esforços fragmentados ou divergentes. O desenvolvimento deve ser feito sempre em cima da última versão.
>
>
Segundo 1 os desenvolvedores devem integrar e liberar código no repositório freqüentemente, em intervalos de poucas horas, sempre que possível. Em nenhum caso, este intervalo deve exceder um dia. A integração contínua garante que o desenvolvimento não resulte em esforços fragmentados ou divergentes. O desenvolvimento deve ser feito sempre em cima da última versão.

O papel da integração contínua dentro da metodologia XP pode ser melhor entendido neste diagrama.

Line: 9 to 12
Added:
>
>
1

Objetivos

O objetivo deste trabalho é identificar e testar, quando possível, as ferramentas disponíveis para a automatização da integração contínua. Focaremos em ferramentas para Java e em Java, mas não exclusivamente. Limitaremos as ferramentas aqui apontadas, àquelas com código aberto(conforme definidio OSI).

Ferramentas

Nesta seção apontamos as ferramentas encontradas, listando suas características, funcionalidades, vantagens e desvantagens.

Controle de Versão

Em primeiro lugar precisamos de um repositório com controle de versão. As duas ferramentas mais populares nessa área são o CVS e o Subversion.

CVS

Maiores informações sobre CVS podem ser encontradas aqui.

Subversion

Maiores informações sobre Subversion podem ser encontradas na página oficial.

Line: 13 to 36
Changed:
<
<
#1 [1] Extreme Programming: A gentle introduction http://http://www.extremeprogramming.org/index.html
>
>
1 Extreme Programming: A gentle introduction http://http://www.extremeprogramming.org/index.html

 <<O>>  Difference Topic ProcessoDeConstrucao (r1.1 - 28 Sep 2004 - GuilhermeMartins)
Line: 1 to 1
Added:
>
>
META TOPICPARENT ApresentacaoDeTrabalhos
-- GuilhermeMartins - 28 Sep 2004

Introdução

Segundo [1] os desenvolvedores devem integrar e liberar código no repositório freqüentemente, em intervalos de poucas horas, sempre que possível. Em nenhum caso, este intervalo deve exceder um dia. A integração contínua garante que o desenvolvimento não resulte em esforços fragmentados ou divergentes. O desenvolvimento deve ser feito sempre em cima da última versão.

Cada par de programadores deve integrar o código que desenvolvido sempre que um objetivo traçado seja alcançado, como: 100% dos testes passam ou uma funcionalidade esteja pronta. Apenas um par integra por vez.

Referências

#1 [1] Extreme Programming: A gentle introduction http://http://www.extremeprogramming.org/index.html


Topic ProcessoDeConstrucao . { View | Diffs | r1.5 | > | r1.4 | > | r1.3 | More }
Revision r1.1 - 28 Sep 2004 - 18:45 - GuilhermeMartins
Revision r1.5 - 28 Nov 2004 - 22:55 - GuilhermeMartins
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding XP? Send feedback.