Integração Contínua: Aspectos e Fundamentos no Desenvolvimento de Software

Integrac¸a˜ o Cont´ınua: Aspectos e Fundamentos no Desenvolvimento de Software Felipe Grando S´oria1 ,Glauco Gomes1 , Rodrigo Galvan1 ,Orlando Renato Brenner Lantmann1 1

CITS – Centro Internacional de Tecnologia de Software Rua do Semeador, 702 - CEP 81270-050 - Curitiba - Paran´a - Brasil {felipe.soria,glauco.gomes,rodrigo.galvan,orlando.lantmann}@cits.br

Abstract. The Continuous Integration appears like a solution for software building problems in various software development processes, including MPS.BR. Idea applied most commonly in Agile methods, Continuous Integration is increasingly presenting results in other methodologies. The continuous creation of Builds with tests associated allows the creation of a better software because it can detect defects in the early stages of projects. Also this process has become an excellent tool in verifying the quality of code. Resumo. A Integrac¸a˜ o Cont´ınua aparece com soluc¸a˜ o para problemas na construc¸a˜ o de Builds nos mais diversos processos de desenvolvimento de software, incluindo o MPS.Br. Id´eia aplicada mais comumente em m´etodologias ´ Ageis a Integrac¸a˜ o Cont´ınua cada vez mais vem apresentando resultados em outras m´etodologias. A criac¸a˜ o de builds continuos permite o teste mais r´apido e eficiente dos sistemas pois consegue detectar defeitos nas fases iniciais dos projetos. Al´em disso esse processo se tornou uma excelente ferramenta na verificac¸a˜ o da qualidade de c´odigo.

1. Integrac¸a˜ o Cont´ınua e MPS.Br Buscando sempre uma melhor qualidade e maturidade no processo de desenvolvimento de software, o MPS-BR, visa estabelecer um conjunto de boas pr´aticas, que ajudam a fortalecer o mercado de software nacional. Seguindo essas premissas o CITS - Centro Internacional de Tecnologia de Software, realizou internamente uma s´erie de estudos envolvendo profissionais das a´ reas de an´alise, desenvolvimento e testes de software, os quais foram respons´aveis em pesquisar e analisar ferramentas e processos que permitissem aumentar o ´ındice de qualidade nos projetos desenvolvidos, dessa forma minimizando retrabalho atrav´es do uso de tarefas automatizadas, como por exemplo, o processo de testes e gerac¸a˜ o autom´atico de build. Atrav´es desse estudo o conceito de Integrac¸a˜ o Cont´ınua[Caelum 2008] foi amplamente discutido, o que possibilitou uma maior compreens˜ao do assunto e facilitando a implementac¸a˜ o de alguns desses conceitos em projetos ativos dentro do CITS, o que nos motivou a escrever este artigo.

2. Processo de IC A Integrac¸a˜ o Cont´ınua apresenta-se como uma soluc¸a˜ o para agilizar e melhorar a qualidade na criac¸a˜ o de ”Builds” no processo de desenvolvimento de software. Al´em disso,

fortalece ainda mais a regra 10 de Myers, que estabelece que o custo de correc¸a˜ o de defeitos tende a aumentar quanto mais tarde o defeito e´ detectado [Myers 2004]. Nem sempre e´ vi´avel ou mesmo necess´ario a utilizac¸a˜ o da IC em sua forma mais completa, a Figura 1 ilustra a estrutura da Integrac¸a˜ o Cont´ınua.

˜ Cont´ınua Figura 1. Estrura da Integrac¸ao

Muitas vezes, a utilizac¸a˜ o de partes desse processo, resolve e beneficia o desenvolvimento de software. A partir dele, pode-se adaptar e melhorar o processo conforme o problema a ser resolvido. O processo de integrac¸a˜ o cont´ınua pode conter os seguintes passos: • • • • • •

Versionamento de C´odigo Gerac¸a˜ o de Build Autom´atico An´alise de c´odigo Autom´atica Testes Caixa-Branca Autom´aticos Testes Caixa-Preta Autom´aticos Envio de Mensagens para Respons´aveis

2.1. Versionamento de C´odigo Embora seja comum em qualquer desenvolvimento organizado de c´odigo, o versionamento e´ parte fundamental e necess´aria para o processo de integrac¸a˜ o cont´ınua. A partir do versionamento, temos a centralizac¸a˜ o do c´odigo desenvolvido, al´em de permitir a criac¸a˜ o dos builds a partir de qualquer alterac¸a˜ o adicionada no desenvolvimento do sistema. Seguindo a id´eia de que toda vez que um c´odigo e´ alterado ou modificado, a partir do controle e versionamento desses, e´ poss´ıvel definir-se os pontos necess´arios para reteste do aplicativo bem como a possibilidade de verificac¸a˜ o dos pontos modificados. 2.2. Gerac¸a˜ o de Build Autom´atico Com o aumento de tamanho e complexidade dos sistemas, a criac¸a˜ o de builds est´aveis de software, se tornou mais dif´ıcil. As aplicac¸o˜ es cada vez mais necessitam da integrac¸a˜ o com outras, tornando a criac¸a˜ o do build um processo oneroso e complicado e muitas vezes pass´ıvel de erros. A implantac¸a˜ o de um sistema em servidores de teste ou mesmo homologac¸a˜ o e/ou produc¸a˜ o e´ uma tarefa que toma tempo e pode ser um risco do projeto.

A gerac¸a˜ o do build autom´atico apresenta-se como soluc¸a˜ o para esses problemas. Basicamente, automatizac¸a˜ o do build consiste na criac¸a˜ o de scripts que, quando executados na ordem e tempo correto, resolvem os problemas de dependˆencias na criac¸a˜ o de um build. Hoje, ferramentas como Jenkins [ 2011], Hudson [Hudson 2011], entre outras amparam a realizac¸a˜ o desse processo. Essas ferramentas s˜ao gerenciadores da criac¸a˜ o dos Builds, a partir delas pode-se criar regras de criac¸a˜ o de builds. Por exemplo, pode-se definir que a cada ”commit” de um desenvolvedor um novo build seja criado, ou ent˜ao, ao final de todos os dias um build e´ gerado. Hoje a gerac¸a˜ o do Build e´ o ponto m´ınimo para que a Integrac¸a˜ o Continua exista. 2.3. An´alise de c´odigo Autom´atica A an´alise de c´odigo autom´atica toda vez que um buid ou c´odigo e´ gerado, permite garantir a redigibilidade e legibilidade de cada parte de c´odigo desenvolvido. Isso garante a integridade de c´odigo permitindo a todos os profissionais que necessitem alterar algum c´odigo existente consigam entender esse e modific´a-lo sem a necessidade do envolvimento do criador da primeira vers˜ao desse. Al´em disso, os padr˜oes e a criac¸a˜ o de c´odigos voltados aos padr˜oes garantem uma maior efic´acia e eficiˆencia na resoluc¸a˜ o de poss´ıveis problemas que possam ser inseridos no desenvolvimento. 2.4. Testes Caixa-Branca Autom´aticos Quanto antes um defeito for encontrado mais f´acil e menos custoso e´ sua resoluc¸a˜ o [Myers 2004]. Os testes caixa-branca est˜ao intimamente ligados ao desenvolvimento do c´odigo. Eles permitem que defeitos ao n´ıvel do desenvolvedor, ou seja, mais baixo n´ıvel, como problemas de l´ogica, possam ser encontrados e resolvidos antes que sejam testados a n´ıvel de usu´ario. Esses testes, geralmente amparados por frameworks de testes unit´arios, servem como crit´eria de aceitac¸a˜ o de build, garantindo assim que os testes caixa-preta possam ser focados em regras de neg´ocio do sistema e n˜ao em problemas espec´ıficos de desenvolvimento. 2.5. Testes Caixa-Preta Autom´aticos A partir do momento que temos a garantia de que os problemas, ou parte dos problemas, no que se refere ao desenvolvimento do software foram encontrandos nas fases anteriores aos testes caixa-preta, podemos ent˜ao realizar testes de interface gr´afica, seguranc¸a, funcionalidade, etc. de forma autom´atica com o aux´ılio de ferramentas de automac¸a˜ o de testes caixa-preta. Esses teste permitem garantir que as funcionalidades, a n´ıvel de usu´ario, continuam funcionando mesmo com as alterac¸o˜ es realizads no c´odigo anteriormente. Os testes caixa-preta autom´aticos s˜ao o u´ ltimo passo antes da validac¸a˜ o e realizac¸a˜ o de testes manuais que garantam a qualidade do que foi desenvolvido. 2.6. Envio de Mensagens para Respons´aveis Muitas das ferramentas dispon´ıveis para gerenciamento e controle de tarefas de automatizac¸a˜ o de builds e Integrac¸a˜ o Cont´ınua, oferecem recursos que permitem o envio de informac¸o˜ es com status do desenvolvimento, dessa forma os membros da equipe s˜ao informados sobre o andamento do projeto a cada commit realizado, e poss´ıvel ainda configurar parˆametros que permitem enviar alertas sobre builds corrompidos ou que apresentem inconsistˆencias t´ecnicas que envolvam parˆametros de desenvolvimento como, por exemplo, ´ındices de complexidade ciclom´atica[ 2008].

3. Estudo de Caso Nos meses de maio e junho de 2011, foram designados dois desenvolvedores para implantar a Integrac¸a˜ o Cont´ınua em um dos projetos do CITS. Esse projeto serviu de piloto para implantac¸a˜ o do processo de Integrac¸a˜ o Cont´ınua denttro da empresa. Como todo processo, ele foi utilizado como base e adaptado as necessidade primordiais do cliente, mais do que isso, esse processo est´a sempre sendo revisado melhorado. O projeto teve como escopo o desenvolvimento de uma biblioteca desenvolvida em linguagem C++, a criac¸a˜ o e adaptac¸a˜ o de uma biblioteca dinˆamica que j´a estava em produc¸a˜ o sendo utilizado por clientes do nosso cliente, sendo necess´ario a inclus˜ao de novas funcionalidades, melhorias do c´odigo e portabilidade para outros sistemas operacionais, como o sistema estava em produc¸a˜ o uma necessidade b´asica do sistema era a qualidade e velocidade na gerac¸a˜ o dos builds. Os sistemas operacionais em que o software funciona, e deveria continuar funcionando, s˜ao Windows[OS 2011] e Linux[OS 2011] ou seja os dois principais sistemas operacionais utilizados no mercado. Para a vers˜ao Linux, o software deveria estar compat´ıvel com seis distribuic¸o˜ es espec´ıficas, para a vers˜ao windows, para as principais distribuic¸o˜ es como pode ser visto na Tabela1 abaixo. Sistema Operacional Vers˜ao Windows XP, Vista, Seven 32 bits Windows XP, Vista, Seven 64 bits Debian 5 32 bits Debian 5 64 bits Ubuntu 10 32 bits Ubuntu 10 64 bits Sles 10 32 bits Sles 10 64 bits Sles 11 32 bits Sles 11 64 bits OpenSuse 11 32 bits OpenSuse 11 64 bits Mandriva 2010 32 bits Mandriva 2010 64 bits ´ Tabela 1. Tabela de cenarios

Foram criados builds no formato de pacotes ”deb”, ”rpm” e ”dll” conforme a distribuic¸a˜ o em quest˜ao. Al´em disso o software deveria ter compatibilidade com a arquitetura do processador em quest˜ao, ou seja, suportando hardware de 32 e 64 bits, sendo assim necess´ario gerar o build (compilar o c´odigo) nesse cen´arios. Desta forma a gerac¸a˜ o de build necessitou a criac¸a˜ o de 14 builds diferentes a serem realizadas em cada cen´ario como os definidos. A partir desse cen´ario, adaptou-se o processo proposto e focado os resultados conforme a necessidade do cliente em quest˜ao. Assim para cada n´ıvel definido anteriormente a implantac¸a˜ o foi alterada e amparada por ferramentas nos diversos n´ıveis do processo comforme a Tabela 2.

Atividade Ferramenta Versionamento de C´odigo Subversion Gerac¸a˜ o de Build Autom´atico Jenkins e Doxigen An´alise de c´odigo Autom´atica Vera++ e cppCheck Testes Caixa-Branca Autom´aticos API Sanity Autotest e Valgrind Testes Caixa-Preta Autom´aticos – Envio de Mensagens para Respons´aveis Jenkins Tabela 2. Tabela de ferramentas

4. Subversion - Versionamento de C´odigo A escolha do subversion se deu devido a equipe de desenvolvimento j´a etar acostumada com a interface do sistema. A aplicac¸o˜ a serviu para o monitoramento de mudanc¸as no c´odigo. Al´em disso, todo controlador de vers˜ao, permite que voltar a uma vers˜ao anterior caso uma mudanc¸a se mostre errada, verificar mudanc¸as feitas a um arquivo. Quando se realiza o desenvolvimento em grupo, e´ comum que mais de um desenvolvedor fac¸a modificac¸o˜ es a um mesmo arquivo sendo assim necess´ario juntar as modificac¸o˜ es de ambos em uma vers˜ao u´ nica, isso e´ poss´ıvel atrav´es do sistema de versionamento automaticamento[Jo˜ao Araujo Ribeiro 2011].

5. Gerac¸a˜ o de Build Autom´atico A escolha da ferramenta utilizada para a gerac¸a˜ o do build foi feita atrav´es de uma pesquisa inicial das ferramentas dispon´ıveis. A partir dessa pesquisa optou-se pela ferramenta Jenkins[ 2011] para esse cen´ario. Essa decis˜ao se deu a partir da availiac¸a˜ o do desenvolvedor respons´avel, que levou em considerac¸a˜ o a facilidade de uso da ferramenta, tamanho da comunidade etc. Uma necessidade do cliente, era a criac¸a˜ o autom´atica da documentac¸a˜ o. Para isso a ferramenta Doxigen[Doxygen 2011] foi utilizada e seu resultado publicado via FTP. A ferramenta Jenkins foi desenvolvida em uma m´aquina Windows 32 bits como mestre, e comandava as outras m´aquinas como escravas. Estas m´aquinas s˜ao todas virtuais e, nas m´aquinas Linux, h´a mais um n´ıvel de emulac¸a˜ o, utilizando o processo chroot para permitir a compilac¸a˜ o para diferentes distros.

6. An´alise de c´odigo Autom´atica O desenvolvimento da aplicac¸a˜ o foi realizada utilizando C++, assim para uma an´alise do c´odigo duas ferramentas foram utilizadas. Para a An´alise de conformidade ao padr˜ao de estilo de c´odigo foi utilizado a ferramenta Vera++[Vera 2011] e para realizar uma busca de poss´ıveis defeitos devido a` n˜ao utilizac¸a˜ o das melhores pr´aticas de programac¸a˜ o, a ferramenta CppCheck[CppCheck 2011].

7. Testes Caixa-Branca Autom´aticos Para os testes unit´arios, devido a falta de tempo e prazos mais curtos, uma ferramente de gerac¸a˜ o de testes unit´ario autom´atico foi utilizado. Essa ferramenta realiza a busca de func¸o˜ es que terminam anormalmente ou travam quando lhe s˜ao enviados argumentos aleat´orios, essa ferramenta e´ API Sanity Autotest[Sanity 2011]. Para uma an´alise de consumo de mem´oria com detecc¸a˜ o de vazamentos de mem´oria a ferramenta Valgrind[Valgrind 2011] foi usada.

8. Testes Caixa-Preta Autom´aticos Para esse projeto espec´ıfico n˜ao houve a necessidade da criac¸a˜ o de testes caixa-preta, pois o software apresentava apenas funcionalidades sem a necessidade da intervenc¸a˜ o do usu´ario.

9. Envio de Mensagens para Respons´aveis A ferramenta de gerenciamento da criac¸a˜ o dos builds Jenkins[ 2011] realiza essa tarefa em suas configurac¸o˜ es.

10. Gerenciamento da construc¸a˜ o do Build Um ponto importante ressaltar e´ que a ferramenta de gerenciamento de gerac¸a˜ o de builds, no caso do estudo de caso a ferramenta Jenkins[ 2011], n˜ao foi desenvolvida para realizar todas as ac¸o˜ es na gerac¸a˜ o de build, justamente para permitir ao usu´ario uma maior flexebilidade na sua utilizac¸a˜ o, mas permite o gerenciamento de diversos scripts que realizem as tarefas necess´arias no momento certo. Sendo assim, para a realizac¸a˜ o das tarefas do processo de Integrac¸a˜ o Cont´ınua alguns scripts desenvolvidos em Windows Batch , Python e Windows PowerShell foram desenvolvidos permitindo assim a criac¸a˜ o dos builds de forma correta em cada cen´ario.

11. Resultados O tempo total de compilac¸a˜ o chegou a 23 minutos, executando a gerac¸a˜ o de oito builds simultaneamente. Ao se executar a gerac¸a˜ o de quatorze builds simultaneamente os resultados demoram mais devido a competic¸a˜ o pelos recursos da m´aquina. Um desenvolvedor, ao executar manualmente, os procedimentos de gerac¸a˜ o de desse builds, necessitou cerca de duas horas. Al´em do tempo muito maior no processo realizado manualmente esse processo estaria sujeito aos diversos problemas comuns a criac¸a˜ o humana de builds. 2

˜ entre o processo de gerac¸ao ˜ de build Figura 2. Comparac¸ao

12. Conclus˜ao Depois de superada a curva inicial de aprendizado sobre a utilizac¸a˜ o de ferramentas e processos de Integrac¸a˜ o Cont´ınua, foi poss´ıvel observar que algumas etapas devem ser avaliadas no sentido de medir se o esforc¸o t´ecnico aplicado justifica sua utilizac¸a˜ o, uma vez que a complexidade[Bruno Lage. 2011] envolvida pode inviabilizar alguns projetos, principalmente os de menor porte ou com um numero mais reduzido de desenvolvedores. Em nosso estudo de caso, aplicamos o uso da integrac¸a˜ o continua em um projeto de maior complexidade, dessa forma foi poss´ıvel avaliar e exemplificar claramente os benef´ıcios propostos por este conceito, uma vez que neste caso a gerac¸a˜ o de builds submetidos ao processo de testes apresentavam um grande volume de interac¸o˜ es, gerando um esforc¸o que sobrecarrega tanto a equipe de desenvolvimento como os testadores. Ap´os a mudanc¸a no processo com o uso do processo de automatizac¸a˜ o de builds, ficou vis´ıvel ao ganho de produtividade na equipe de desenvolvimento atrav´es da paralelizac¸a˜ o das atividade diminuindo assim o tempo necess´ario para a obtenc¸a˜ o dos resultados. O processo de criac¸a˜ o de build, execuc¸a˜ o de testes, an´alise de c´odigo, etc. e´ muito custoso e desmotivante para qualquer profissional. Isso e´ evitado atrav´es de um processo bem definido e pr´atico de Integrac¸a˜ o Cont´ınua.

Referˆencias (2008). Complexidade ciclom´atica. http:// logbr.reflectivesurface.com/2008/11/12/ conceitos-de-programacao-complexidade-ciclomatica/. Informac¸o˜ es sobre complexidade ciclom´atica. (2011). Jenkins. http://jenkins-ci.org/. Informac¸o˜ es sobre Jenkins. Bruno Lage. (2011). Integrac¸a˜ o cont´ınua - cruisecontrol.net. http://www.lagix. com.br/2011/04/integracao-continua-cruisecontrolnet. html/. Informac¸o˜ es sobre Integrac¸a˜ o Cont´ınua - CruiseControl.NET. Caelum (2008). Integrac¸a˜ o continua. http://blog.caelum.com.br/ integracao-continua/. Site sobre informac¸o˜ es e comparativos sobre integrac¸a˜ o continua. CppCheck (2011). Cppcheck. http://sourceforge.net/projects/ cppcheck/. Informac¸o˜ es sobre cppcheck. Doxygen (2011). Doxygen. http://www.stack.nl/˜dimitri/doxygen/. Informac¸o˜ es sobre doxigen. Hudson (2011). Hudson. http://hudson-ci.org/. Informac¸o˜ es sobre Hudson. Jo˜ao Araujo Ribeiro (2011). Subversion. http://www.geomatica.eng.uerj. br/docentes/araujo/. Informac¸o˜ es sobre subversion. Myers, G. J. (2004). The Art of Software Testing, Second Edition. Wiley, 2 edition. OS (2011). Os. http://www.guiadopc.com.br/artigos/3394/ as-10-principais-diferencas-entre-o-windows-e-o-linux. html. Informac¸o˜ es sobre OS. Sanity (2011). sanity test. http://ispras.linuxfoundation.org/index. php/API_Sanity_Autotest. Informac¸o˜ es sobre sanity test. Valgrind (2011). Valgrind. http://valgrind.org/. Informac¸o˜ es sobre valgrind. Vera (2011). Vera++. http://www.inspirel.com/vera/. Informac¸o˜ es sobre vera++.