| <<O>> Difference Topic ProcessoDeConstrucao (r1.5 - 28 Nov 2004 - GuilhermeMartins) |
| Line: 1 77 to 1 78 | ||||||||
|---|---|---|---|---|---|---|---|---|
| Added: | ||||||||
| > > |
| |||||||
| <<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 | |||||||
| > > |
| |||||||
| Line: 12 to 11 | ||||||||
| Changed: | ||||||||
| < < |
Objetivos | |||||||
| > > |
Para ser ter um processo automático de construção, necessita-se:
| |||||||
| 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:
| |||||||
| 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ãoO 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çãoA 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.AntAnt é 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 processoCruiseControl?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
ObjetivosO 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).FerramentasNesta seção apontamos as ferramentas encontradas, listando suas características, funcionalidades, vantagens e desvantagens.Controle de VersãoEm 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.CVSMaiores informações sobre CVS podem ser encontradas aqui.SubversionMaiores 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: | ||||||||
| > > |
IntroduçãoSegundo [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. |