2011_wdra_sbqs_curitiba

5/11/2018 2011_WDRA_SBQS_Curitiba - slidepdf.com

http://slidepdf.com/reader/full/2011wdrasbqscuritiba 1/4

Melhoria no Desenvolvimento Ágil com Implantação deProcesso de Integração Contínua Multiplataforma para Java

e .NETEliane F. Collins1,2, Thiago Falcão1,2, Rafael Cunha1,2, Vicente Ferreira de Lucena

Jr.2

1Instituto Nokia de Tecnologia (INdT)Caixa Postal 7200 – 69048-660 – Manaus – AM – Brasil

2Universidade Federal do Amazonas (UFAM)Campus Universitário – 69077-000 – Manaus – AM – Brasil

{eliane.collins,thiago.falcao,rafael.cunha}@indt.org.br,

[email protected]

Abstract. This paper describes an experience to implement a Continuous Integration process in a project with two software development platforms

(Java and .NET) and thereby improve the agile software process in terms of

quality. With the demand for agile development, the Continuous Integration

gained much importance in order to ensure quality the integration process.

The results showed the benefits of continuous integration adoption for gaining

time to detect defects, decrease costs and risks and improve product quality.

Resumo. Este artigo descreve a experiência de implantar um processo de

Integração Contínua em um projeto com duas plataformas de desenvolvimento

(Java e .Net) e, com isso, melhorar o processo ágil em termos de qualidade.

Com a demanda por rapidez no desenvolvimento, a Integração Contínua

ganhou importância por garantir qualidade ao processo de integração. Os

resultados mostraram a viabilidade de se adotar um processo de integração

contínua para ganho em tempo para detecção de defeitos, redução de custos e

riscos e a melhoria da qualidade do produto.

1. Introdução

O Processo de Integração Contínua (I.C.) é a prática no desenvolvimento de softwareonde os membros de um time devem integrar seu trabalho a cada alteração realizada.Cada integração é verificada, na qual testes unitários e de aceitação são executados paradetectar defeitos rapidamente. Com essa abordagem é possível reduzir problemas de

integração, controlar versões estáveis do sistema e permitir que o time desenvolvarapidamente um software coeso [Stolberg 2009].

Contudo, para alguns desenvolvedores, a implantação desse processodependendo da complexidade da plataforma, da experiência da equipe e das ferramentasadotadas pode se tornar caro e demorado. Apesar disso, este artigo irá mostrar que asvantagens desse processo compensam o investimento inicial de tempo e recursos.

Na seção 2 é contextualizado o ambiente da experiência realizada. Na seção 3 émostrado como se deu a implantação do processo de integração contÍnua. A execução e



os resultados obtidos serão analisados na seção 4 e por último, na conclusão, as liçõesaprendidas com o processo e os projetos futuros para a evolução do ambiente.

2. Contexto do Ambiente

O projeto piloto desta experiência é um sistema para realizar a manutenção preventivade equipamentos que são utilizados ininterruptamente na produção de uma fábrica deprodutos eletrônicos. Este sistema tem por objetivo evitar a substituição prematura deuma peça ou a parada de linha de produção devido ao desgaste e, com isso, diminuir oscustos com a manutenção dos equipamentos de produção.

Este projeto foi desenvolvido utilizando a metodologia ágil de desenvolvimentoScrum [Schwaber 2004] e possuí três módulos: o primeiro é um cliente web naplataforma Java usando um servidor JBoss [JBoss 2010]; o segundo e o terceiro, sãorespectivamente, um webservice e um serviço na plataforma .NET [Northrup 2009],ambos executando em um servidor Internet Infomation Services (IIS) [IIS 2011].

4. Implantação do Processo Multiplataforma de Integração ContínuaPrimeiramente foram realizadas pesquisas com ferramentas de I.C.. A ferramenta Open

Source Hudson [Hudson 2010] foi escolhida, pois possui uma interface amigável quepermite sua configuração automática. O Hudson possui plug-ins, os quais facilitam aintegração com outros softwares como JUnit [Lourindas 2005], NUnit [Williams et. al.2009], Subversion (SVN)[Wright et. al 2009] e MSBuild [MSBuild 2011].

Para o módulo do sistema na plataforma Java, foi utilizado Apache Ant [Serrano2004]. Foi criado um arquivo XML responsável por compilar todo o código escrito emJava, rodar os testes unitários usando JUnit como framework de teste, empacotar oarquivo, e finalmente enviá-lo para o servidor através da ferramenta Hudson.

O módulo do sistema em .NET utilizou o Microsoft MSBuild, onde um arquivoMSBuild era responsável por compilar todo o código .NET, rodar os testes unitáriosusando NUnit, e finalmente, executar a distribuição para o servidor IIS. Todo esseprocesso era executado pelo Hudson automaticamente.

Figura 1 - Arquitetura do Processo de Integração Contínua Multiplataforma



Pode-se notar na figura 1 que a ferramenta Hudson em um servidor suporta doismódulos do projeto, distribuindo as versões do software para os servidores JBoss e IIS.

5. Execução e Resultados Obtidos

Os desenvolvedores codificavam os testes unitários usando JUnit para a plataforma Javae NUnit para .NET. Ao final do dia, o time tinha que enviar o código para o repositórioSVN, contudo, cada desenvolvedor tinha o dever de se certificar que o código e os testesestavam corretos, para não causar erro na versão do sistema no servidor (build ).

Quando o código era enviado, a mudança no projeto era automaticamentedetectada pelo o servidor com o Hudson e imediatamente os scripts do Ant, e doMSBuild compilavam, executavam os testes, empacotavam o código e enviavam aversão do software estável para o servidor de destino (servidor de teste ou de produção).

A ferramenta Hudson ao detectar falhas em qualquer passo desse processo,interrompia o script (Ant ou MSBuild), a versão não era enviada para o servidor de

destino e todo time recebia um e-mail com o relatório detalhado sobre as falhasencontradas. É possível visualizar na ferramenta o histórico de todo processo e dasações executadas por cada membro do time, identificando o autor de cada mudança.

Em cinco iterações do projeto foram geradas 140 builds para o módulo Java e283 builds para o módulo .NET. Na figura 2, gerada pela ferramenta Hudson, pode-seobservar a evolução do número de testes unitários executados para o módulo Java. Asfalhas nos testes durante a integração são representadas em cinza claro, em preto ostestes não executados e em cinza escuro os testes que tiveram sucesso.

Figura 2. Cobertura de Teste

Conforme o processo de I.C. era executado, a cobertura de testes aumentava e aincidência de falhas diminuía. Isso ocorreu devido ao ambiente automatizado quepropiciou facilidade na confecção de testes unitários. A equipe de testes foi beneficiadacom esse processo, pois as versões para teste se tornaram estáveis e sem defeitos deintegração, o que possibilitou focar as atividades nos requisitos de negócio, usabilidadee teste de desempenho. Com isso o projeto não sofreu atrasos no cronograma deentregas e reduziram custos com correção de problemas e manutenção do sistema.



Em projetos anteriores à implantação do processo de I. C., era comum encontrarcódigos que não compilavam, testes que falhavam, componentes do sistema que eramdesenvolvidos em paralelo, softwares que funcionavam somente no computador de umdesenvolvedor e não havia um software pronto para ser entregue a qualquer momento.

Com isso, muitas falhas eram encontradas pelos testadores, o que ocasionava atraso naentrega do projeto e gasto com mais recursos devido à baixa qualidade do sistema.

6. Conclusão

O processo de I.C. possibilitou testes automatizados, distribuição rápida e versões dosoftware estáveis. Assim, as equipes ficaram focadas somente em desenvolver em suasplataformas, sem preocupação com a dependência de outros componentes.

Com a experiência, a equipe tomou como lição aprendida que é importante parao sucesso do processo planejar em cada iteração o esforço de tempo para a criação,atualização e execução de testes unitários e também a correção de defeitos detectados.

Como ações para a evolução e melhoria do processo de I.C., a equipe estáadicionando ferramentas para automatizar testes de aceitação, inspeção e cobertura decódigo para validar se o código obedece aos padrões estabelecidos pela equipe, o que irágarantir um código uniforme, documentado e com mais qualidade.

References

Stolberg, S. (2009): “Enabling Agile Testing through Continuous Integration”, AgileConference. Agile’09, pp.369-374,24-28 Aug. Doi:10.1109/AGILE.2009.16

Schwaber, K. (2004) Agile Project Management with Scrum. Microsoft Press, 2004.

JBoss (2010), “JBoss Documentation”, http://www.jboss.org/jbossas/docs, Dezembro.

IIS (2011), “IIS Learn Center”, http://learn.iis.net/, Janeiro.Northup Tony (2009), “Microsoft .NET Framework-Application Development

Foundation Training Kit”, Microsoft Press, Segunda edição, Washington.

Hudson (2010), “Hudson”, http://hudson-ci.org/docs/HudsonIntro.pdf, Dezembro.

Lourindas, P. (2005), “JUnit: unit testing and coiling in tandem”, Software, IEEE,vol.22, no.4, pp. 12- 15, July-Aug. 2005. Doi: 10.1109/MS.2005.100.

Williams, L.; Kudrjavets, G.; Nagappan, N.; (2009), "On the Effectiveness of Unit TestAutomation at Microsoft," Software Reliability Engineering, 2009. ISSRE '09. 20thInternational Symposium on, vol., no., pp.81-89, 16-19 Nov.Doi: 10.1109/ISSRE.2009.32.

Wright, H.K.; Perry, D.E.; (2009) , "Subversion 1.5: A case study in open source releasemismanagement," Emerging Trends in Open Source Software Research andDevelopment, FLOSS '09, pp.13-18, 18-18May. Doi:10.1109/FLOSS.2009.5071354.

Serrano, N.; Ciordia, I.; "Ant: automating the process of building applications,"Software, IEEE , vol.21, no.6, pp. 89- 91,Nov.-Dec. 2004. Doi: 10.1109/MS.2004.33

MSBuild (2011), “MS Build Reference, http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx”, Janeiro.

2011_wdra_sbqs_curitiba

Documents