APLICAÇÃO DA INTEGRAÇÃO CONTÍNUA EM EQUIPES ÁGEIS Marcos Henrique Moreno Klein 1, Luiz Camargo 2 RESUMO: A integração contínua é um assunto relativamente novo e está tornando uma prática comum em equipes de desenvolvimento de software, devido a popularização das práticas ágeis. Este artigo irá apresentar seus benefícios, ferramentas e uma análise dos resultados obtidos com a implantação de suas práticas na Softplan/Poligraph. Empresa de desenvolvimento de software que iniciou a utilização das metodologias ágeis Scrum, Kanban há cerca de 5 anos, e a 1 ano e meio vem aplicando as práticas de integração contínua em seu processo de desenvolvimento. Palavras-chave: Software. Práticas ágeis. Scrum. Integração Contínua. 1 INTRODUÇÃO O Artigo está organizado como se segue. Na seção 2, deparamos com o desenvolvimento ágil, ponto de partida para a prática da integração contínua. Relata sobre a história e o porquê do desenvolvimento ágil em software e seus princípios básicos. Na seção 3, é relatado o conceito de integração contínua, suas vantagens, requisitos para sua aplicação e etapas de funcionamento. Na seção 4, relata sobre a implantação das práticas de integração contínua na empresa Softplan/Poligraph, os cenários antes e depois das práticas implantadas, os benefícios e resultados obtidos após sua implantação. E por fim, na seção 5, é encontrado a conclusão e possíveis trabalhos futuros. 2 DESENVOLVIMENTO ÁGIL O mercado de desenvolvimento de software está cada vez mais competitivo e por isso tornou-se necessário que o desenvolvimento de softwares seja feito de forma mais rápida, com mais qualidade e menor custo. Para atender essa necessidade o uso de metodologias ágeis tornou-se popular, desde que ocorreu o Manifesto Ágil (Beck, et al., 2013) que indica alguns princípios que são compartilhados por tais métodos: Indivíduos e interações são mais importantes que processos e ferramentas; Software funcionando é mais importante do que documentação detalhada; Colaboração dos clientes é mais importante do que negociação de contratos; Adaptação às mudanças é mais importante do que seguir um plano. Desenvolvimento ágil como um conjunto de filosofias, onde defende a satisfação do cliente e a entrega de incremental prévio; Equipes de projeto pequenas e altamente motivadas; Métodos informais; Mínimos artefatos de engenharia de software e acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que análise e projeto (embora não desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes [PRESSMAN, 2011]. 1 Pós-graduando em Engenharia de Software pela UNISOCIESC. E-mail (marcoshklein@gmail.com) 2 Professor de pós-graduação pela UNISOCIESC. E-mail (camargho@gmail.com)
Mas o que seria uma equipe ágil em desenvolvimento de software? uma equipe ágil é aquela rápida e capaz de responder apropriadamente a mudanças. Mudanças tem tudo a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudança nos membros da equipe, mudanças devidos a novas tecnologias, mudanças de todos os tipos que poderão ter um impacto no produto que está em construção ou no projeto que cria o produto. Suporte para mudanças deve ser incorporado em tudo que fazemos em software, algo que abraçamos porque é o coração e a alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar estão no cerne do sucesso do projeto [JACOBSON, 2013]. A adaptação de métodos ágeis dentro de uma empresa é uma tarefa desafiadora. Agilidade não é como um mero software que pode simplesmente ser instalado algum dia. A agilidade precisa ser adaptada ao contexto da empresa, incluindo seus aspectos culturais, técnicos e organizacionais [NARAYANAN, 2009]. Uma das vantagens das metodologias ágeis em contraposição às metodologias tradicionais é a flexibilidade que estas possuem quando inseridas em ambientes que têm características como: definição dos requisitos com mudanças constantes, onde as equipes são pequenas e os prazos são mais curtos, o que por fim caracteriza a necessidade de um desenvolvimento rápido [LUNA, COSTA, MOURA, 2011]. 3 INTEGRAÇÃO CONTÍNUA A integração contínua faz parte do que é conhecido como metodologia ágil e é considerada como um dos pilares da agilidade. Trata-se de uma prática que visa solucionar problemas que envolvem a unificação das alterações realizadas na base de códigos fonte de um projeto, em um cenário, onde vários desenvolvedores buscam um mesmo objetivo na elaboração de um projeto. A utilização da integração contínua não está restrita apenas ao desenvolvimento de grandes projetos. Aqueles considerados pequenos e/ou médios, também podem utilizá-la, seguramente. Nos processos mais tradicionais, a integração era feita depois do desenvolvimento de todas as partes e de forma isolada, o que difere da integração contínua, introduzida como uma das práticas do processo XP (Extreme Programming) que é efetuada depois que cada parte de desenvolvimento é completada, ou mesmo em várias vezes durante a programação em um dia. Isso faz com que a organização tenha a possibilidade de controlar, de forma mais eficaz, o que está sendo feito por todos os desenvolvedores. Assim, para que haja sucesso no processo de desenvolvimento, uma comunicação eficiente e eficaz entre todos os envolvidos (stakeholders) é fundamental para o que o processo seja produtivo. Segundo os conceitos ditos por Martin Fowler [FOWLER, 2006], o processo de integração contínua consiste simplesmente em integrar código fonte, porém hoje em dia é muito discutido este processo de forma automatizada e seus benefícios. Existe um ciclo de desenvolvimento com integração contínua que gira em torno de alguns requisitos definidos por Fowler, que é fazer uma cópia local do repositório conhecida como checkout; desenvolver sua tarefa com testes unitários; atualizar a cópia local com a versão do repositório; montar um build do projeto e passar por todos os testes, se algo der errado nos testes é preciso corrigir até que a versão esteja sincronizada com a versão principal; guardar suas alterações no repositório através do comando commit; montar um build a partir de uma máquina de integração garantindo que todas as novas alterações foram submetidas corretamente, de preferência de forma automática com algum programa de integração contínua. Muitos acreditam que essa abordagem leva uma significante redução nos problemas de integração, e permite que uma equipe desenvolva software coeso com mais agilidade. A grande vantagem da utilização desta metodologia é o feedback instantâneo, uma forma de trazer segurança em relação as mudanças, fundamental para introduzir novas funcionalidades e não erros.
Basicamente funciona da seguinte forma: a cada commit no repositório, o build é disparado automaticamente, com todos os testes e falhas sendo detectadas. Caso a construção de um novo build apresente problemas equipe será notificada instantaneamente (através de e-mail ou painéis por exemplo, indicando as falhas e o commit causador das mesmas). Com isso a equipe torna-se proativa e consegue resolver os problemas encontrados o mais rápido possível. É interessante ressaltar que a integração contínua é uma prática que requer disciplina e aceitação de sua equipe, a ideia é que as entregas dos desenvolvedores sejam menores e com mais frequência e que a prioridade mais alta é deixar a versão atual sempre funcionando. O sistema básico de funcionamento da integração contínua consiste em: Verificar se o build está rodando, se estiver aguarde finalizar, caso quebre toda a equipe deve se mobilizar para resolver o problema o mais rápido possível, após finalizar corretamente, suba suas alterações; Execute o build localmente (incluindo testes automatizados) antes de integrar as alterações; Se falhar pare imediatamente e ajuste localmente; Se passar vá para a próxima tarefa; Não é aconselhado o desenvolvimento de tarefas em outros branchs, pois a ideia de código integrado se perde, a não ser por questões limitadas. 4 IMPLEMENTANDO A INTEGRAÇÃO CONTÍNUA Antes de começar são necessários três coisas: Controle de versão Local onde tudo que está relacionado ao seu projeto será reportado (códigos, testes, scripts, build e etc.). A utilização de um sistema de controle de versão é consideravelmente uma ação importante para que toda a equipe possa trabalhar com o mesmo projeto. O controle de versão apoia o desenvolvimento através de históricos nos quais se registra toda a evolução do projeto, todas as alterações sobre cada um dos arquivos do projeto permitindo saber o que, quando e onde foi feita uma determinada alteração [SOMMERVILLE, 2011]. Build automatizado O processo de automatização de build surge de forma a beneficiar o desenvolvimento dia-a-dia. Uma vez que todo o pacote de código fonte está em um repositório, a ferramenta faz uma espécie de checkout deste código para que em meio as configurações específicas os plugins possam controlar todo o código fonte, e também relatórios de testes executados que foram automatizados. O Build automatizado pode até ser via linha de comando, desde que seja feito com sucesso e com todos os testes automatizados rodados. Existem várias ferramentas que podem ser usadas para implementá-lo (exemplos: FinalBuilder, Jenkins, Ant, Maven, Sonar, Structure, Hudson). Acordo com a equipe É de extrema importância que a equipe faça as entregas menores e com mais frequência, isso reduzirá o impacto quando integrar os códigos. 4.1 O primeiro cenário O cenário anterior à aplicação das práticas de integração contínua era problemático, havia apenas um repositório dos códigos fonte do sistema, local em que todos os desenvolvedores realizavam
commit, porém não era compilado com frequência, gerando inúmeros problemas quando havia a necessidade de liberação de uma nova versão para o cliente. Não havia uma ferramenta adequada para o controle de versão, era utilizado um controle a nível de arquivo, dificultando o rastreamento de modificações realizados no código fonte. Também por falta de ferramenta adequada a sincronização dos arquivos de código fonte eram feitos de forma manual. Ocorriam problemas de integração com implementações, onde várias pessoas alterassem o mesmo arquivo ou mesmo em algo que impactasse a implementação um do outro, pois era possível encontrar o problema somente após compilar a versão atual do repositório. A cada desfecho de uma versão demandava o tempo de uma a duas semanas para deixar a versão estável, como o código não era compilado com frequência os erros de integração eram só vistos no final da versão. Com o tempo curto de testes para deixar a versão integrada com todas as alterações realizadas dificultavam a vida para programadores e testadores encontrarem todas as falhas no sistema. A forma problemática de controlar as alterações do sistema se agravava com o tamanho da equipe, quanto maior, mais problemas de integração apareciam. 4.2 O primeiro passo para a mudança O primeiro passo da equipe foi utilizar um método síncrono de integração. A regra era uma espécie de semáforo, para integrar as alterações no trunc principal era necessário obedecer uma fila, cada interação era feita por vez e compilada após seu término. Este método resolveu alguns problemas de integração, o build era feito a cada integração e deveria estar sempre funcionando, a cultura da integração contínua estava sendo inserida na equipe. A responsabilidade com o build era atribuída a cada desenvolvedor, pois não poderia concluir sua atividade até integrar seu código com sucesso. Havia um problema nesse método: o tamanho da equipe. O tempo de integração no trunc principal era inviável, com um número de pessoas grande dentro da equipe havia uma grande fila de espera para integrar o código, algumas vezes era necessário aguardar até o outro dia para que pudesse ser feito. 4.3 A transformação da metodologia Mesmo obtendo os benefícios de uma versão atual compilável, era necessário melhorar o processo de integração. No decorrer do tempo foi alterado o software de gerenciamento de arquivos VSS (Visual Source Safe) para o TFS (Team Foundation Server) uma ferramenta da Microsoft que permite o gerenciamento de código fonte. Houve vários ganhos com os recursos deste software, a equipe passou a ter mais agilidade para integrar o código fonte devido ao merge automatizado da ferramenta (raras exceções é necessário resolver conflitos manualmente), histórico de alterações do código fonte detalhado, possibilidade de criar branchs, ferramenta de comparação de arquivos embutido entre outros. Também foi instituído o Jenkins, aplicação de monitoramento de execuções de tarefas que, por sua vez, são agendadas e configuradas, como por exemplo, a compilação de um projeto e ou a execução de testes automatizados. Jenkins trabalha com uma abordagem qual prioriza as saídas, as informações de retorno referente a cada tarefa pré-determinada, e tudo aquilo que é executado/criado. Assim, essas saídas são mantidas para que possam ser perceptíveis todo e qualquer processo que esteja errado [JENKINS, 2011]. Construindo e testando continuamente, a aplicação fornece uma maneira fácil de usar o que é chamado de sistema de integração contínua, facilitando a tarefa dos desenvolvedores de integrar as alterações no projeto de software.
Resultados obtidos A utilização das novas ferramentas e a aplicação das práticas de integração contínua, trouxe rapidez para a integração do código fonte e fluidez no processo de desenvolvimento. O código fonte passou a ser compilado e testado a cada integração no sistema de controle de versão, com essas mudanças a entrega de uma versão do sistema é realizada em poucas horas. Podemos identificar na figura 1 números expressivos, em relação ao tempo médio em horas de entrega de uma versão (coluna azul) e em horas para encontrar erros de integração (coluna em laranja). As colunas da esquerda representam os dados antes da utilização das práticas de integração contínua e as colunas da direita com a utilização das práticas de integração contínua. Figura 1 - Melhorias com a utilização das práticas de integração contínua. 5 CONCLUSÃO Este trabalho avaliou a utilização das práticas de integração contínua na empresa Softplan/Poligraph, identificando os benefícios de sua utilização. O principal benefício é o feedback instantâneo, o que traz segurança em relação as mudanças, fundamental para introduzir novas funcionalidades e não erros. Com o tempo de sincronização reduzida a equipe obteve motivação para continuar com a cultura de integração contínua, os resultados foram expressivos, os erros com integração foram reduzidos consideravelmente e com isso conseguimos aumentar a produtividade e qualidade do desenvolvimento do código. O custo de tempo e esforço para a integração é menor com a utilização das ferramentas adequadas, a chance de inserir um código com erros é reduzida pela execução dos testes automatizados (desde que haja cobertura por testes e métricas). A probabilidade de ocorrer algum problema de integração é reduzida, pois o ciclo da integração é menor, existe mais agilidade para deixar o código integrado não deixando para o final da Sprint ou até mesmo da versão para integrar todo o código realizado.
É preciso manter a cultura de integrar o código em pequenos pedaços e com mais frequência para obter os benefícios da integração contínua. Como sugestões para trabalhos futuros pode se destacar o uso da ferramenta de integração contínua Jenkins com o plugin Sonar, para se avaliar o nível de maturidade no desenvolvimento de software. REFERÊNCIAS CAMARGO, L. C. Modelo de Documento do Artigo. Florianópolis, SOCIESC - Educação e Tecnologia. 2013. BECK, K; BEEDLE, M.; BENNEKUM, A.; COCKBURN, A.; CUNNINGHAM, W.; FOWLER, M.; THOMAS, D. Manifesto for Agile Software. 2013, Novembro. PRESSMAN, R. S. Engenharia de Software - uma abordagem profissional. v. 7, 2011. JACOBSON, I. D. P. W. The Essence of Software Engineering. v. 1, p. 5-7, 2013. NARAYANAN, V. Traduzido por MARQUES, Marcelo; ANDRADE, Marcelo(2009). Superando os Desafios Técnicos para a Adição de Métodos ágeis nas Empresas. Disponível em < http://www.infoq.com/br/articles/technical-challenges >. Acesso em 21 abril de 2014. LUNA, A. H. O.; COSTA, C. P.; MOURA, H. P. 2011. Engenharia de Software Magazine, edição 37, p. 05 19. A necessidade de ser ágil Uma análise crítica sobre novos métodos ágeis. Disponível em: <http://www.devmedia.com.br/websys.4/webreader.asp?cat=48&revista=esma gazine_37#a-3674 >. Acesso em 21 de abril de 2014. FOWLER, M.; HUMBLE, J.; FARLEY, D. Continuous Delivery, Boston, p. 3-17; 55-57, 2011. SOMMERVILLE, I. Engenharia de Software. 9ª Ed.2011, p. 73-97. Person/Prentice Hall, 2011. JENKINS. Disponível em: < http://jenkins-ci.org/ >. Acesso em 20 de abril de 2014. POOJA, G.; IVEY, M.; PENIX, J. Testing at the speed and scale of Google. 2011. Disponível em <http://google-engtools.blogspot.com.br/2011/06/testing-at-speed-and-scale-ofgoogle.html> Acesso em: 10 de fevereiro de 2014. LEE, K., A. Realizing continuous integration. Setembro, 2005. Disponível em: http://www.ibm.com/developerworks/rational/library/sep05/lee> Acesso em: 10 de fevereiro de 2014. SHORE, J. Continuous Integration on a Dollar a Day. 2006, Fevereiro. Disponível em <http://www.jamesshore.com/blog/continuous-integration-on-a-dollar-a-day.html> acesso em: 18 de fevereiro de 2014. BEZERRA L., SANTANA S. Integração Contínua Utilizando Jenkins. Disponível em <http://www.ebah.com.br/content/abaaagqaaah/integracao-continua-utilizando-jenkins>. Acesso em 20 de abril de 2014.
ABSTRACT: Continuous integration is a relatively new subject and is becoming a common practice in software development teams due to the popularization of agile practices. This article will introduce its benefits, tools and an analysis of the results obtained with the implementation of its practices in Softplan / Poligraph. Software development company that initiated the use of Agile Scrum, Kanban is about 5 years old and 1 and a half has been applying the practices of continuous integration in its development process. Keywords: Software. Agile Practices. Scrum. Continuous Integration.