Você está na página 1de 4

Melhoria no Desenvolvimento gil com Implantao de Processo de Integrao Contnua Multiplataforma para Java e .

NET
Eliane F. Collins1,2, Thiago Falco1,2, Rafael Cunha1,2, Vicente Ferreira de Lucena Jr.2 Instituto Nokia de Tecnologia (INdT) Caixa Postal 7200 69048-660 Manaus AM Brasil 2 Universidade Federal do Amazonas (UFAM) Campus Universitrio 69077-000 Manaus AM Brasil
{eliane.collins,thiago.falcao,rafael.cunha}@indt.org.br, vicente@ufam.edu.br
1

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 experincia de implantar um processo de Integrao Contnua 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 Integrao Contnua ganhou importncia por garantir qualidade ao processo de integrao. Os resultados mostraram a viabilidade de se adotar um processo de integrao contnua para ganho em tempo para deteco de defeitos, reduo de custos e riscos e a melhoria da qualidade do produto.

1. Introduo
O Processo de Integrao Contnua (I.C.) a prtica no desenvolvimento de software onde os membros de um time devem integrar seu trabalho a cada alterao realizada. Cada integrao verificada, na qual testes unitrios e de aceitao so executados para detectar defeitos rapidamente. Com essa abordagem possvel reduzir problemas de integrao, controlar verses estveis do sistema e permitir que o time desenvolva rapidamente um software coeso [Stolberg 2009]. Contudo, para alguns desenvolvedores, a implantao desse processo dependendo da complexidade da plataforma, da experincia da equipe e das ferramentas adotadas pode se tornar caro e demorado. Apesar disso, este artigo ir mostrar que as vantagens desse processo compensam o investimento inicial de tempo e recursos. Na seo 2 contextualizado o ambiente da experincia realizada. Na seo 3 mostrado como se deu a implantao do processo de integrao contnua. A execuo e

os resultados obtidos sero analisados na seo 4 e por ltimo, na concluso, as lies aprendidas com o processo e os projetos futuros para a evoluo do ambiente.

2. Contexto do Ambiente
O projeto piloto desta experincia um sistema para realizar a manuteno preventiva de equipamentos que so utilizados ininterruptamente na produo de uma fbrica de produtos eletrnicos. Este sistema tem por objetivo evitar a substituio prematura de uma pea ou a parada de linha de produo devido ao desgaste e, com isso, diminuir os custos com a manuteno dos equipamentos de produo. Este projeto foi desenvolvido utilizando a metodologia gil de desenvolvimento Scrum [Schwaber 2004] e possu trs mdulos: o primeiro um cliente web na plataforma Java usando um servidor JBoss [JBoss 2010]; o segundo e o terceiro, so respectivamente, um webservice e um servio na plataforma .NET [Northrup 2009], ambos executando em um servidor Internet Infomation Services (IIS) [IIS 2011].

4. Implantao do Processo Multiplataforma de Integrao Contnua


Primeiramente foram realizadas pesquisas com ferramentas de I.C.. A ferramenta Open Source Hudson [Hudson 2010] foi escolhida, pois possui uma interface amigvel que permite sua configurao automtica. O Hudson possui plug-ins, os quais facilitam a integrao com outros softwares como JUnit [Lourindas 2005], NUnit [Williams et. al. 2009], Subversion (SVN)[Wright et. al 2009] e MSBuild [MSBuild 2011]. Para o mdulo do sistema na plataforma Java, foi utilizado Apache Ant [Serrano 2004]. Foi criado um arquivo XML responsvel por compilar todo o cdigo escrito em Java, rodar os testes unitrios usando JUnit como framework de teste, empacotar o arquivo, e finalmente envi-lo para o servidor atravs da ferramenta Hudson. O mdulo do sistema em .NET utilizou o Microsoft MSBuild, onde um arquivo MSBuild era responsvel por compilar todo o cdigo .NET, rodar os testes unitrios usando NUnit, e finalmente, executar a distribuio para o servidor IIS. Todo esse processo era executado pelo Hudson automaticamente.

Figura 1 - Arquitetura do Processo de Integrao Contnua Multiplataforma

Pode-se notar na figura 1 que a ferramenta Hudson em um servidor suporta dois mdulos do projeto, distribuindo as verses do software para os servidores JBoss e IIS.

5. Execuo e Resultados Obtidos


Os desenvolvedores codificavam os testes unitrios usando JUnit para a plataforma Java e NUnit para .NET. Ao final do dia, o time tinha que enviar o cdigo para o repositrio SVN, contudo, cada desenvolvedor tinha o dever de se certificar que o cdigo e os testes estavam corretos, para no causar erro na verso do sistema no servidor (build). Quando o cdigo era enviado, a mudana no projeto era automaticamente detectada pelo o servidor com o Hudson e imediatamente os scripts do Ant, e do MSBuild compilavam, executavam os testes, empacotavam o cdigo e enviavam a verso do software estvel para o servidor de destino (servidor de teste ou de produo). A ferramenta Hudson ao detectar falhas em qualquer passo desse processo, interrompia o script (Ant ou MSBuild), a verso no era enviada para o servidor de destino e todo time recebia um e-mail com o relatrio detalhado sobre as falhas encontradas. possvel visualizar na ferramenta o histrico de todo processo e das aes executadas por cada membro do time, identificando o autor de cada mudana. Em cinco iteraes do projeto foram geradas 140 builds para o mdulo Java e 283 builds para o mdulo .NET. Na figura 2, gerada pela ferramenta Hudson, pode-se observar a evoluo do nmero de testes unitrios executados para o mdulo Java. As falhas nos testes durante a integrao so representadas em cinza claro, em preto os testes no 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 a incidncia de falhas diminua. Isso ocorreu devido ao ambiente automatizado que propiciou facilidade na confeco de testes unitrios. A equipe de testes foi beneficiada com esse processo, pois as verses para teste se tornaram estveis e sem defeitos de integrao, o que possibilitou focar as atividades nos requisitos de negcio, usabilidade e teste de desempenho. Com isso o projeto no sofreu atrasos no cronograma de entregas e reduziram custos com correo de problemas e manuteno do sistema.

Em projetos anteriores implantao do processo de I. C., era comum encontrar cdigos que no compilavam, testes que falhavam, componentes do sistema que eram desenvolvidos em paralelo, softwares que funcionavam somente no computador de um desenvolvedor e no havia um software pronto para ser entregue a qualquer momento. Com isso, muitas falhas eram encontradas pelos testadores, o que ocasionava atraso na entrega do projeto e gasto com mais recursos devido baixa qualidade do sistema.

6. Concluso
O processo de I.C. possibilitou testes automatizados, distribuio rpida e verses do software estveis. Assim, as equipes ficaram focadas somente em desenvolver em suas plataformas, sem preocupao com a dependncia de outros componentes. Com a experincia, a equipe tomou como lio aprendida que importante para o sucesso do processo planejar em cada iterao o esforo de tempo para a criao, atualizao e execuo de testes unitrios e tambm a correo de defeitos detectados. Como aes para a evoluo e melhoria do processo de I.C., a equipe est adicionando ferramentas para automatizar testes de aceitao, inspeo e cobertura de cdigo para validar se o cdigo obedece aos padres estabelecidos pela equipe, o que ir garantir um cdigo uniforme, documentado e com mais qualidade.

References
Stolberg, S. (2009): Enabling Agile Testing through Continuous Integration, Agile Conference. Agile09, 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 edio, 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 Test Automation at Microsoft," Software Reliability Engineering, 2009. ISSRE '09. 20th International 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 release mismanagement," Emerging Trends in Open Source Software Research and Development, 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 us/library/0k6kkbsd.aspx, Janeiro. Reference, http://msdn.microsoft.com/en-