Integração e Entrega Contínua para aplicações móveisdesenvolvidas em React Native

Pedro José de Souza NetoCentro de Informática, Universidade federal de

PernambucoRecife, Pernambuco, Brasil

pjsn@cin.ufpe.br

Vinicius Cardoso GarciaCentro de Informática, Universidade federal de

PernambucoRecife, Pernambuco, Brasil

vcg@cin.ufpe.br

RESUMOContinuous integration and continuous delivery are not new fordevelopers who create web applications, however in the develop-ment of mobile applications this practice is still not very commonmainly because of the challenges during the process of distributingthe application. In the face of the growing number of applications,a greater requirement for quality and ever-shorter delivery times,delivering a healthy code is often extremely important to keep upwith the competition. The purpose of this work is to implement anintegration and continuous delivery pipeline for mobile applicati-ons developed in React Native. It intends to automate the process ofbuild and delivery of applications developed with this technology.

CCS CONCEPTS• Software and its engineering→ Software evolution; Appli-cation specific development environments.

KEYWORDSpipeline, continuous integration, continuous delivery, react native,mobile applicationACM Reference Format:Pedro José de Souza Neto and Vinicius Cardoso Garcia. 2018. Integração eEntrega Contínua para aplicações móveis desenvolvidas em React Native.In Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação),Dezembro, 2018, Recife, PE. ACM, New York, NY, USA, 10 pages.

1 INTRODUÇÃOO crescente número de aplicações de software, uma exigência maiorem relação a qualidade e com os prazos de entrega cada vezmenores,acarretou em uma mudança que afetou o processo de desenvolvi-mento e a maneira que o software é entregue para o cliente. Diantedesse cenário, vimos o surgimento de metodologias como DevOps[Ebert et al. 2016], que tem como base a prática de integração eentrega contínua no seu ciclo operacional com a finalidade de au-mentar a capacidade de resposta às necessidades dos clientes pormeio de lançamentos de software frequentes e automatizados [10].Com a propagação dessas práticas supracitadas, muitas empresas de-senvolveram diversas soluções aplicando integração contínua [PaulDuvall and and Glover 2007; Zhao et al. 2017] e entrega contínua

Permission to make digital or hard copies of part or all of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).TCC BSI ’18, Dezembro, 2018, Recife, PE© 2018 Copyright held by the owner/author(s).

[Chen 2017] para aplicações web, porém no mundo de aplicaçõesmóveis, a adoção dessas práticas ainda é pouco utilizada [Jacksman2020; Klepper et al. 2015].

O objetivo deste trabalho é o estudo e a implementação de umapipeline de integração e entrega contínua para aplicações móveisdesenvolvidas em React Native [Facebook 2020] com fins de auto-matizar o processo de build e entrega destas aplicações tendo osseguintes objetivos específicos:

• Criação da pipeline da aplicação• Estudo de ferramenta de integração e entrega contínua• Estudo de ferramenta para testar aplicações React Native• Implementação de uma aplicação em React Native e dos tes-tes baseados nos estudos para realizar as funções desejadas

Para o desenvolvimento da pipeline, foram utilizadas as ferra-mentas Jenkins1, que é o principal servidor de automação opensource que fornece centenas de plugins para apoiar os processos debuild, implantação e automação para diversos tipos de projeto; BlueOcean2, que repensa a experiência do usuário do Jenkins, reduz adesordem e aumenta a clareza para todos os membros da equipe;TestFairy3, que é uma plataforma de testes para aplicações móveisque fornece registros e relatórios de falhas além de ser um meiode centralizar a distribuição do aplicativo; e, finalmente, o Slack4,que é uma canal de comunicação presente em quase todas as em-presas além de possuir ótimos meios de integração com as demaisferramentas utilizadas nesse trabalho.

Esse documento está organizado como se segue: Seção 1 - In-trodução: Apresenta motivações e objetivos do estudo; Seção 2 -Conceitos básicos: Apresenta um contexto teórico e tecnológicopara a compreensão dos capítulos seguintes; Seção 3 - Implemen-tação do aplicativo: Apresenta a escolha da tecnologia adotada, odesenvolvimento dos testes e do aplicativo; Seção 4 - A pipelinede integração e entrega contínua: Apresenta o passo a passo noprocesso de construção da pipeline; e, finalmente, Seção 5 - Conclu-sões: Apresenta as conclusões obtidas durante o desenvolvimentodo projeto, trabalhos futuros e limitações.

2 CONCEITOS BÁSICOSNesta seção são apresentados e discutidos os conceitos básicos quefundamentam este trabalho.

1https://www.jenkins.io/, último acesso em 29/03/20212https://www.jenkins.io/projects/blueocean/, último acesso em 29/03/20213https://www.testfairy.com/, último acesso em 29/03/20214https://slack.com/, último acesso em 29/03/2021

arX

iv:2

103.

1653

8v1

[cs

.SE

] 3

0 M

ar 2

021

TCC BSI ’18, Dezembro, 2018, Recife, PE Souza Neto e Garcia

2.1 Frameworks de desenvolvimento emJavaScript

No princípio, o JavaScript5 era utilizado na construção de anima-ções e para fornecer interatividade para algumas páginas da web.Contudo, não existia nenhum tipo de comunicação com o servidor,todas as ações eram voltadas apenas para exibição de artefatos.

Com o advento do AJAX6, o JavaScript começou a se comunicarcom o servidor e com isso passou a realizar tarefas mais importantesnas aplicações web. Atualmente é raro encontrar aplicações quenão utilizem JavaScript para funcionar.

Devido a popularização da linguagem, algumas dificuldades dosdesenvolvedores começaram a ficar mais evidentes, como a neces-sidade de manipulação do DOM7 (Document Object Model) e dainteração do usuários através de eventos, por exemplo: o clique domouse. As funções já existentes não possuíam uma solução efici-ente para tais necessidades e começaram a surgir frameworks comoAngular, Vue e React que fornecem um caminho para suprir essasdificuldades.

2.1.1 Angular. AngularJS8, depois apenas Angular, foi criado em2010 por uma equipe de desenvolvedores da Google e foi o pioneirona popularização de frameworks em JavaScript. Ele surge focadono desenvolvimento de SPAs (Single Page Applications), com umaarquitetura MVC (Model-View-Controller), separando a lógica doaplicativo, lógica de exibição e modelos.

O Angular permite que o desenvolvedor possa estender o HTMLcriando novas tags que podem ser reutilizada em outra parte docódigo quando necessário. Outra característica importante que ficouconhecido por two-way data-bindings, vinculava o modelo como objeto JavaScript permitindo a atualização automática quandoacontecia mudança no HTML ou no próprio modelo.

2.2 VueVue9 é bastante parecido com Angular, foi criado por Evan Youdepois de trabalhar na Google utilizando Angular com o objetivode ser um framework mais simples de se utilizar e na redução donúmero de arquivos usados.

Na documentação oficial, Vue é definido como um frameworkprogressivo para construção de interfaces de usuário. Em suas últi-mas versões já apresenta uma abordagem baseada em componentese um DOM virtual de maneira similar ao React.

O DOM virtual é uma representação de um objeto DOM. Umobjeto DOM virtual possui as mesmas propriedades de um objetoDOM, no entanto manipulá-lo é muito mais rápido.

2.2.1 React. Na documentação oficial, React10 é definido comouma biblioteca JavaScript declarativa, eficiente e flexível para criarinterfaces com o usuário através de componentes.

React foi criado pelo Facebook e o primeiro framework a usarum DOM virtual. Em relação a sua estrutura, React não utiliza oconceito de MVC, sua visualização é representada como uma árvore

5https://en.wikipedia.org/wiki/JavaScript, último acesso em 29/03/20216https://en.wikipedia.org/wiki/Ajax_(programming), último acesso em 29/03/20217https://en.wikipedia.org/wiki/Document_Object_Model, último acesso em 29/03/20218https://en.wikipedia.org/wiki/AngularJS9https://vuejs.org/, último acesso em 29/03/202110https://reactjs.org/, último acesso em 29/03/2021

de entidades chamadas componentes que podem ser compostos deoutros componentes.

2.3 Desenvolvimento para aplicações móveisDepois de dominar o mundo da web, o JavaScript começou a serutilizado como uma alternativa para lidar com o desenvolvimentomultiplataforma em dispositivos móveis. Aplicativos híbridos, comoficou conhecido, é a combinação de tecnologias da web comoHTML,o próprio JavaScript e CSS, Cascading Style Sheets, para construçãode aplicativos móveis.

Os aplicativos híbridos são hospedados em uma aplicação nativaexecutando em cima de uma WebView, que é o nome dado aobrowser encapsulado dentro da aplicação. Isso permite o acesso aosrecursos do dispositivo como câmera, contatos, geolocalização etc.A Figura 1 apresenta uma abstração da arquitetura de um aplicativohíbrido.

Figura 1: Abstração da arquitetura de uma aplicação híbrida

Assim como ocorreu na web, começaram a surgir frameworksJavaScript focados no desenvolvimento de aplicações híbridas comoo PhoneGap/Apache Cordova entregando um conjunto de pluginsque auxiliam o acesso aos recursos do aparelho. O PhoneGap11foi criado em 2009 pela empresa Nitobi, porém em 2011 a Adobecomprou a empresa e doou o código para o projeto Apache. Depoisdesse acontecimento, nasceu o Apache Cordova12 projeto opensource mantido por sua comunidade.

A principal limitação de uma aplicação híbrida é quando se falaem performance. Atualmente a abordagem híbrida não consegueser tão performática que uma aplicação nativa, justamente pelo fatodo poder de renderização da WebView. Quando falo em aplicaçõesnativas significa que o desenvolvimento da aplicação foi realizadocom a linguagem de programação padrão do SDK (Software Develo-per’s Kit) do dispositivo. No caso do Android temos o Java e, maisrecentemente, Kotlin e para iOS temos o Objective-C e Swift.

Todavia, a aplicação híbrida possui como maior ponto positivo acapacidade de, através de um único código fonte, entregar a apli-cação em múltiplas plataformas, trazendo consigo uma série debenefícios como: velocidade de desenvolvimento e facilidade demanutenção do código.11https://phonegap.com/, último acesso em 29/03/202112https://cordova.apache.org/, último acesso em 29/03/2021

Integração e Entrega Contínua para aplicações móveis desenvolvidas em React Native TCC BSI ’18, Dezembro, 2018, Recife, PE

Diante desse cenário, temos o surgimento do React Native comouma solução que consegue melhorar o problema de performanceda aplicação híbrida e mantém a prática de, através de um únicocódigo, entregar a aplicação nas principais plataformas móveis.

2.3.1 React Native. O React Native [Facebook 2020], assim como oReact, foi criado e é mantido pelo Facebook. React Native utilizao mesmo design do React, permitindo compor ricas interfaces deusuário a partir de componentes declarativos.

Com React Native, você não cria um aplicativo híbrido utilizandoas ferramentas oriundas da web, no entanto é possível criar umaplicativo móvel real que é indistinguível de um aplicativo nativo,pois ele usa os mesmos blocos de construção fundamentais da in-terface do usuário dos aplicativos iOS e Android comuns. Diferentede ferramentas como PhoneGap/Apache Cordova que executa oJavaScript e permitir sua interação com recursos nativos, o ReactNative compila o JavaScript ao código nativo, explicando assimcomo ele consegue melhorar a performance da aplicação. A Figura2 apresenta uma abstração da arquitetura do React Native. ReactNative vem crescendo junto com sua comunidade e sendo adotadopor grandes empresas como: Instagram, Uber e o próprio Facebook.

Figura 2: Abstração da arquitetura de uma aplicação em Re-act Native

Os principais problemas associados ao React Native são de ge-renciamento de configuração, dependências e testes. Por ser apenasum código, na teoria se um teste passou no ambiente iOS, podemosassumir que o teste também passará no ambiente Android. Na maio-ria dos casos o cenário descrito acima é verídico, que é testemunhodo poder do React Native, porém existem exceções suficientes paracausar problemas no ciclo de controle e garantia de qualidade doaplicativo, como por exemplo: bibliotecas que funcionam bem paraiOS, porém não no Android.

Diante desse cenário, uma abordagem para solucionar tais pro-blemas é o desenvolvimento e utilização de uma pipeline DevOps.DevOps se propõe a resolver esse problema combinando a mudançacultural com a automação de entrega de software com objetivode garantir lançamentos de software frequentes, previsíveis e semerros.

2.4 DevOpsDevOps é um conjunto de práticas destinadas a reduzir o tempoentre fazer uma alteração em um sistema e a mudança ser colocadaem produção normal, garantindo alta qualidade [Bass et al. 2015].

DevOps surgiu na engenharia de software com ênfase em co-laboração, automação e utilização de ferramentas como ponte decomunicação entre as atividades de desenvolvimento e operações,em resposta a crescente utilização das metodologias ágeis e ao au-mento da demanda de produção de aplicativos de software, quenecessitavam de entregas rápidas, contínuas e com mais qualidade.A Figura 3 apresenta uma abstração de uma pipeline DevOps.

Figura 3: Abstração de uma pipeline DevOps

DevOps se inclui área emergente de pesquisa e prática chamadade Engenharia de Software Contínua. Essa área refere-se ao desen-volvimento, implantação e obtenção de feedback rápido do softwaree do cliente em um ciclo muito rápido [Bosch 2014; Fitzgerald andStol 2017]. Engenharia de Software Contínua envolve três fases:Estratégia de Negócio e Planejamento, Desenvolvimento e Opera-ções. Para este estudo iremos focar nas atividades relacionadas afase de Desenvolvimento: Integração contínua, Entrega contínua eImplantação contínua. A Figura 4 apresenta o relacionamento entreessas atividades.

Figura 4: Relacionamento entre integração contínua, en-trega contínua e implantação contínua [Shahin et al. 2017]

2.4.1 Integração contínua. Integração contínua é um conjunto depráticas de desenvolvimento de software, no qual os desenvolve-dores publicam regularmente as alterações em seus códigos com opropósito de reduzir o tempo para disponibilizar novas atualizaçõesno software [Fowler 2006].

Martin Fowler define integração contínua como: “uma práticade desenvolvimento de software em que os membros de uma equipe

TCC BSI ’18, Dezembro, 2018, Recife, PE Souza Neto e Garcia

integram seu trabalho com frequência, geralmente cada pessoa rea-liza pelo menos uma integração diariamente - levando a múltiplasintegrações por dia. Cada integração é verificada por uma compilaçãoautomatizada (incluindo teste) para detectar erros de integração omais rápido possível” [Fowler 2006].

A utilização dessa prática permite que as empresas de softwaretenham um ciclo de lançamento mais curto e frequente, melhorem aqualidade do software e aumentem a produtividade de suas equipes.Esta prática inclui a construção de um servidor com uma ferramentade integração contínua como o Jenkins e implementação de testesautomatizado.

2.4.2 Entrega contínua. Segundo [Humble and Farley 2010], en-trega contínua é a capacidade de obter mudanças de todos os tipos- incluindo novos recursos, alterações de configuração, correçõesde erros e experimentos - na produção ou nas mãos dos usuários,com segurança e rapidez de maneira sustentável.

Entrega contínua nasce com o objetivo de substituir o processo deentrega de software tradicional e tal prática é possível garantindoum bom processo de integração contínua, deixando o softwareem um estado entregável após cada mudança efetivada [Weberet al. 2016] após passar com sucesso em testes automatizados everificações de qualidade.

De acordo com [Chen 2015], esta prática oferece bastante be-nefícios como como redução do risco de implantação, redução decustos, aumento da satisfação do usuário, produtividade e eficiência.Conforme apresentado na Figura 4 esta prática tem como requisitoa utilização de integração contínua.

2.4.3 Implantação contínua. Implantação Contínua é uma práticade desenvolvimento de software na qual cada alteração de códigopassa por toda a pipeline e é colocada em produção, automatica-mente.

Não existe um consenso no meio acadêmico sobre a definição ediferença entre Entrega contínua e Implantação contínua [Fitzgeraldand Stol 2017], no entanto é importante ressaltar que a práticade Implantação contínua implica obrigatoriamente na prática deEntrega contínua, mas o inverso não é verdadeiro [Humble 2010].

A principal diferença entre Entrega contínua e Implantação contí-nua está no momento da entrega do software. Na Entrega contínua,seu software estará sempre em um estado entregável após as mu-danças efetivadas, porém o momento de distribuição para o clientefinal é um passo manual, ou seja, uma decisão de negócio. No en-tanto, conforme apresentado na Figura 5, na Implantação contínuao processo é totalmente automatizado.

2.5 DiscussãoNesta Seção foi apresentado todo um contexto teórico e tecnológicopara termos uma noção sobre os benefícios e desafios associados àimplantação de uma pipeline DevOps.

A próxima Seção apresenta como foi realizado o desenvolvimentodo aplicativo bem como a implementação de seus testes.

3 IMPLEMENTAÇÃO DA PROPOSTANesta seção é apresentada a escolha pela tecnologia adotada para odesenvolvimento do aplicativo, bem como sua implementação e osscripts de testes elaborados para o propósito deste estudo.

Figura 5: Diferença entre Entrega contínua e Implantaçãocontínua [Humble 2010]

3.1 Tecnologia adotadaConforme apresentado na Seção 2.1, na Seção de conceitos básicos,React Native é uma biblioteca para construção de aplicativos móveis.Pelo fato desta tecnologia ter JavaScript em seu núcleo, é muito maisfácil encontrar desenvolvedores em comparação a outras linguagenscomo Swift ou Kotlin.

A Stack Overflow , maior comunidade online de desenvolvedoresdo mundo, publica todo ano um survey apresentando um conso-lidado das respostas de seus usuários sobre vários temas, desdetecnologias favoritas até preferências de trabalho. No seu survey[Stack Overflow 2018] publicado neste ano de 2018, JavaScript atin-giu a marca de linguagem de programação mais popular do mundopelo sexto ano consecutivo. O survey publicado em 2016 [StackOverflow 2016] apontou React como a principal tendência tecno-lógica no contexto de desenvolvimento como ilustrado na Figura6, a confirmação desta tendência está presente no survey desteano no qual React aparece na terceira colocação na categoria deFrameworks, Libraries and Tools mais utilizada atualmente.

Figura 6: Alteração na parcela de votos do Stack Overflowentre janeiro de 2015 e janeiro de 2016 [StackOverflow 2016]

Integração e Entrega Contínua para aplicações móveis desenvolvidas em React Native TCC BSI ’18, Dezembro, 2018, Recife, PE

3.2 Implementação dos testesBrian Marick, em uma série de posts13, fez uma classificação detestes de software em uma forma chamada The Marick Test Matrix.De acordo com Marick, podemos dividir a área de testes em quatrotipos, são elas: testes de aceitação, unitário, exploratório e nãofuncional.

Neste estudo, para atender o objetivo, focamos na implementaçãoapenas dos testes de aceitação que representa requisitos funcionaisvistos da perspectiva de negócio. Geralmente, esse tipo de teste, éescrito na forma de histórias de usuários exemplificando como osoftware deve funcionar. O aplicativo desenvolvido para este estudo,consiste em uma listagem de professores e para o mesmo foramdefinidos duas histórias de usuários:

• Como usuário, eu quero visualizar a lista de professores• Como usuário, eu quero visualizar os detalhes de um profes-sor

Os testes presentes na Figura 7 foram implementados utilizandoa ferramenta open source Calabash14 em sua versão 0.9.7. Calabashpermite a escrita e execução de testes de aceitação automatizadosde aplicativos móveis. Ele consiste em uma biblioteca que permiteo código de teste interagir com o aplicativo simulando ações dousuário final.

Figura 7: Código do teste de aceitação

As palavras reservadas Given, When e Then são expressões doCucumber15, ferramenta que permite a utilização de linguagemnatural para expressar o comportamento do usuário ao utilizar oaplicativo. No trecho de código abaixo estamos descrevendo a açãodo usuário de abrir a aplicação.Given(/^the app has launched$/) do

wait_for do!query("*").empty?

endend

No entanto, as expressões wait_for, query, sleep, touch ewait_for_element_exists são palavras reservadas do Calabash13https://codegardener.com/tag/Brian%20Marick, último acesso em 29/03/202114https://calaba.sh/, último acesso em 29/03/202115https://cucumber.io/, último acesso em 29/03/2021

responsáveis por simular as ações do usuário interagindo com aaplicação. No trecho de código abaixo estamos simulando a açãode clique do usuário em um item da listagem de professores.

When("I press some teacher") dotouch("* marked:'TeacherItem' index:0")sleep(2)

end

3.3 Implementação do aplicativoApós a definição das histórias de usuários e a elaboração dos casosde teste foi iniciado a fase de implementação do aplicativo em ReactNative na versão 0.55.2. A Figura 8 apresenta o código e a tela delistagem dos professores e a Figura 9 apresenta o código e a tela dedetalhe de professor. Todo código desenvolvido está disponível emum repositório público16 no Github.

Figura 8: Código e a tela de listagem de professores

O trecho de código abaixo ilustra a classe responsável pela telade listagem dos professores.

3.4 DiscussãoNesta Seção foi apresentada a justificativa da tecnologia adotada,a implementação dos testes e o desenvolvimento do aplicativo emReact Native que será utilizado na pipeline DevOps.

A implementação do aplicativo foi importante para sentir as difi-culdades de um desenvolvedor React Native com o gerenciamentode versões de dependências, compreender o motivo pelo qual Reacté o framework JavaScript mais utilizado atualmente e entender asdificuldades e limitações das ferramentas disponíveis para testaresse tipo de aplicação.

A próxima Seção apresenta como foi o passo a passo do processode construção da pipeline de integração e entrega contínua.

16https://github.com/pedrojsn96/intro-react/tree/master/TeachersProject, últimoacesso em 29/03/2021

TCC BSI ’18, Dezembro, 2018, Recife, PE Souza Neto e Garcia

Figura 9: Código e tela do detalhe de professor

4 A PIPELINE DE INTEGRAÇÃO E ENTREGACONTÍNUA PARA APLICAÇÕES MÓVEISDESENVOLVIDAS EM REACT NATIVE

Rafał Leszko [Leszko 2017] apresenta o conceito de pipeline como“uma sequência de operações automatizadas que geralmente repre-senta uma parte da entrega de software e o processo de garantia dequalidade”.

O sucesso da implantação de uma pipeline de integração e en-trega contínua não depende exclusivamente das ferramentas quevão ser utilizadas, mas principalmente da estrutura da organização,equipe de desenvolvimento e as suas práticas.

A pipeline pode variar de acordo com o aplicativo em questão,no sentido de possuir mais ou menos passos para atender a necessi-dade do mesmo. A Figura 10 apresenta a pipeline para o aplicativodesenvolvido neste estudo.

Figura 10: Pipeline desenvolvida para este trabalho

4.1 Configuração de ambienteNo processo de implementação de uma pipeline de integração eentrega contínua é necessário fazer uso de ferramentas para darsuporte ao controle de versionamento de código, automação debuild, automação de testes etc. Neste estudo utilizamos o Github17como ferramenta para versionamento de código, Jenkins na versão2.138.2 como servidor de integração contínua e o Gradle18 pararealização do build.

4.1.1 Jenkins. Na configuração do servidor Jenkins foram instala-dos os plugins Blue Ocean na versão 1.9.0, Slack Notification Pluginna versão 2.3, TestFairy Plugin na versão 4.16 e Github IntegrationPlugin na versão 0.2.4 para auxiliar na integração e comunicação en-tre o Jenkins e as demais aplicações utilizadas no desenvolvimentoda pipeline.

5 ESTRUTURA DA PIPELINEAo lidar com pipeline no Jenkins é preciso ter em mente dois ele-mentos: etapa e passo.

• Passo: É a operação mais básica, uma tarefa única onde sediz o que o Jenkins vai fazer. Por exemplo: executar um script.

• Etapa: É um conjunto de passos, dentro do mesmo contexto,que serão executados de maneira sequencial ou paralela. Porexemplo: sequência de scripts de configuração.

A Figura 11 apresenta uma visão geral da relação entre etapa epasso.

Figura 11: Estrutura de pipeline

5.1 JenkinsfilePara construção de pipeline no Jenkins é necessário escrever umarquivo de texto chamado de Jenkinsfile. Neste arquivo contéma declaração de todas as etapas e passos presentes na sua pipeline.

O Jenkinsfile fica na raiz do seu projeto sendo consideradocomo parte do desenvolvimento. Esta prática deu origem ao termo"pipeline-as-code" que trata a pipeline de integração e entrega contí-nua como parte do aplicativo que precisa ser versionado e revisado.

17https://github.com/, último acesso em 29/03/202118https://gradle.org/, último acesso em 29/03/2021

Integração e Entrega Contínua para aplicações móveis desenvolvidas em React Native TCC BSI ’18, Dezembro, 2018, Recife, PE

5.2 Poll SCM TriggerA primeira etapa é responsável por dar início a execução da pipe-line. Ela é acionada automaticamente, através de cron job19 queexecuta a cada doze horas de segunda a sexta verificando a exis-tência de alterações no repositório. Caso haja de novos commits norepositório, o processo de pipeline é iniciado.

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

5.3 SettingsA etapa de Settings contém duas sub-etapas chamadas de BUNDLEINSTALL e NPM INSTALL. Esta etapa é responsável pelo gerencia-mento das dependências do projeto. Durante a execução da pipelineas duas sub-etapas são executadas em paralelo.

A sub-etapa de BUNDLE INSTALL garante que todas as depen-dências necessárias para testar a aplicação estejam devidamenteinstaladas e versionadas. Enquanto a sub-etapa de NPM INSTALL rea-liza a instalação de todas as dependência, devidamente versionadas,que a aplicação necessita para funcionar corretamente.

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

19https://en.wikipedia.org/wiki/Cron, último acesso em 29/03/2021

5.4 Build Debug ModeEsta etapa é responsável por criar o build no modo de debug, nestemodo, por exemplo, é possível visualizar todos os erros e alertasgerados pela aplicação em tempo de execução.

Ainda nesta etapa, um arquivo apk (Android Application Package),é gerado sendo possível executar os cenários de testes na próximaetapa da pipeline. Para esse passo executamos um script que acionao Gradle, ferramenta responsável pelo build da aplicação conformeapresentado na Seção 4.1 Se alguma coisa der errado, a execução dapipeline é interrompida apresentando visualmente em qual passo oerro aconteceu, como ilustrado na Figura 12, caso contrário, seguirápara a próxima etapa.

Figura 12: Erro durante a execução da pipeline

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

5.5 Teste de AceitaçãoA etapa de Teste de Aceitação é a responsável por executar os testesdo aplicativo, apresentados na Seção 3.2. Esta etapa é importante,pois é ela que vai garantir a qualidade do software e decidirá se oaplicativo está pronto ou não para ser entregue para os usuários.Se acontecer erro em algum dos testes, a execução da pipeline éinterrompida, caso contrário, o aplicativo seguirá para próximaetapa.

Para esta etapa obter sucesso, existe a necessidade de possuir umdispositivo Android, configurado em modo de desenvolvimento,conectado via usb na máquina ou a utilização de um simulador An-droid. O aplicativo será instalado automaticamente no dispositivoe os testes serão executados no mesmo.

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

TCC BSI ’18, Dezembro, 2018, Recife, PE Souza Neto e Garcia

5.6 Build Release ModeEsta etapa tem a função de preparar o aplicativo para ser enviadopara Google Play Store20. O Android exige que todos os aplicativossejam assinados digitalmente com um certificado antes de poderemser distribuídos e instalados.

Para assinar digitalmente é necessário seguir a documentaçãooficial da plataforma21 e adicionar o certificado gerado ao seu có-digo, como pode ser visto na Figura 13. Dado que o certificado jáfoi devidamente inserido ao código, agora é possível gerar um buildno modo de release.

Para gerar o build no modo de release, executamos um script queaciona novamente o Gradle. Se ocorrer erro durante a execuçãodeste passo, a pipeline é interrompida, caso contrário, seguirá paraa próxima etapa.

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

5.7 EntregaA última etapa é responsável basicamente por uma tarefa: notifi-cação. No nosso caso, esta etapa notifica dois públicos distintos:o time de desenvolvimento e grupo de usuários que receberam oaplicativo para testar.

O time de desenvolvimento recebe o aviso através de um bot doJenkins em um canal no Slack indicando que a execução da pipelinefoi finalizada, conforme a Figura 14.

Por sua vez, o grupo de usuários recebe o aviso através de ume-mail contendo os devidos links para realização do download doaplicativo, conforme a Figura 15.

O bloco de código a seguir apresenta a parte do Jenkinsfileresponsável por esta etapa.

5.8 DiscussãoNesta Seção foi apresentado o conceito, a estrutura e a pipelinedesenvolvida para o estudo. Bem como as ferramentas utilizadaspara dar suporte a integração contínua, ao versionamento de có-digo, ao build e a entrega do aplicativo. É apresentado o detalhe decada etapa da pipeline explicando suas responsabilidades e funcio-namento.

20https://play.google.com/store, último acesso 29/03/202121https://facebook.github.io/react-native/docs/signed-apk-android, último acesso em29/03/2021

Figura 13: Assinatura do aplicativo para distribuição na lojaGoogle Play

A etapa que apresentou maior dificuldade de ser implementadafoi a de Testes de Aceitação, pelo fato da mesma ser responsável porgarantir a qualidade do software que será entregue para os usuáriose talvez seja um dos principais motivos para quebrar o processo deautomação do pipeline por completo. A Figura 16 apresenta todasas etapas da pipeline após a execução.

Integração e Entrega Contínua para aplicações móveis desenvolvidas em React Native TCC BSI ’18, Dezembro, 2018, Recife, PE

Figura 14: Notificação para o time de desenvolvimento

Figura 15: Notificação para o grupo de usuários

Figura 16: Todas as etapas da pipeline após a execução

A próxima Seção apresenta as conclusões, limitações e os traba-lhos futuros necessários para cobrir toda a fase de Desenvolvimentoda Engenharia de Software Contínua.

6 CONSIDERAÇÕES FINAISA construção de uma pipeline fornece um mecanismo para orga-nização do processo de desenvolvimento de software como umtodo, automatizando build e a maneira como o software é entreguepara o cliente. Com a popularização no uso de integração e entrega

contínua, a construção de pipelines estará presente no cotidiano detoda empresa de desenvolvimento nos próximos anos.

Com o desenvolvimento deste trabalho, foi possível provar commeios práticos e utilização de ferramentas testadas no mercado eamplamente conhecidas no ambiente organizacional que é tangívela utilização de integração e entrega contínua, altamente difundidano desenvolvimento web, agregando assim todos os benefícios jáconhecidos atrelados a utilização desta prática, para o ambiente dedesenvolvimento de aplicativos móveis.

6.1 Dificuldades e lições aprendidasNeste estudo a maior dificuldade encontrada foi que o React Nativepossui um conjunto limitado de ferramentas para realizar testes.Calabash, a ferramenta escolhida, possui uma pequena comunidadede usuários o que dificulta para encontrar soluções de possíveisproblemas e apresenta dificuldades para inspecionar e identificaros elementos na tela, para contornar esse problema é necessárioadicionar a propriedade do React Native accessibilityLabel, que éuma propriedade que torna os aplicativos acessíveis para pessoascom deficiências indicando que o elemento está visível para sermanipulado. Esta propriedade auxilia na busca por elementos pelasferramentas de testes, além de ser uma boa prática de desenvolvi-mento.

6.2 Trabalhos futuros e limitaçõesNeste estudo não foi realizado a implementação de testes unitáriose não foi aplicado uma ferramenta de Cobertura de Testes, na qualse exige uma porcentagem mínima de código coberto por teste paraum commit ser aceito e dar início a execução da pipeline. Ficamoslimitado ao ambiente Android, não foi possível incluir o processode build para iOS, bem como não foi implementado o passo daimplantação contínua responsável, no contexto de aplicação móvel,por publicar o aplicativo nas lojas.

Como principais atividades futuras esta implementação dos tes-tes unitários utilizando Jest22, ferramenta utilizada para testar apli-cações desenvolvidas em React, integrar ao pipeline a ferramentaFastlane23 para auxiliar na etapa de build da aplicação para o ambi-ente iOS e no processo de publicação tanto na Google Play Storequanto na Apple Store. Com essas atividades será possível cobrirtoda a fase de Desenvolvimento da Engenharia de Software Contí-nua.

REFERÊNCIASLen Bass, IngoWeber, and Liming Zhu. 2015. DevOps: A Software Architect’s Perspective.

Addison-Wesley, New York. http://my.safaribooksonline.com/9780134049847Jan Bosch. 2014. Continuous Software Engineering: An Introduction. Springer Internati-

onal Publishing, Cham, 3–13. https://doi.org/10.1007/978-3-319-11283-1_1Lianping Chen. 2015. Continuous Delivery: Huge Benefits, but Challenges Too.

IEEE Software 32, 2 (mar 2015), 50–54. https://doi.org/10.1109/MS.2015.27 ar-Xiv:arXiv:1011.1669v3

Lianping Chen. 2017. Continuous Delivery: Overcoming adoption challenges. Journalof Systems and Software 128 (jun 2017), 72–86. https://doi.org/10.1016/j.jss.2017.02.013

Christof Ebert, Gorka Gallardo, Josune Hernantes, and Nicolas Serrano. 2016. DevOps.IEEE Software 33, 3 (may 2016), 94–100. https://doi.org/10.1109/MS.2016.68

Facebook. 2020. React Native. https://github.com/facebook/react-native.

22https://jestjs.io/, último acesso em 29/03/202123https://fastlane.tools/, último acesso em 29/03/2021

TCC BSI ’18, Dezembro, 2018, Recife, PE Souza Neto e Garcia

Brian Fitzgerald and Klaas-Jan Stol. 2017. Continuous software engineering: A roadmapand agenda. Journal of Systems and Software 123 (jan 2017), 176–189. https://doi.org/10.1016/j.jss.2015.06.063

Martin Fowler. 2006. Continuous Integration. https://www.martinfowler.com/articles/continuousIntegration.html.

Jez Humble. 2010. Continuous Delivery vs Continuous Deployment.https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/.

Jez Humble and David Farley. 2010. Continuous Delivery: Reliable Software Relea-ses through Build, Test, and Deployment Automation (1st ed.). Addison-WesleyProfessional, Boston, MA.

Marie Jacksman. 2020. Continuous Integration Tools for Mobile vs Web. What’s theDifference? https://code-maze.com/ci-tools-for-mobile-apps/.

Sebastian Klepper, Stephan Krusche, Sebastian Peters, Bernd Bruegge, and LukasAlperowitz. 2015. Introducing Continuous Delivery of Mobile Apps in a CorporateEnvironment: A Case Study. In 2015 IEEE/ACM 2nd International Workshop on RapidContinuous Software Engineering. IEEE, Florence, Italy, 5–11. https://doi.org/10.1109/RCoSE.2015.9

Rafał Leszko. 2017. Continuous delivery with Docker and Jenkins : delivering software atscale. Packt Publishing, Birmingham, UK.

Steve Matyas Paul Duvall and and Andrew Glover. 2007. Continuous Integration:Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series(Fowler)). Addison-Wesley Professional, Boston, MA.

Mojtaba Shahin, Muhammad Ali Babar, and Liming Zhu. 2017. Continuous Integration,Delivery and Deployment: A Systematic Review on Approaches, Tools, Challengesand Practices. IEEE Access 5 (2017), 3909–3943. https://doi.org/10.1109/ACCESS.2017.2685629 arXiv:1703.07019

Stack Overflow. 2016. Developer Survey Results 2016. https://insights.stackoverflow.com/survey/2016.

Stack Overflow. 2018. Developer Survey Results 2018. https://insights.stackoverflow.com/survey/2018.

I. Weber, S. Nepal, and L. Zhu. 2016. Developing Dependable and Secure CloudApplications. IEEE Internet Computing 20, 3 (2016), 74–79. https://doi.org/10.1109/MIC.2016.67

Yangyang Zhao, Alexander Serebrenik, Yuming Zhou, Vladimir Filkov, and BogdanVasilescu. 2017. The impact of continuous integration on other software develop-ment practices: A large-scale empirical study. In 2017 32nd IEEE/ACM InternationalConference on Automated Software Engineering (ASE). IEEE, Urbana, IL, USA, 60–71.https://doi.org/10.1109/ASE.2017.8115619