You are on page 1of 183

ISBN

Impresso e PDF: 978-85-5519-219-7

EPUB: 978-85-5519-220-3

MOBI: 978-85-5519-221-0

Voc pode discutir sobre este livro no Frum da Casa do


Cdigo: http://forum.casadocodigo.com.br/.

Caso voc deseje submeter alguma errata ou sugesto, acesse


http://erratas.casadocodigo.com.br.
AGRADECIMENTOS
Agradeo minha bisav, Tereza (in memoriam), e minha av,
Iara, por estarem ao meu lado desde o meu primeiro dia de vida e
por me permitirem ser hoje um homem de bom carter, com
dignidade e ter sido premiado com uma educao de excelente
qualidade. Amo vocs!

Tambm gostaria de agradecer ao Instituto de Informtica da


Universidade Federal do Rio Grande do Sul (UFRGS), pela
excelente qualidade de ensino fornecida a mim durante a graduao.

Um agradecimento especial Casa do Cdigo. Ao Adriano


Almeida, por permitir a publicao deste material, e para a Vivian
Matsui, por me acompanhar nesta jornada com suas revises e
sugestes para que fizssemos um livro de boa qualidade. Muito
obrigado a vocs todos.

Por fim, gostaria de agradecer a voc, prezado leitor, por ter


adquirido este livro. Ele foi resultado de muita pesquisa,
experimentos e revises, de modo a lhe fornecer um material
diferenciado e que possa ser til em sua vida profissional.
SOBRE O AUTOR

Figura 1: Roger Silva

Desde 2012 com atuao no setor de TI, Engenheiro de


Software com forte experincia em desenvolvimento mobile. J
trabalhou tambm com desenvolvimento front-end, back-end e em
manuteno de software legado. Oficialmente certificado Scrum
Master (pela Scrum Alliance), apaixonado por trabalhar com todas
as correntes do Agile Scrum, Lean, Kanban e XP.

Bacharel em Cincia da Computao pela Universidade Federal


do Rio Grande do Sul (UFRGS), tambm blogueiro e palestrante
em eventos sobre tecnologia. Nas horas vagas, frequentador
assduo do estdio do seu time de corao, game manaco desde os
quatro anos de idade e viciado em happy hours.
Blog: http://www.orogersilva.com/

LinkedIn: https://br.linkedin.com/in/orogersilva
PREFCIO
Sua empresa ser a responsvel por desenvolver um novo app
Android para seu cliente. O arquiteto de software ser o
encarregado por dar o kick-off do projeto. Ele abre o Android
Studio, cria um novo projeto, nomeia-o, redefine seu nome de
pacote, e define a API mnima suportada pelo app e plataformas-
alvo (telefone, tablet, Android Wear, TV, Android Auto etc). Ento,
hora de construir a aplicao! Na verdade, no. hora de consert-
la. Sim. Consert-la. Pois tido como premissa que todo novo
software est quebrado at que ele seja validado.

Em contrapartida ao modelo Waterfall, em que um novo


software tem suas funcionalidades somente validadas ao final do
ciclo de seu desenvolvimento, quem sabe valid-lo desde a escrita de
suas primeiras linhas de cdigo?

Mas at termos um prottipo funcional levar dias. O que


validaremos ento? A resposta simples: suas estruturas internas.
Desde o primeiro dia de desenvolvimento, se possvel.

De mtodos de instncia at contextos funcionais em nvel de


business, o app ter sua chance de ser validado. E no somente isso.
H a gerao de relatrios resultantes de anlises de suas estruturas
e publicao automatizada para o Google Play. Isso desde o
primeiro dia de implementao. Vrias vezes ao dia, caso desejado.

Esse contexto expressa o dia a dia de um time de


desenvolvimento que faz entrega contnua de seu software.
Validaes sendo realizadas o mais brevemente possvel,
publicaes do app para o cliente diversas vezes durante a semana, e
feedback antecipado sobre o estado atual do app da parte do cliente.
Isso no sonho. Isso realidade.
Desde a publicao do livro Continuous Delivery Reliable
Software Releases Through Build, Test, And Deployment
Automation, de Jez Humble e David Farley, muito foi discutido
sobre o assunto. Porm, um vcuo literrio ainda persistia.

Como fazer entrega contnua de aplicaes mobile? Mais


especificamente, apps Android. Trata-se de um contexto peculiar.
Apps so publicados para o Google Play (ou para outras plataformas
de distribuio). Alguns tipos de testes requerem um dispositivo
para suas execues. Assim, a comunidade de desenvolvimento
mobile merecia uma publicao como esta para solucionar essas
questes.

A quem este livro se destina?


Voc desenvolvedor mobile Android? Esta publicao ser
muito bem-vinda a voc. Voc desenvolvedor mobile iOS?
Arrisco-me a dizer que tambm lhe ser muito til. Pois muitas
ideias retratadas aqui so compartilhadas entre as duas plataformas
mobile. O que diferir sero as tecnologias.

Voc profissional de TI, no necessariamente um


desenvolvedor? Este livro tambm far de voc um profissional
melhor, pois, alm da parte terica sobre os conceitos de integrao,
entrega e deployment contnuo, sero expostos como esses
conceitos so colocados em prtica.

Porm, esta publicao direcionada no somente para


profissionais, como tambm para estudantes. Apesar de no ser
voltada para calouros, o contato com o contedo deste livro permite
com que esse pblico esteja a par do que o mercado de produo de
software de alta qualidade demanda de seus profissionais.

O nico requisito tcnico recomendado para a leitura deste livro


o conhecimento bsico de programao em Java, tal que facilite a
compreenso do leitor sobre o funcionamento de testes
automatizados para apps Android.
Casa do Cdigo Sumrio

Sumrio

1 Primeiros passos e definies 1


1.1 O problema 2
1.2 Pipeline de deployment 4
1.3 Integrao contnua 13
1.4 Entrega contnua x Deployment contnuo 16
1.5 O caso de estudo 18

2 Gerenciamento de branches 21
2.1 Gerenciando branches em um contexto com integrao
contnua 22
2.2 Estratgias de branching 24

3 Testes automatizados 35
3.1 O que um teste automatizado? 36
3.2 Testes unitrios 43
3.3 Anlise esttica de cdigo 51
3.4 Testes de integrao 60
3.5 Testes de integrao em Android 63
3.6 Testes funcionais 71

4 Ferramentas para integrao e entrega contnua 77


4.1 Travis CI 79
Sumrio Casa do Cdigo

4.2 GoCD 86
4.3 Jenkins 98
4.4 Comparao entre ferramentas 122
4.5 Publicao no Google Play 127

5 Distribuies over-the-air 140


5.1 O conceito 140
5.2 Requisitos para atualizaes OTA 143
5.3 HockeyApp 144
5.4 Crashlytics 157
5.5 Concluso 169

6 Bibliografia 171
CAPTULO 1

PRIMEIROS PASSOS E
DEFINIES

Concepo, projeto, desenvolvimento, testes, todas essas etapas


so algumas das fases que constituem a construo de um novo
software. A literatura que aborda essas fases vasta e em constante
atualizao de acordo com novas ideias e tecnologias que surgem
com o passar dos dias.

Porm, a fase determinante durante o ciclo de vida de aplicao


sofre pela escassez de literatura, e de suma importncia para a
qualidade e manuteno do software sob desenvolvimento: a fase de
entrega. A escolha pela forma de entrega do software ao(s) cliente(s)
fundamental. Mas o que a entrega? Pode ser empacotar o
software, armazen-lo em um disco e enviar ao cliente em um
envelope pelo correio? Sim, pode! E envi-lo por e-mail tambm vale?
Claro! Porm, so mecanismos arcaicos (para no dizer coisa pior).
Existem formas muito mais adequadas e corretas.

Se j no bastasse a escassez literria sobre entrega de software, o


cenrio ainda mais obscuro quando falamos sobre entrega de
software mobile. O contexto de entrega nesse cenrio tem suas
particularidades. Ainda mais se considerarmos que a fase de entrega
pode ser dependente de outros elementos, tais como a estratgia de
gerenciamento de branches no controle de verso e a execuo de
testes automatizados.

1 PRIMEIROS PASSOS E DEFINIES 1


Por exemplo, um processo de entrega automatizado evita a falha
humana, uma vez que esta possvel de ocorrer durante o
gerenciamento da configurao, preparao dos dados ou escolha
dos passos para construo do artefato de software. Realizar
entregas frequentes de funcionalidades, to logo estejam
implementadas, permite o imediato feedback do cliente, de modo
que melhorias possam ser realizadas para a prxima entrega.
Validar o software atravs de testes automatizados primordial
(apesar de testes manuais exploratrios terem tambm a sua
importncia). Porm, no simples.

De modo a desmistificar a automatizao de testes sobre


aplicativos Android, o captulo 3 desta publicao tratar mais sobre
cada categoria de testes, e as ferramentas utilizadas para a
implementao dos testes pertencentes a cada uma delas.

A entrega de um aplicativo mobile


A obra tida como referncia sobre o assunto o livro
Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation, de Jez Humble e David Farley. Apesar
de ser um excelente livro, ele no retrata alguns dos problemas com
que nos deparamos ao entregar software para plataformas mobile.

Por exemplo, como automatizar a distribuio do app para o


Google Play? Como executar testes automatizados sobre as
funcionalidades do app, sendo que eles necessitam de interao com
a interface grfica e, portanto, necessrio um dispositivo fsico ou
um emulador? Como disponibilizar o app para a equipe de testes,
em vrios dispositivos, de modo que o app possa ser validado
manualmente? E o principal, como tratar todos esses requisitos de
modo que, quando um desenvolvedor comitar seu cdigo-fonte
para um repositrio de cdigo remoto, uma bateria de testes
automatizados seja executada, acompanhada por uma anlise de

1.1 O PROBLEMA 3
cobertura de cdigo-fonte, verificaes de regras de negcios e, por
fim, pela distribuio automatizada do app para o Google Play? So
respostas para esses tipos de problemas que este livro traz.

1.2 PIPELINE DE DEPLOYMENT


O pipeline de deployment uma implementao automatizada
dos processos de build, deploy, testes e release de um software.

O BUILD o processo de construo do software, efetuado


atravs de arquivos de cdigos-fonte, bibliotecas e outros
artefatos de software auxiliares. J um deploy a gerao
resultante de um processo de build, ou seja, o artefato do
software construdo.

Os testes so as validaes realizadas sobre o artefato de


software de forma automatizada e no automatizada. Por fim,
o processo de release a disponibilizao do software ao
pblico geral ou a um grupo de usurios pr-selecionados.

Ou seja, por um pipeline de deployment, uma vez que um


desenvolvedor comitar alteraes do cdigo-fonte de uma aplicao
para o repositrio de cdigo, ao final do pipeline poder estar
disponvel uma verso da aplicao validada por seus testes e, at,
ser entregue ao(s) cliente(s) de forma automatizada. Um possvel
pipeline de deployment mostrado a seguir:

Figura 1.1: Pipeline de deployment

4 1.2 PIPELINE DE DEPLOYMENT


Estgio de commit
Assim que h um commit para o repositrio da aplicao, o
pipeline de deployment pode ser notificado sobre alteraes na
aplicao trabalhada. Feita essa notificao, o cdigo-fonte, assim
como os demais recursos que compem a aplicao, so
direcionados ao primeiro estgio do pipeline deployment, tambm
chamado de estgio de commit. Esse estgio, composto pelas
seguintes subetapas:

Figura 1.2: Estgio de commit

A fase de compilao aqui pode ser entendida como o incio do


processo de build (construo) da aplicao. E por que incio? Ao
executar o build para um aplicativo Android, o Gradle (sistema de
build usado para construir apps Android) formado por passos de
build. Dentre os passos que compem o build como um todo, esto
aqueles responsveis por executar os testes unitrios, anlise esttica
de cdigo e empacotamento da aplicao. Sendo assim, todas as
subetapas citadas definem o build como um todo.

A prxima etapa executa testes unitrios contra a aplicao.

1.2 PIPELINE DE DEPLOYMENT 5


de tipo de um tipo genrico:

Figura 1.4: Conveno de cdigo no adotada

Aps executar a ferramenta de anlise de cdigo, reportado o


seguinte resultado:

Figura 1.5: Resultado da anlise esttica de cdigo

Existem muitos outros pontos de ateno ao final de uma


anlise como essa. Mas afinal, essa uma subetapa crtica? Depende.
Depende dos requisitos da aplicao a ser construda.

Uma anlise de cdigo automatizada no resolve


completamente o problema, mas serve como um timo suporte ao
alcance desse objetivo. A aplicao basicamente um MVP
(Minimum Viable Product), no crtica e contm funcionalidades
muito triviais? Talvez uma anlise esttica de cdigo no valha o
esforo nesse caso. Logo, essa subetapa, dependendo do contexto,
no obrigatria dentro de um pipeline de deployment. Mas
sempre bem-vinda.

Por fim, a subetapa de empacotamento trata de agrupar todos


os componentes resultantes do processo de build e gerar o arquivo
do aplicativo Android, formado pela extenso apk . A execuo de
validaes durante o estgio de commit no requer um emulador
Android. Isso muito importante.

O principal motivo para um processo de entrega contnua ser

1.2 PIPELINE DE DEPLOYMENT 7


dividido em etapas atravs de um pipeline de deployment
viabilizar rpido feedback. Testes automatizados no estgio de
commit so rpidos (preferencialmente, no podem levar mais do
que dez minutos para serem finalizados para uma grande aplicao).
Essa rapidez viabiliza ao time de desenvolvimento (e outros
stakeholders) ser notificado de que h algo errado e, se for o caso,
todos devem trabalhar juntos para que o build seja estabilizado.

Estgio de testes de integrao


A sada do estgio de commit (o arquivo executvel do
aplicativo Android) estar disponvel em uma pasta dentro do
ambiente do pipeline. Uma vez disponvel, ele ser usado como
entrada para o prximo estgio que, no pipeline esquematizado
neste captulo, o estgio de testes de integrao.

Como o prprio nome diz, esse um estgio responsvel por


testar a integrao. Mas integrao de qu? A integrao dos
componentes que compem o aplicativo Android. Em outras
palavras, ser verificado se as interaes entre os componentes do
aplicativo, dado um cenrio e dados de entrada, resultam em um
comportamento esperado.

Por exemplo, um teste de integrao vivel verificar se o


componente responsvel por gerenciar a persistncia de
informaes na base de dados interage de forma correta e esperada
com essa, como mostrada a seguir:

8 1.2 PIPELINE DE DEPLOYMENT


Estgio de testes funcionais
O prximo estgio do pipeline de deployment caracteriza-se por
tratar daquilo que o sistema como um todo faz. Ou seja, os casos de
teste pertencentes a esse estgio so baseados nas especificaes da
aplicao, por vezes definidas por um product owner ou um
membro do time de quality assurance (QA). Os testes
automatizados pertencentes a essa classe so chamados de testes
funcionais.

Devido ao fato de os critrios de aceitao de cada caso de uso


poderem ser especificados com a abordagem BDD (Behavior Driven
Development), uma boa prtica usar a descrio de cada critrio de
aceitao para nomear cada mtodo de teste funcional:

BDD no ser abordado neste livro, mas sugiro uma excelente


referncia, o livro User Stories Applied: For Agile Software
Development, de Mike Cohn (2004).

Figura 1.7: Critrio de aceitao

@Test
public void dadoQueNaoExistemAmigosAinda_quandoEuAdicionoUmNovoA
migo_entaoUmaNovaLinhaEhMostradaNaLista() {
// Implementao do mtodo de teste funcional deve vir aqui
}

Entretanto, devemos ter bom senso se essa prtica de nomeao

10 1.2 PIPELINE DE DEPLOYMENT


for levada ao p da letra. No exemplo mostrado, o nome do mtodo
muito longo. No entanto, o objetivo principal de qualquer nome
de mtodo expressar claramente sua responsabilidade. Como
trata-se de um mtodo de teste, o comprimento do nome do
mtodo ainda vlido, pois, aps a execuo de uma sute de testes
automatizados, em caso de falha na execuo de um mtodo de
teste, devido ao seu nome ser autoexplicativo, instantnea a
descoberta do contexto sob o qual o teste falhou. Porm, no
devemos exacerbar. necessrio bom senso sobre a deciso em
escolher usar essa prtica de nomeao ou no.

A execuo de testes funcionais em Android requer o uso de um


emulador e, por isso, so tambm chamados de testes peso-pesado
devido ao fato de poderem acessar recursos externos aplicao
(como base de dados, chamadas a APIs, comunicao
interprocessos), aos longos fluxos de execuo de cada mtodo de
teste. Afinal, cada mtodo corresponder a interao do usurio
com a aplicao atravs de um cenrio de caso de uso. Claro que
tambm so chamados assim devido a uma possvel lentido do
emulador Android. Logo, testes funcionais so caros, portanto,
prefervel implement-los em menor escala em relao a testes
unitrios, por exemplo.

Estgio de testes manuais


Finalizada mais uma etapa do pipeline de deployment, dado
incio a outra etapa, no automatizada, na qual os membros da
equipe de testes atuam sobre a aplicao. No estgio de testes
manuais, testadores podem realizar testes exploratrios, testes de
user experience, ou mesmo a validao dos critrios de aceitao de
casos de uso j validados no estgio de testes funcionais, com o
adicional de estressar a aplicao em cenrios mais complexos.

Por vezes, equipes responsveis pela construo de softwares

1.2 PIPELINE DE DEPLOYMENT 11


preferem suprimir esse estgio no processo de desenvolvimento
com o argumento de que automatizar todo processo de testes
atravs de um pipeline torna desnecessria a presena humana para
validaes manuais. Isso um erro. Testadores tm a viso e
habilidades que desenvolvedores no possuem. Eles sabem julgar e
explorar provveis fluxos de execuo que resultariam em erros na
execuo da aplicao.

Produo
O ambiente de produo mais conhecido para aplicativos
Android o Google Play. Ou seja, a loja oficial para publicao e
disponibilizao de aplicativos da plataforma Android. Porm, no
o nico.

Um aplicativo Android, aps a passagem pelo estgio de testes


manuais, pode ser despachado para dispositivos particulares de
usurios pr-selecionados. Esse tipo de distribuio conhecida
como over-the-air. Como exemplo de plataformas desse tipo,
podemos citar o Crashlytics e o HockeyApp, que sero abordados
nos captulos seguintes.

O app tambm pode distribudo atravs do site da companhia


proprietria da aplicao. O WhatsApp adota essa prtica, a qual
permite a seus usurios realizarem o download de verses beta da
aplicao ainda no publicadas no Google Play.

12 1.2 PIPELINE DE DEPLOYMENT


Figura 1.8: Distribuio de aplicativo no site

Tal qual faz o WhatsApp, possvel distribuir um app para um


grupo de usurios pr-selecionados atravs do Google Play
Developer Console, plataforma para gerenciamento de apps
publicados no Google Play e de suas informaes. Esse tipo de
distribuio, tambm conhecida como distribuio beta, precede a
publicao do app no Google Play ao pblico geral, de modo que
feedback sobre o app possa ser coletado de um grupo de usurios, o
app melhorado e, em seguida, distribudo oficialmente no Google
Play.

1.3 INTEGRAO CONTNUA


Ao construir um novo software, ele estar quebrado at que se
prove o contrrio. No recomendado validar funcionalidades da
aplicao somente quando elas estiverem prximas de estarem
prontas, pois postergar a fase de testes encarece o desenvolvimento
da aplicao e de sua manuteno em longo prazo. Isso se deve ao

1.3 INTEGRAO CONTNUA 13


fato de muitas das estruturas da aplicao j terem sido
implementadas at sua quase finalizao. Um teste que encontra
uma falha no contexto em que a fase de testes postergada para o
final do ciclo de desenvolvimento torna modificaes mais
trabalhosas de serem realizadas.

Uma boa estratgia para demonstrar a corretude de uma


aplicao desde o incio de seu ciclo de desenvolvimento atravs
de testes unitrios. Isso porque eles atuam sobre componentes
individuais que formam a arquitetura da aplicao de forma que o
software ser devidamente validado desde suas menores estruturas
at as maiores.

Acompanhada de uma sute inicial de testes unitrios, para


manter o histrico de modificaes sobre o software sendo
construdo (dentre outras utilidades), necessrio o uso de uma
ferramenta de controle verso. Digamos que durante o
desenvolvimento da nova aplicao uma falha seja introduzida (no
propositalmente) pelo desenvolvedor, falha esta que no ocorria
anteriormente.

Logo, um ou mais dos testes unitrios falharo. Existem duas


atitudes a serem tomadas nesse caso: ou realizada manuteno
sobre o cdigo da aplicao, de modo que a regresso ocorrida seja
removida; ou, em caso de urgncia, pode ser realizado um rollback
do cdigo-fonte. Atravs de um sistema de controle de verso, o
rollback pode ser facilmente realizado, de forma controlada e
registrada.

Um build automatizado e executado em um curto perodo de


tempo permite que o time de desenvolvimento comite alteraes da
aplicao-alvo, de modo que sempre obtenha feedback sobre
possveis regresses rapidamente, para que a aplicao possa ser
consertada tambm mais rapidamente que o habitual.

14 1.3 INTEGRAO CONTNUA


Comitando modificaes sobre o software nesse contexto, to
continuamente quanto possvel, com o apoio de um sistema de
controle de verso, um build automatizado ea concordncia do time
em trabalhar sob esse regime viabilizam a prtica da integrao
contnua (continuous integration).

Diversos so os softwares que facilitam a adoo de integrao


contnua por parte de times de desenvolvimento. Tais softwares
podem ser chamados de ferramentas de integrao contnua. Dentre
as ferramentas disponveis podem ser citadas o Travis CI, Circle CI,
Jenkins, dentre outras.

Figura 1.9: Travis CI

Figura 1.10: Circle CI

1.3 INTEGRAO CONTNUA 15


processo de entrega, o app estar disponvel no Google play para
que usurios possam baix-lo em seus dispositivos mveis.

Figura 1.12: Deployment "push-button"

Sob essas condies, a entrega contnua (continuous delivery)


ocorre uma vez que um time de desenvolvimento assegura que
possam ser comitadas alteraes sobre o software e, aps validadas
por seus testes, entregues to frequentemente quanto possvel para o
ambiente de produo (em Android, para o Google Play) a qualquer
momento. Porm, o processo no ocorre em sua totalidade sempre
de forma automatizada, como mostra a figura a seguir:

Figura 1.13: Entrega contnua x Deployment contnuo

1.4 ENTREGA CONTNUA X DEPLOYMENT CONTNUO 17


mundo real atravs deste livro, ser usado como exemplo um app
Android com nome de Racha Conta. Seguem telas do aplicativo:

Figura 1.14: Racha Conta

O aplicativo auxilia o usurio a dividir a conta em um encontro


entre amigos. Mas isso no importante. O que realmente importa
o fato desse app ter sido desenvolvido desde sua concepo com o
auxlio de um pipeline de deployment.

A existncia de uma sute de testes dos mais variados tipos


possibilita com que o app escale arquiteturalmente, se necessrio, de
modo que um alto nmero de modificaes no cdigo-fonte da
aplicao no introduza regresses. Alm disso, o pipeline de
deployment foi projetado de forma a permitir deployment contnuo.
Ou seja, o desenvolvedor executa o comando git push... em sua
mquina e, aps alguns minutos, uma nova verso do Racha Conta
estar publicada no Google Play.

O cdigo-fonte do app Android Racha Conta pode ser


encontrado no GitHub: https://github.com/orogersilva/racha-
conta-android.

1.5 O CASO DE ESTUDO 19


20 1.5 O CASO DE ESTUDO
2.1 GERENCIANDO BRANCHES EM UM
CONTEXTO COM INTEGRAO CONTNUA
A adoo da prtica de integrao contnua recomenda que
todos os artefatos de um aplicativo em desenvolvimento sejam
comitados em uma nica branch, mais especificamente na branch
master. Isso porque o software sob essa branch ser continuamente
integrado aps cada commit de cada desenvolvedor.

Assim, o software estar sempre em um estado releasable. Ou


seja, aps passar por todos os estgios de um pipeline de integrao,
estar pronto para ser entregue ao cliente a qualquer momento.

A integrao contnua uma prtica. Requer muita disciplina da


parte do time de desenvolvimento. E, principalmente, o time precisa
ter conscincia do seguinte fato: caso o build no servidor de
integrao quebrar em decorrncia de um commit, o time deve
voltar todos os seus esforos em consert-lo, para, somente aps
esse conserto, retomar o processo de desenvolvimento de novas
features normalmente.

22 2.1 GERENCIANDO BRANCHES EM UM CONTEXTO COM INTEGRAO


CONTNUA
Figura 2.1: Build quebrado

A falta de experincia de alguns membros do time pode levar a


quebras frequentes do build, tornando o estado do software no
releasable. Isso faz parte do processo. Porm, uma vez quebrado,
todos no time, se necessrio, trabalharo para que a integrao seja
estabilizada. A maturidade do time e qualidade do software
desenvolvido dependem dessa postura.

A escolha pela adoo de mltiplas branches vivel. Porm, o


software no estar sob o contexto de integrao contnua, pois,
uma vez que uma nova branch for criada a partir da branch master,
seu merge para a linha de desenvolvimento principal pode levar
muito tempo. Em consequncia, isso resulta em uma chance alta de
conflitos no merge quando ele for realizado e, portanto, em uma
chance muita alta de quebra no build.

Dessa forma, a dificuldade de conserto do build ser maior, uma


vez que a feature trabalhada na branch dedicada levou muito tempo
para ser integrada linha principal de desenvolvimento.

2.1 GERENCIANDO BRANCHES EM UM CONTEXTO COM INTEGRAO CONTNUA


23
Porm, deve-se levar em considerao que cada contexto de
desenvolvimento tem as suas necessidades. Adaptaes devem ser
adotadas para supri-las. Por vezes, um app deve ser desenvolvido
com o uso de mltiplas branches. Assim, seguem possveis
abordagens para manter o controle sobre o histrico do software em
desenvolvimento.

2.2 ESTRATGIAS DE BRANCHING


A seguir, so descritas duas estratgias de gerenciamento de
branches para manter o histrico de um software durante seu ciclo
de vida. Ser dada prioridade a essas duas estratgias por serem
simples, predominantes durante a manuteno de projetos de
software e facilitarem a configurao de pipelines de deployment.

Desenvolvendo na master
O sistema de controle de verso conter uma nica branch: a
master. O cdigo comitado por todos os desenvolvedores estar
sobre a master.

24 2.2 ESTRATGIAS DE BRANCHING


Figura 2.2: Comitando na branch master

Trata-se da abordagem mais recomendada para a adoo da


prtica de integrao contnua. Isso porque, aps cada commit
realizado por desenvolvedores para o repositrio de cdigo remoto,
um build ser disparado pelo software de integrao contnua, de
modo que a aplicao seja construda e tenha suas funcionalidades
validadas.

2.2 ESTRATGIAS DE BRANCHING 25


isto , muitas integraes de pequenas modificaes sobre o
software.

Alm disso, manter verses customizadas de um mesmo app


(por exemplo, verses alfa/beta de testes e de produo) torna-se
uma tarefa um pouco mais complexa no impossvel, somente
mais custosa. Pelo fato de o mesmo cdigo estar sendo comitado
sobre a mesma branch, deve haver uma forma de comunicar ao
software de integrao contnua quando determinada alterao
sobre uma verso customizada do app deve ser construda de um
modo particular. Isso anula a caracterstica de simplicidade desse
modelo de branching e, por consequncia, faz-se melhor a escolha
por outro modelo.

Branching baseado em Gitflow


Gitflow trata-se de um modelo de branching criado por Vincent
Driessen, engenheiro e arteso de software holands. um modelo
multibranch em que cada branch tem seu nome previamente
definido pelo modelo, ou segue uma conveno pr-determinada
em que cada branch tem uma funo bem definida.

Ao iniciar um projeto para desenvolvimento de uma nova


aplicao, ser criada uma nova branch de nome develop a partir da
branch master. Esta sempre conter a ltima verso do software em
desenvolvimento.

28 2.2 ESTRATGIAS DE BRANCHING


Figura 2.6: Criao da branch develop

Todas as pequenas correes de bugs devem ser comitadas sobre


a branch develop sem a necessidade de criao de novas branches
para isso.

Uma vez que uma nova feature precise ser implementada, essa
ao no ser realizada na branch develop, pois, lembrando, a
develop somente conter a ltima verso comitada do software com
features completas ou com pequenas modificaes, tais como
bugfixes. Commits intermedirios de novas features no devem ser
realizados nessa branch.

Ento, uma vez sob esse contexto, deve ser criada uma nova
branch partindo da branch develop chamada de feature-branch. A
conveno para nomeao de uma nova feature-branch determina
que o nome da branch deve ser prefixado com a palavra-chave

2.2 ESTRATGIAS DE BRANCHING 29


feature seguido por um sufixo, como mostrado a seguir:

Figura 2.7: Feature branch

No caso da figura anterior, assim que a feature 123 esteja


completamente implementada, deve ser realizado o merge da
branch feature-123 em direo branch develop, fazendo com que a
branch develop tenha a ltima verso atualizada do software j com
a feature 123 implementada dentro de seu prximo pacote de
funcionalidades.

Quando for determinado que uma nova verso da aplicao


deve ser enviada ao cliente ou publicada no Google Play, por
exemplo, uma nova ramificao deve ser criada, de forma que seja
possvel configurar metadados da aplicao atravs dela, tais como
nmero da verso a ser publicada e configuraes secundrias. Essa
nova branch conhecida como release-branch.

30 2.2 ESTRATGIAS DE BRANCHING


Figura 2.8: Release branch

O nome da release branch deve ser prefixado com a palavra-


chave release, tal como no caso da figura anterior, onde a branch
nomeada como release-1.1, e o sufixo o prximo nmero de verso
da aplicao a ser distribuda. Porm, a nomeao do sufixo livre.

Assim que todos os tratamentos tenham sido realizados sobre


essa branch, deve ser realizado o seu merge em direo branch
master, a qual tambm conter uma nova tag marcando o nome da
verso resultante desse merge. Contudo, a branch de release
tambm deve ser mergeada para a branch develop, pois tido como
premissa que a branch develop sempre conter a ltima verso da
aplicao em desenvolvimento. Logo, a develop deve conter o
nmero de verso da aplicao atualizado tambm.

Digamos que exista uma verso j publicada da aplicao no


cliente. Ento descoberto um bug crtico nessa aplicao. Qual a

2.2 ESTRATGIAS DE BRANCHING 31


atitude a ser tomada? Nesse contexto, uma nova branch ser criada
a partir do ltimo commit realizado sobre a branch master, ou seja,
a partir da ltima verso publicada ao cliente. Essa branch
denominada hotfix-branch. Com nome prefixado com a palavra-
chave hotfix, a branch responsvel por conter commits que
consertam o bug encontrado em produo:

Figura 2.9: Hotfix branch

Tendo sido finalizadas todas as correes sobre o bug, a branch


de hotfix deve sofrer ao de um merge em direo branch master.
Mas no somente. Tambm deve ser mergeada em direo branch
develop. A no ser que exista uma branch release viva no sistema de
controle de verso, pois, como j mencionado anteriormente, a
branch release ser futuramente mergeada para a branch develop.

Somente as branches master e develop existem durante todo o


ciclo de vida da aplicao sob desenvolvimento. As feature-branches,
release-branches e hotfix-branches, uma vez que no tenham mais

32 2.2 ESTRATGIAS DE BRANCHING


Levando em considerao que, por dia, um time de
desenvolvimento de tamanho razovel pode comitar uma dezena de
vezes, uma dezena de validaes seriam realizadas. Manualmente?
Por qu? Elas podem muito bem ser automatizadas. E no prximo
captulo que ser mostrado como automatizar testes sobre apps
Android e atravs de quais ferramentas.

34 2.2 ESTRATGIAS DE BRANCHING


CAPTULO 3

TESTES AUTOMATIZADOS

As aplicaes devem ser testadas. Isso uma regra. E quando


falo "devem ser testadas", no me refiro somente a testes manuais
(que tambm tm a sua importncia), mas, principalmente, a testes
automatizados. Aplicaes no testadas no so confiveis,
encarecem o produto final e so de difcil manuteno. Logo, no h
escolha. Simplesmente teste.

E quando falamos sobre testar apps Android, a importncia


ainda maior, devido ao vasto ecossistema de dispositivos que
existem no mercado. Um aplicativo pode ser aprovado em todos os
testes automatizados em um dispositivo de um determinado
fabricante, porm reprovado em testes em um dispositivo de outro
fabricante. Ou seja, existem testes implementados e o aplicativo
ainda falha em um determinado contexto. Imagina se no
existissem.

Sob a tica de viabilizar a entrega contnua de um app Android,


testes automatizados so de fundamental importncia, pois eles
representam alguns dos estgios que formam um pipeline de
deployment. Em captulos anteriores, foi mencionado que o
primeiro estgio de um pipeline de deployment denominado
estgio de commit. Apesar de esse estgio conter as subetapas de
compilao e empacotamento, neste captulo, o pipeline de
deployment ser apresentado sem essas subetapas, de forma que
cada estgio do pipeline expresse uma categoria de teste
automatizado. Assim, as subetapas de testes unitrios e anlise

3 TESTES AUTOMATIZADOS 35
esttica de cdigo so desmembradas em dois novos estgios, como
mostrado a seguir:

Figura 3.1: Pipeline de deployment automatizado

Em relao ao modelo de pipeline de deployment proposto em


captulos anteriores, esse novo pipeline suprime o estgio de testes
manuais, para que o pipeline de deployment seja completamente
automatizado. Ou seja, uma vez que um desenvolvedor realize um
commit com modificaes sobre o aplicativo Android sob
desenvolvimento, e todos os testes de todos os estgios sejam
executados com correo, ao final do pipeline deve ser publicada
uma nova verso do app Android no Google Play automaticamente,
sem interveno humana.

Mas o que significa testes serem automatizados? Quais so seus


reais benefcios? Quais tipos de testes existem? Que ferramentas
podem ser usadas para executar esses testes contra um aplicativo
Android? O aplicativo precisa ser adaptado para poder ser testado?
As perguntas so muitas. Seguem suas respostas.

3.1 O QUE UM TESTE AUTOMATIZADO?


Um teste automatizado pode ser executado por um clique de
boto ou por um comando em um console, tal que, ao final da
execuo desse teste, o resultado produzido por ele seja comparado
a um resultado esperado. Caso ambos os resultados sejam iguais,
pode ser dito que a aplicao passou para aquele teste. Porm, caso
o resultado produzido seja diferente do esperado, a aplicao falhou

36 3.1 O QUE UM TESTE AUTOMATIZADO?


para aquele teste.

Figura 3.2: Teste executado com sucesso barra verde 1

Figura 3.3: Teste executado com sucesso barra verde 2

Figura 3.4: Teste executado com falha barra vermelha 1

Figura 3.5: Teste executado com falha barra vermelha 2

As imagens anteriores mostram duas execues do mesmo teste


contra um aplicativo Android atravs do Android Studio. Na
primeira, o teste passou. J na segunda, o teste falhou. interessante
notar a barra horizontal em verde e vermelho para o teste executado
com sucesso e com falha, respectivamente.

proposital a barra ocupar boa parte da tela, pois ela facilita a


visibilidade sobre o status atual de execuo dos testes. Em caso de
teste com falha, stakeholders sero facilmente notificados sobre algo

3.1 O QUE UM TESTE AUTOMATIZADO? 37


estar errado.

Alis, algumas empresas preferem reforar esse feedback atravs


de um monitor colocado em uma posio com boa visibilidade no
ambiente de trabalho do time de desenvolvimento (e de outras
partes interessadas). Ele dedicado a mostrar, dentre outras
informaes, resultados de testes automatizados executados contra
uma aplicao.

Figura 3.6: Feedback imediato

Uma pergunta pertinente: com a implementao de testes


automatizados, testes manuais so ainda necessrios? Para
responder a essa pergunta, outra ainda precisa ser respondida: "O
que um teste manual?". uma pessoa qualquer interagindo
aleatoriamente contra a aplicao-alvo tentando encontrar algum
bug?

Na verdade, completamente o contrrio disso. Um teste


manual um procedimento no qual um testador (com skills para

38 3.1 O QUE UM TESTE AUTOMATIZADO?


desenvolvedor. Ento, esse desenvolvedor olha para o seguinte
mtodo do app:
public void addFriend(Friend friend) {

if (friend == null) {
throw new NullPointerException();
}

mFriendDal.create(friend);
}

Ele pensa em voz alta: Hum, do meu ponto de vista, no parece


correto esse mtodo lanar um NullPointerException . Vou dar
um jeito nisso.
public void addFriend(Friend friend) {

if (friend == null) return;

mFriendDal.create(friend);
}

Bom, parece que o novo desenvolvedor est motivado e j quis


mostrar suas competncias. Entretanto, seu colega de trabalho
atualizou o cdigo-fonte da aplicao em sua mquina j com as
modificaes do novo desenvolvedor. Ento, ele resolve executar os
testes automatizados para verificar se algo est errado e...

Figura 3.8: Sute falhando testes

40 3.1 O QUE UM TESTE AUTOMATIZADO?


tambm o modo como est evoluindo a aplicao
arquiteturalmente. Assim, boa parte de reescrita da aplicao pode
ser evitada caso gaps de arquitetura sejam detectados
antecipadamente pela implementao de testes automatizados.

3.2 TESTES UNITRIOS

Figura 3.11: Estgio de testes unitrios

Testes unitrios testam a unidade. Bem, mas o que uma


unidade? Resumindo, uma unidade pode ser uma Activity , um
Fragment , um componente de acesso camada de dados, um
componente de acesso rede etc. Ou seja, so os menores
componentes testveis de uma aplicao.

Cada mtodo de teste unitrio deve atuar somente sobre uma


unidade de cada vez.

Figura 3.12: Mtodos de teste unitrios

Caso uma unidade dependa de outra, como test-las


separadamente? a que entra em cena os objetos mock. O mock

3.2 TESTES UNITRIOS 43


simular a unidade que a unidade dependente faz uso, o que
viabiliza a aplicao do teste unitrio.

Figura 3.13: Mock em testes unitrios

Uma vez apresentada a parte conceitual, vamos a um exemplo


prtico.

Mos obra
A seguir, sero abordadas estruturas do app Racha Conta, j
mencionado anteriormente, para exemplificar a implementao de
testes unitrios. Sero implementados testes unitrios para duas
classes: FriendBll e DeskActivity .

A primeira classe pertence camada de lgica de negcio e


contm operaes CRUD (Create-Retrieve-Update-Delete) sobre
objetos que representam usurios. A segunda classe contm a lgica
de gerenciamento da tela de lista de usurios.

Comeando pela classe FriendBll . Ela contm um mtodo


chamado getFriend :
public Friend getFriend(String name) {

Friend friend = null;

try {

44 3.2 TESTES UNITRIOS


if (StringUtils.isNullOrEmpty(name)) {
throw new InvalidStringException();
}

friend = mFriendDal.retrieve(name);

} catch (InvalidStringException e) {}

return friend;
}

Esse mtodo retorna um objeto do tipo Friend com todas as


informaes sobre um usurio, uma vez fornecido o seu nome. Esse
mtodo pode ser testado de diversas formas.

Por exemplo, caso o nome passado para getFriend seja nulo,


qual o resultado esperado a ser produzido por esse mtodo? De
acordo com o fluxo de execuo, o nome avaliado na expresso
condicional e disparado um InvalidStringException . O fluxo
de execuo segue pelo bloco catch e, por fim, atinge o comando
return . O valor do objeto friend nesse ponto ser nulo, pois,
desde que foi inicializado com esse valor, ele no foi alterado uma
vez sequer. Assim, um mtodo de teste correspondente a esse fluxo
ser definido.

O source set referente aos testes unitrios no projeto da aplicao


identificado por (test).

Figura 3.14: Source set para testes unitrios

Nesse source set criada a classe FriendBllTest , que ser a


classe responsvel por conter testes unitrios referente unidade
FriendBll .

3.2 TESTES UNITRIOS 45


O mtodo de teste que testa o fluxo mencionado anteriormente
:
@Test
public void getFriend_whenFriendNameIsNull_returnsNull() {

// ARRANGE
final String NULL_FRIEND_NAME = null;

// ACT
Friend gottenNullFriend = mFriendBll.getFriend(NULL_FRIEND_N
AME);

// ASSERT
assertNull(gottenNullFriend);
}

Todo mtodo de teste unitrio deve ser precedido por um


annotation @Test , de modo que o mtodo seja reconhecido como
um teste.

Um bom padro para nomeao de mtodos de teste unitrios


pode ser descrito como:
[nome do mtodo testado]_[condio]_[valor produzido pelo mtodo]

Mtodos devem ter bons nomes. Algum poderia perguntar:


Mas o nome do mtodo no est muito longo? Preferencialmente,
nomes de mtodos devem ser curtos. Porm, o principal o mtodo
expressar sua inteno. Se difcil encontrar um nome enxuto que
expresse a inteno do mtodo, no hesite: nomeie-o com um nome
longo. Seus colegas desenvolvedores (e voc mesmo) agradecero
futuramente.

O corpo do mtodo segue um pattern denominado Arrange-


Act-Assert (AAA). Ele auxilia a organizao do teste. A seo
Arrange contm todas as instrues necessrias para preparar a
invocao e definio de valor esperado a ser retornado pelo
mtodo sendo testado.
// ARRANGE

46 3.2 TESTES UNITRIOS


final String NULL_FRIEND_NAME = null;

A seo Act contm a invocao do mtodo sendo testado. O


valor retornado pelo mtodo deve ser armazenado para que esse
resultado seja verificado.
// ACT
Friend gottenNullFriend = mFriendBll.getFriend(NULL_FRIEND_NAM
E);

A seo Assert contm todo cdigo-fonte responsvel por


comparar o valor retornado pelo mtodo sob teste com um
resultado esperado, que, no caso desse teste, nulo.
// ASSERT
assertNull(gottenNullFriend);

Para executar o teste unitrio, pressione o cone assinalado na


figura a seguir:

Figura 3.15: Executando mtodo de teste

E como resultado do teste...

Figura 3.16: Resultado da execuo do mtodo de teste 1

3.2 TESTES UNITRIOS 47


Figura 3.17: Resultado da execuo do mtodo de teste 2

O resultado do teste com sucesso significa que, para o fluxo


coberto do mtodo testado, ele foi realizado com sucesso. Mas
somente para aquele fluxo. Logo, outros fluxos do mtodo
getFriend precisam ser cobertos.

Implementando outro mtodo de teste para cobrir outro fluxo


de getFriend :
@Test
public void getFriend_whenFriendNameIsValid_returnsFriend() {

// ARRANGE
final String FAILED_TEST_MESSAGE = "Objeto 'Friend' recupera
do deve ser igual ao objeto 'Friend' esperado.";

final String VALID_FRIEND_NAME = "Roger";


final double FRIEND_DEBT = 34.00;

Friend expectedFriend = new Friend(VALID_FRIEND_NAME, FRIEND


_DEBT);

when(mFriendDalMock.retrieve(VALID_FRIEND_NAME)).thenReturn(
expectedFriend);

// ACT
Friend gottenValidFriend = mFriendBll.getFriend(VALID_FRIEND
_NAME);

// ASSERT
assertEquals(FAILED_TEST_MESSAGE, expectedFriend, gottenVali
dFriend);
}

Esse mtodo de teste trata do fluxo (como dito em seu nome)


do cenrio em que, quando passado como parmetro um nome de
usurio vlido a getFriend , ser retornado um objeto Friend
com informaes completas sobre um usurio. Analisando o fluxo

48 3.2 TESTES UNITRIOS


de execuo de getFriend , no contexto sendo tratado, pode ser
visto que realizada uma invocao ao mtodo retrieve em um
objeto da classe FriendDal . Ou seja, dever ser usado um objeto
mock de FriendDal para simular uma invocao a retrieve ,
para que esse fluxo possa ser testado de forma unitria.

A classe FriendBll tem um construtor que recebe como


argumento um objeto FriendDal . Logo, FriendBll ser
instanciado recebendo como argumento um objeto mock de
FriendDal . Isso permitir unidade FriendBll ser testada de
forma isolada. A instanciao realizada desta forma:
@Before
public void setup() {

mFriendBll = new FriendBll(mFriendDalMock);


}

O mtodo setup precedido pela annotation @Before . Esta


determina que setup ser invocado antes da execuo de cada
mtodo de teste definido em FriendBllTest . Esse tratamento
realizado para que todas as pr-condies sejam atendidas para a
execuo de cada mtodo de teste a ser executado. O objeto mock
declarado precedendo o objeto-alvo com a annotation @Mock :
@Mock
FriendDal mFriendDalMock;

O mtodo de teste contm o seguinte comando na seo


Arrange:
when(mFriendDalMock).retrieve(VALID_FRIEND_NAME)).thenReturn(exp
ectedFriend);

Esse comando deve ser interpretado da seguinte forma: quando


o fluxo de execuo se deparar com uma chamada ao mtodo
retrieve de um objeto do tipo FriendDal , o valor retornado
por esse mtodo deve ser expectedFriend . O mtodo no ser
invocado. Ser realizado um "faz de conta". Isso permite com que

3.2 TESTES UNITRIOS 49


somente FriendBll esteja sendo testado pelo mtodo de teste.

Um outro estilo de teste unitrio pode ser implementado para a


unidade DeskActivity . Criamos a classe DeskActivityTest
para conter mtodos de teste para testar a classe DeskActivity .
Como DeskActivity gerencia a lgica de uma das telas do app,
dito que os testes implementados para essa classe so testes
unitrios de view.

Como eles so testes que exigem manipulaes de objetos de


classes presentes no Android SDK (Software Development Kit), ser
necessrio um Robolectric . Veja a seguir:
@SmallTest
@RunWith(RobolectricGradleTestRunner.class)
@Config(constants = BuildConfig.class, sdk = Build.VERSION_CODES
.LOLLIPOP)
public class DeskActivityTest {

O fluxo de execuo que ser tratado expresso pelo mtodo de


teste:
@Test
public void clickingOnFloatingActionButton_shouldStartDialog() {

// ARRANGE
FloatingActionButton addFriendFloatingActionButton = (Floa
tingActionButton) mDeskActivity.findViewbyId(R.id.desk_floatingact
ionbutton);

InputAddFriendDialog inputAddFriendDialog;

// ACT
addFriendFloatingActionButton.performClick();

inputAddFriendDialog = (InputAddFriendDialog) ShadowDialog


.getLatestDialog();

// ASSERT
assertTrue(inputAddFriendDialog.isShowing);
}

Ou seja, pressionado o boto para a adio de um novo usurio

50 3.2 TESTES UNITRIOS


na lista de usurios, a lgica de execuo deve iniciar um dilogo, ou
seja, uma janela para o preenchimento do nome desse novo usurio.
O dilogo no ser realmente iniciado. Robolectric somente
verifica se, caso ao pressionar o boto para a adio de um novo
usurio, o fluxo de execuo dispara uma chamada para a exibio
do dilogo InputAddFriendDialog , sem realmente exibi-lo de
fato.

Lembrando, no necessrio um emulador ou dispositivo fsico


para executar esse teste. O teste iniciado na JVM (Java Virtual
Machine). Isso viabiliza a eficincia do uso de TDD, por exemplo,
pois, como testes so executados com frequncia durante o perodo
de desenvolvimento, primordial a rapidez da sua execuo.

3.3 ANLISE ESTTICA DE CDIGO

Figura 3.18: Estgio de anlise esttica de cdigo

Existe outra categoria de testes que responsvel por: validar se


o estilo de escrita do cdigo-fonte condiz com o esperado; apontar
bad smells no cdigo que sejam indcios de ocorrncias de bugs no
aplicativo quando em execuo; e sinalizar outras medies de
qualidade de cdigo, tais como performance, usabilidade, corretude,
dentre outras. A categoria de testes automatizados por tratar dessas
questes denominada anlise esttica de cdigo.

A adoo do uso por tal categoria de testes deve ser mensurada.


Em projetos de baixa escala, com poucos membros no time de
desenvolvimento, talvez ela no se justifique, pois testes como esses

3.3 ANLISE ESTTICA DE CDIGO 51


tm pouco ROI (Return On Investment) sob esse contexto. Vale
mais a pena dedicar o esforo implementao de testes unitrios e
de integrao, por exemplo.

J em times com muitos membros, faz-se mais adequada a


adoo de anlise esttica de cdigo em projetos. Por haver
pluralidade de estilo de escrita de cdigo em grandes times, um
processo automatizado que trata de verificaes sobre a sade do
cdigo-fonte no somente recomendada, mas sim necessria.

H uma boa variedade de ferramentas que realiza esse tipo de


tratamento. Elas sero detalhadas a seguir. Porm, para fins de
organizao, ser adotada uma conveno para manter todas as
configuraes responsveis por tratar da anlise de cdigo.

As configuraes responsveis por tratar a anlise de cdigo


podem ser mantidas de diversas formas. Agora, mant-las de forma
organizada tornando-as de fcil manuteno sempre prefervel.
Logo, ser criado um folder config na raiz do projeto da aplicao
Android, onde todas as configuraes sobre qualidade de cdigo
sero mantidas.

Figura 3.19: Organizao de folders para anlise esttica de cdigo

Um subfolder quality ser tambm criado para manter


somente as configuraes de qualidade de cdigo. E dentro desse

52 3.3 ANLISE ESTTICA DE CDIGO


ltimo folder, so mantidas as configuraes de cada ferramenta de
anlise de cdigo adotada, assim como um arquivo Gradle que
conter a descrio de cada task responsvel por tratar cada tipo de
anlise.

Alm disso, deve ser adicionada no arquivo build.gradle , em


nvel de projeto, a aplicao de todas as tasks definidas em
quality.gradle :

Figura 3.20: Aplicao das configuraes para anlise de cdigo

Checkstyle
Trata-se de uma ferramenta que auxilia desenvolvedores a
manterem um padro de escrita do cdigo Java em seus projetos.

O sistema de build Gradle j contm a ferramenta Checkstyle.


Assim, basta ativ-la para que seja executada durante o build. Para
isso, no arquivo quality.gradle , aplique o plugin de Checkstyle.

Aplicao do plugin Checkstyle apply plugin:


'checkstyle'

Tambm, deve ser definida a task a ser executada quando for


lanado o Checkstyle, como mostrado a seguir:

3.3 ANLISE ESTTICA DE CDIGO 53


Figura 3.21: Task do Checkstyle

Para realizar a verificao com o Checkstyle, execute o seguinte


comando Gradle:

Gradle Windows gradlew.bat checkstyle

Gradle Linux ./gradlew checkstyle

Para exemplificar, digamos que o seguinte tipo genrico seja


descrito da seguinte forma:
private List< Friend > mFriends;

Ou seja, h espaos em branco na declarao desse tipo. Aps a


verificao do checkstyle , gerado um arquivo HTML contendo
o resultado da anlise. No caso desse exemplo, sinalizada a m
prtica de escrita de um tipo genrico com espaos em branco.

Figura 3.22: Report do Checkstyle

Findbugs

54 3.3 ANLISE ESTTICA DE CDIGO


uma ferramenta de anlise esttica que busca por bug patterns
em bytecodes Java. Ou seja, sobre arquivos .class , alm de indicar
potenciais problemas de segurana.

Assim como Checkstyle, Findbugs j includo no sistema de


build Gradle. Assim, deve-se aplicar seu plugin no
quality.gradle :

Aplicao do plugin Findbugs apply plugin:


'findbugs'

Tambm deve ser definida a task responsvel pelo modo como


deve ser configurado o Findbugs.

Figura 3.23: Task do Findbugs

3.3 ANLISE ESTTICA DE CDIGO 55


Para o uso dessa ferramenta, deve ser executada a seguinte task
do Gradle:

Gradle Windows gradlew.bat findbugs

Gradle Linux ./gradlew findbugs

PMD
Semelhante ferramenta Findbugs, porm analisa o cdigo-
fonte da aplicao, e no somente os bytecodes. Alm disso, PMD
no somente aplicvel linguagem Java, como tambm para
outras linguagens de programao.

Tal como as outras ferramentas j apresentadas, PMD includo


no sistema de build Gradle por padro. Basta a aplicao de seu
plugin em quality.gradle :

Aplicao do plugin PMD apply plugin: 'pmd'

Tambm, sua task dedicada deve ser declarada no mesmo


arquivo.

56 3.3 ANLISE ESTTICA DE CDIGO


Figura 3.24: Task do PMD

Para o acionamento da ferramenta, deve ser executado atravs


do console o seguinte comando Gradle:

Gradle Windows gradlew.bat pmd

Gradle Linux ./gradlew pmd

Com PMD, possvel realizar uma anlise mais criteriosa sobre


o cdigo-fonte em relao ferramenta Findbugs. Por exemplo, o
conhecido dilema do "abre-fecha chaves" em instrues
condicionais pode ser definido em sua configurao.

3.3 ANLISE ESTTICA DE CDIGO 57


Lint
Lint uma ferramenta de anlise esttica de cdigo voltada a
solues Android, que realiza validaes tais como corretude,
usabilidade, segurana, dentre outros atributos e, tambm, em
aspectos exclusivos de projetos Android, tais como a
obrigatoriedade da disposio de figuras de dimenses distintas em
seus respectivos folders drawable .

A seguir, veja as configuraes necessrias para a implantao


de Lint no arquivo quality.gradle :

Figura 3.25: Configuraes para o Lint

Para analisar o cdigo-fonte, deve ser disparada a task


relacionada ferramenta Lint na execuo do build Gradle.

Gradle Windows gradlew.bat lint

Gradle Linux ./gradlew lint

Uma pergunta pertinente: Mas por que tantas ferramentas se elas


servem para resolver o mesmo problema? Bom, algumas delas

58 3.3 ANLISE ESTTICA DE CDIGO


resolvem o mesmo problema. Porm, elas o fazem de diferentes
formas. Ou seja, elas se complementam. A existncia de uma
ferramenta no exclui a utilidade da outra. Logo, todas podem ser
usadas em conjunto de forma a analisar o cdigo-fonte de um
aplicativo Android por completo.

Se for requerido executar todas essas ferramentas durante o


mesmo build, pode ser declarada uma dependncia delas com a task
check do Gradle, de forma com que todas sejam disparadas de
forma implcita.

Figura 3.26: Dependncia de tasks para anlise de cdigo

Por padro, a ferramenta Lint acionada ao disparar a task


check .

Outro ponto a ser frisado so customizaes sobre quais regras


de conveno de cdigo devem ser aplicadas por cada ferramenta.
As ferramentas permitem a descrio dessas customizaes em
arquivos dedicados, como mostrado a seguir:

Figura 3.27: Customizaes para anlise de cdigo

3.3 ANLISE ESTTICA DE CDIGO 59


3.4 TESTES DE INTEGRAO

Figura 3.28: Estgio de testes de integrao

Dado que as unidades de uma aplicao so validadas


separadamente pelos seus correspondentes testes unitrios, nada
garante que a aplicao esteja livre de bugs. Afinal, as unidades
precisam interagir umas com as outras, de modo que a aplicao
solucione os problemas do usurio. Logo, as unidades e interaes
entre elas tambm devem ser testadas:

Figura 3.29: Teste de integrao

Um teste de integrao responsvel por validar as interaes


entre componentes da aplicao em si ou tambm entre

60 3.4 TESTES DE INTEGRAO


componentes da aplicao e partes do sistema com o qual ela
interage.

Figura 3.30: Testando interaes entre componentes da aplicao e componentes externos

Testes de integrao esto a para atender necessidades, tais


como as listadas a seguir.

Mais abrangentes que testes unitrios e com maior


granularidade que testes funcionais
Testes de integrao agem sobre a interao entre componentes.
Em testes unitrios, as unidades no interagem. Logo, existe essa
demanda a ser validada por testes de integrao.

Algum pode perguntar: Mas testes funcionais podem tratar


disso tambm. Podem mesmo. Mas vejamos o seguinte trecho de
cdigo. Ele mostra um mtodo pertencente camada de acesso a
dados (logo, no coberto por testes unitrios, j que essa camada
realiza interaes diretamente com uma base de dados):

3.4 TESTES DE INTEGRAO 61


public int create(Friend friend) {

mRealm.beginTransaction();

try {

mRealm.copyToRealm(friend);

} catch (IllegalArgumentException | RealmPrimaryKeyConstra


intException e) {

mRealm.cancelTransaction();
throw e;
}

mRealm.commitTransaction();

return SUCCESS_OPERATION;
}

A pergunta : como construir o cenrio de teste que cubra o


fluxo que faz com que seja lanada uma exceo
IllegalArgumentException ? Vale lembrar que testes funcionais
so baseados em BDD (Behavior Driven Development). Logo, por
que um cenrio to granular deveria fazer parte de um grupo de
testes responsvel por cobrir cenrios referentes a regras de
negcio? Os testes de integrao estaro a para atender esse
problema.

Executam mais rapidamente que testes funcionais


Apesar de serem mais lentos do que testes unitrios, testes de
integrao executam mais rapidamente do que testes funcionais.
Logo, ainda que sua execuo no seja adequada quando usada a
abordagem TDD (por no ser to rpida quanto a de testes
unitrios), os testes precisaro ser executados com uma certa
frequncia ainda.

Portanto, se testes onde componentes no podem ser mockados


necessitam ser executados com uma certa frequncia, que seja uma

62 3.4 TESTES DE INTEGRAO


create_whenProductIsNull_returnsIllegalArgumentException
(como o prprio nome descreve) trata do cenrio de um objeto
Friend nulo passado como parmetro para o mtodo testado,
resultando no disparo de um IllegalArgumentException :
@Test(expected = IllegalArgumentException.class)
public void create_whenFriendIsNull_returnsIllegalArgumentExcept
ion() {

// ARRANGE
Friend nullFriend = null;

// ACT
mFriendDal.create(nullFriend);
}

interessante notar como o objeto mFriendDal instanciado:


@BeforeClass
public static void setupClass() {

mContext = InstrumentationRegistry.getTargetContext().getA
pplicationContext();
mFriend = new FriendDal(mContext);

mFriendDal.clearDatabase();
}

Ou seja, diferente do cenrio tratado na seo sobre testes


unitrios, o objeto da classe mFriendDal instanciado de verdade,
e no um mock desse objeto. Para isso, obtido o contexto de
execuo dos testes atravs de
InstrumentationRegistry.getTargetContext().getApplicati
onContext() , para que seja passado como parmetro ao construtor
de FriendDal .

3.5 TESTES DE INTEGRAO EM ANDROID 65


O contexto necessrio para a instanciao do objeto que
acessa a base de dados. Nessa aplicao, fiz uso da biblioteca
Realm (https://realm.io/) para isso. Trata-se de um excelente
framework para manipulao de bases de dados em aplicaes
mobile. Porm, qualquer outro framework para manipulao
da base de dados poderia ter sido usado.

Um segundo mtodo de teste que merece ateno mostrado a


seguir:
@Test
public void retrieve_whenFriendNameExists_returnsFriend() {

// ARRANGE
final String FRIEND_NAME = "Roger";
final double FRIEND_DEBT = 52.00;

final double DEBT_DELTA = 0.01;

Friend friend = new Friend(FRIEND_NAME, FRIEND_DEBT);

Realm realm = Realm.getInstance(mContext);

realm.beginTransaction();
realm.copyToRealm(friend);
realm.commitTransaction();

// ACT
Friend retrievedFriend = mFriendDal.retrieve(FRIEND_NAME);

// ASSERT
assertEquals(friend.getName(), retrievedFriend.getName());
assertEquals(friend.getDebt(), retrievedFriend.getDebt(), DEBT
_DELTA);
}

Ele cobre o cenrio em que, j existindo um usurio buscado na


base de dados, o mtodo retrieve retorna o objeto Friend
referente a esse usurio. Porm, o detalhe mais interessante sobre

66 3.5 TESTES DE INTEGRAO EM ANDROID


esse mtodo a estratgia de teste. Como o mtodo testado
retrieve , pertencente classe FriendDal , recomendvel que
nenhum outro mtodo da classe FriendDal seja mencionado
nesse mtodo de teste.

Todos os mtodos presentes nessa classe sero julgados por uma


bateria de testes. Caso o mtodo para criao de usurio ( create )
seja usado para criar o usurio no mtodo de teste
retrieve_whenFriendNameExists_returnsFriend , uma falha
em create pode comprometer totalmente sua credibilidade.
Assim, deve ser usada outra abordagem para a criao do usurio na
base de dados, para que, por fim, o mtodo retrieve seja
corretamente testado. Essa preparao pode ser notada na seo
Arrange.
// ARRANGE
final String FRIEND_NAME = "Roger";
final double FRIEND_DEBT = 52.00;

final double DEBT_DELTA = 0.01;

Friend friend = new Friend(FRIEND_NAME, FRIEND_DEBT);

Realm realm = Realm.getInstance(mContext);

realm.beginTransaction();
realm.copyToRealm(friend);
realm.commitTransaction();

Como assinalado, usado o objeto de acesso a dados do


framework Realm para inserir o objeto Friend na base de dados.
Isso faz com que no haja dependncias entre os resultados dos
testes.

3.5 TESTES DE INTEGRAO EM ANDROID 67


Vale reiterar que, devido s informaes estarem sendo
manipuladas sobre a base de dados pelos mtodos de teste da
classe FriendDalTest , importante a base de dados ser
limpa aps a execuo de cada mtodo de teste. Isso pode ser
feito atravs de um mtodo com a annotation @After ,
executado aps cada mtodo de teste ser executado. Assim,
resqucios de informaes no sero persistidos entre a
execuo dos testes.

A execuo dos testes de integrao realizada da seguinte


forma:

Figura 3.31: Execuo de testes de integrao em Android

68 3.5 TESTES DE INTEGRAO EM ANDROID


Somente os testes de integrao sero executados. E a vem a
pergunta: possvel executar unit tests e instrumentation tests ao
mesmo tempo? A resposta : no e sim.

No possvel executar esses dois tipos de testes atravs da


interface grfica do Android Studio (at o instante de produo
desta publicao). Mas sim, possvel execut-los ao mesmo tempo
atravs do console via linha de comando. Para isso, no console do
Android Studio, digite o seguinte comando:

Gradle Windows gradlew.bat clean test


connectedAndroidTest

Gradle Linux ./gradlew clean test


connectedAndroidTest

Os resultados dos testes no so visveis pela interface grfica do


Android Studio. Porm, os resultados sobre a execuo dos testes
so gerados em um arquivo em formato HTML, localizado na
seguinte pasta:

3.5 TESTES DE INTEGRAO EM ANDROID 69


Figura 3.32: Folder com os resultados da execuo dos testes de instrumentao

Abrindo esse arquivo em um navegador web, possvel ver os


resultados dos testes:

Figura 3.33: Resultado dos testes instrumentados 1

Figura 3.34: Resultado dos testes instrumentados 2

70 3.5 TESTES DE INTEGRAO EM ANDROID


3.6 TESTES FUNCIONAIS

Figura 3.35: Estgio de testes funcionais

Esses testes realizam verificaes sobre o software sendo testado,


de acordo com a sua especificao. Todos os dados de entrada e
sada dos testes baseiam-se exclusivamente na especificao dos
casos de uso da aplicao.

A especificao de uma aplicao pode ser expressa por uma


abordagem enxuta. Tal abordagem praticada pela escrita de
histrias de usurio, que descrevem necessidades de um usurio sob
o ponto de vista dele.

Uma excelente referncia que trata sobre como histrias de


usurio devem ser escritas o livro User Stories Applied: For
Agile Software Development, de Mike Cohn (2004).

Levando-se em conta o aplicativo "Racha Conta", a seguinte


histria de usurio pode ser escrita para um requisito dessa
aplicao:

3.6 TESTES FUNCIONAIS 71


SENDO um frequentador de happy hour

Posso registrar um amigo na lista

Para que possamos rachar a conta ao fim da noite

Toda histria de usurio deve ser acompanhada por suas regras


de validao. As regras de validao podem ser descritas pela tcnica
BDD. Atravs dessa tcnica, possvel descrever as validaes a
serem realizadas sobre uma histria de usurio com o uso do
pattern Dado-Quando-Ento (Given-When-Then). Uma validao
possvel para a histria anterior pode ser descrita como:

CENRIO: Adiciona novo amigo em lista de amigos vazia

Dado que no existem amigos ainda

Quando eu cadastro um novo amigo

Ento esse amigo adicionado na lista

E a lista deixa de ser vazia

A descrio completa de cada validao de cada histria de


usurio da aplicao ser usada para nomear cada mtodo de teste
funcional.

Espresso: ferramenta para testes funcionais em


Android
uma ferramenta para testes automatizados de interface de

72 3.6 TESTES FUNCIONAIS


usurio. Em comparao com ferramentas semelhantes, tem o
diferencial de tratar automaticamente da sincronizao do fluxo de
execuo do teste com a UI (user interface), sem a necessidade da
adio de sleep's no cdigo-fonte.

Outro diferencial a ferramenta ter sido desenvolvida pelo


Google. Ou seja, nada melhor do que uma ferramenta desenvolvida
para atuar sobre aplicaes Android por aqueles que mantm e
conhecem a fundo esse sistema operacional.

A seguir, um mtodo de teste funcional criado para o cenrio


"Adiciona novo amigo em lista de amigos vazia", descrito
anteriormente, implementado com recursos do Espresso:
@Test
public void dadoQueNaoExistemAmigosAinda_quandoEuCadastroUmNovoA
migo_entaoEsseAmigoEhAdicionadoNaListaEAListaDeixaDeSerVazia() {

// ARRANGE
final String FRIEND_NAME = "Roger";

// ACT
onView(withId(R.id.deskfloatingactionbutton)).perform(click(
));
onView(withId(R.id.friend_name_edittext)).perform(typeText(F
RIEND_NAME));
onView(withId(R.id.add_friend_button)).perform(click());

// ASSERT
onView(withId(R.id.friends_recyclerview)).perform(actionOnIt
emAtPosition(0, click()));
}

Testes funcionais so tratados como testes de instrumentao


(instrumentation tests). Assim, necessrio que um emulador
Android seja executado antes da execuo dos testes.

Espresso uma ferramenta de testes recomendada para

3.6 TESTES FUNCIONAIS 73


desenvolvedores, e no testadores. Isso porque ela, por vezes, requer
capacidade tcnica de customizao de algumas classes para
viabilizar algumas validaes que precisam ser feitas sobre certos
componentes de UI mais complexos de serem manipulados, tais
como RecyclerView s.

No mtodo de teste funcional, para fins de demostrar o poder de


Espresso, vale destacar os seguintes comandos:
onView(withId(R.id.friend_name_edittext)).perform(typeText(FRIEN
D_NAME));
onView(withId(R.id.add_friend_button)).perform(click());

Algumas das melhores caractersticas de Espresso so


legibilidade e clareza em seus comandos, pois eles requerem pouco
esforo para o entendimento de suas intenes. O primeiro
comando pode ser interpretado da seguinte forma: "No componente
de campo de texto 'Nome', preencha-o com o nome do amigo". J o
comando subsequente relata: "No componente de boto 'Adicionar',
pressione-o".

A pgina do Android Testing Support Library contm uma boa


introduo sobre componentes do framework Espresso. Veja
mais em https://google.github.io/android-testing-support-
library/docs/espresso/index.html.

Tambm, uma boa fonte de informaes sobre Espresso pode


ser encontrado no GitHub da desenvolvedora Chiu-Ki Chan,
uma Android Developer Expert. Para mais informaes, acesse
https://github.com/chiuki.

Uma frase dita com frequncia (e, infelizmente, com bastante

74 3.6 TESTES FUNCIONAIS


frequncia) : "Se a inteno dos testes funcionais reproduzir
exatamente o fluxo de interao de um usurio contra uma
aplicao, ento eles so completos o suficiente para cobrir todos os
casos de uso possveis e imaginveis. Logo, testes unitrios e de
integrao so desnecessrios." ERRADO!!! Muito errado mesmo.
Cada categoria de testes tem a sua utilidade. Cada categoria
complementa as demais categorias. Alguns pontos que reforam
essa tese podem ser listados.

Em caso de falha, mais difcil a descoberta do erro


A execuo de um mtodo de teste funcional pode cobrir tanto o
fluxo de diversas telas da aplicao quanto fazer uso de muitas
classes responsveis por manipular regras de negcio. Digamos que
a execuo desse mtodo de teste falha. A pergunta que se faz :
quem garante que a causa do erro foi uma interao incorreta sobre
um componente de interface de usurio e no um valor inesperado
devolvido por um mtodo da camada de regras de negcio?"
Ningum pode garantir.

Na verdade, quem poderia garantir, ou fazer da busca pela causa


raiz da falha do teste funcional mais simples, seria os testes unitrios
e de integrao. Eles tm como caracterstica testar componentes
mais granulares da aplicao, tais como as unidades (classes,
mtodos etc.) e as interaes entre essas unidades, funes estas que
testes funcionais no possuem por testarem a aplicao em um
contexto mais amplo.

Tempo maior para o conserto de um bug


A sute de um conjunto de testes funcionais pode levar horas
para finalizar sua execuo. Muitos times de desenvolvimento
executam essa sute de testes pela madrugada, de modo que, ao
amanhecer, todos tenham o resultado da execuo. Um

3.6 TESTES FUNCIONAIS 75


desenvolvedor olha para o resultado e percebe que um mtodo de
teste funcional em especfico falhou. Logo, um conserto , ento,
aplicado.

No caso, o mtodo de teste falhado executado novamente para


que seja visto que o conserto aplicado foi suficiente para a correo
da aplicao. Caso esse mtodo de teste leve, em mdia, dez minutos
para ser executado por completo e, seja necessrio execut-lo
novamente diversas outras vezes para outros defeitos detectados
atravs desse teste, quanto tempo o desenvolvedor pode ficar neste
ciclo executa-conserta-executa?

Testes unitrios so rpidos, por definio. Caso fosse possvel


cobrir o bug analisado por testes unitrios, o tempo do ciclo citado
anteriormente seria muito menor, permitindo, assim, que o time de
desenvolvimento agregue real valor de negcio aplicao atravs
da correo aplicada e o usurio usufrua do software corrigido o
mais breve possvel.

Nesta altura do campeonato, conhecido como construir cada


bloco fundamental que auxilia para a construo de um pipeline de
deployment para apps Android. Como dispor cada estgio de testes
de forma a viabilizar o processo de automatizao que leva as
alteraes de desenvolvedores sobre projetos de app Android de um
repositrio de cdigo at a publicao desses apps no Google Play,
plataforma de distribuio de apps Android do Google?

No captulo seguinte, sero abordadas as ferramentas para


integrao e entrega contnua. Atravs delas, ser possvel a
automatizao de todas as etapas de construo e validao sobre
apps.

76 3.6 TESTES FUNCIONAIS


CAPTULO 4

FERRAMENTAS PARA
INTEGRAO E ENTREGA
CONTNUA

Ok! Adotaremos a prtica de entrega contnua a partir de hoje em


nossos projetos. Mas qual ferramenta vamos escolher? nesse
momento que muitas dvidas surgem. Uma vez que os conceitos
sobre integrao e entrega contnua estejam dominados, a correta
escolha pela ferramenta que far tudo acontecer , por muitas vezes,
to complicada quanto implementar um pipeline automatizado do
incio ao fim.

A ferramenta deve ser simples? Deve ter uma UI agradvel?


necessria uma customizao sobre como os estgios do pipeline
devem estar dispostos? Deve estar na nuvem ou em uma mquina
fsica prpria (self-hosted)? A configurao do build pode ser
compartilhada pelo repositrio de cdigo remoto? O uso gratuito
ou pago? Todas essas so questes relevantes de se levar em
considerao para a escolha da ferramenta.

Dezenas so os softwares disponveis para integrao/entrega


contnua. Muitas novas boas solues esto ainda sendo lanadas
(no que as antigas sejam ruins, muito pelo contrrio). A deciso
sobre a escolha das ferramentas, nesta publicao, foi embasada em
quatro critrios:

4 FERRAMENTAS PARA INTEGRAO E ENTREGA CONTNUA 77


4.1 TRAVIS CI

O Travis CI pode ser acessado em https://travis-ci.org/.

Trata-se de um servio de integrao contnua hospedado e


distribudo na nuvem usado para realizar builds, testes e deploys
sobre projetos hospedados no GitHub. Projetos presentes no
GitHub podem ser processados pelo Travis CI gratuitamente, desde
que a execuo seja limitada a um job por vez.

Um JOB uma entidade executvel controlada pela ferramenta


de integrao contnua, usada para construir e testar software.

A tela principal do Travis CI, para um determinado projeto,


exibida da seguinte forma:

Figura 4.1: Tela principal do Travis CI

Como demarcadas na figura, as sees da tela anterior podem

4.1 TRAVIS CI 79
ser descritas da seguinte forma (conforme os ndices sobre cada
seo):

1. Nome do repositrio compartilhado no GitHub da aplicao a


ser construda e validada.
2. Status do build realizado sobre a aplicao contendo descrio
da mensagem de commit, rtulo do build, tempo gasto para
execuo do build, autor do commit e branch sobre a qual o
commit buildado pertence.
3. Status resumido sobre os ltimos builds realizados sobre
projetos do usurio da conta.
4. Log de execuo do build.

Construindo o pipeline
Para que uma aplicao seja construda pelo Travis CI, deve ser
adicionado no diretrio raiz do projeto da aplicao um script de
build nomeado como .travis.yml .

Figura 4.2: Script de build no diretrio raiz do projeto

O .travis.yml trata-se de um arquivo do tipo YAML (YAML

80 4.1 TRAVIS CI
Ain't Markup Language). Esse arquivo pode ser definido como:

Figura 4.3: Script de build para o Travis CI

Alguns trechos desse arquivo merecem destaque:


language: android

Esse trecho permite ao Travis CI saber em qual tipo de ambiente


deve ser construda a aplicao. No caso desse exemplo, deve ser
instanciado um ambiente Android.

Uma vez instanciado um ambiente adequado para o build do


projeto Android, componentes do SDK tools e platform-tools devem
estar disponveis. Essa disponibilidade ser viabilizada

4.1 TRAVIS CI 81
automaticamente pelo script de build, como segue:
components:
- platform-tools
- tools

Para a execuo do build da aplicao, so necessrios os build-


tools (ferramentas de build):
- build-tools-23.0.2

Mas qual a verso do SDK que o script de build deve obter? Isso
tambm deve estar explcito no script. Preferencialmente,
recomendado que o script obtenha a ltima verso estvel do SDK:
- android-23

Tendo em vista que sero executados testes de instrumentao,


faz-se necessrio que um emulador seja disparado. Logo, o script de
build tambm deve conter o setup para essa ao:
- echo no | android create avd --force -n test -t andr
oid-19 --abi armeabi-v7a
- emulator -avd test -no-skin -no-audio -no-window &
- android-wait-for-emulator
- adb shell input keyevent 82 &

Por fim, as tasks que refletem a execuo dos estgios do


pipeline de deployment:
./gradlew clean testRelease lintRelease connectedReleaseAn
droidTest assembleRelease publishApkRelease

Cada task pertencente ao script cobre um ou mais estgios do


pipeline.

82 4.1 TRAVIS CI
Figura 4.4: Pipeline de deployment com tasks

Com a inteno de avanar sobre o entendimento de separao


de responsabilidades sobre um pipeline de deployment, o estgio
Produo foi separado em outros dois estgios: Empacotamento e
Publicao. O primeiro o responsvel por gerar o apk assinado
do aplicativo e disponibiliz-lo para o segundo, que ser o
responsvel por public-lo no Google Play.

Uma vez que as configuraes para o build estejam descritas no


arquivo .travis.yml e elas estejam na raiz do projeto da
aplicao, o Travis CI pode construir, validar e publicar o aplicativo.
Da mquina do desenvolvedor ao Google Play, o seguinte percurso
realizado:

1. O desenvolvedor executa por meio da ferramenta de controle


de verso o envio de todas as modificaes sobre arquivos do
projeto da aplicao para o GitHub ( git push ).
2. O GitHub notifica o Travis CI que alteraes sobre o
repositrio do projeto do aplicativo Android foram realizadas.
3. executado o script contido no arquivo .travis.yml sobre
o projeto da aplicao.

4.1 TRAVIS CI 83
4. disponibilizado um status com o resultado do
processamento do script.
5. (Opcional) enviado um e-mail para stakeholders caso o
build tenha sido quebrado ou consertado.

Figura 4.5: Build realizado com sucesso no Travis CI

Figura 4.6: Falha no build do Travis CI

84 4.1 TRAVIS CI
Figura 4.7: Notificao de falha no build do Travis CI

4.1 TRAVIS CI 85
Figura 4.8: Notificao de conserto no build do Travis CI

de fundamental importncia o envio de algum tipo de


notificao a partes interessadas em caso de quebra e conserto de
builds em servidores de integrao. Isso permite que qualquer
comportamento fora do comum durante a integrao da aplicao
(em caso de quebra no build) seja imediatamente sinalizado e, da
mesma forma, que seja notificado quando o build estabilizado (em
caso de conserto do build).

4.2 GOCD
uma ferramenta open source usada para entrega contnua de
software. O uso na implantao de projetos com a prtica de entrega
contnua gratuito. Porm, caso seja necessrio suporte tcnico
especializado, esse servio ser cobrado.

86 4.2 GOCD
O GoCD pode ser obtido em https://www.go.cd/.

Para o uso da soluo GoCD, necessrio realizar o download


de dois instaladores: o agent e o server . O agent GoCD
responsvel por processar todas as operaes relacionadas ao
correto funcionamento dos pipelines. J o server GoCD quem
delega todas as operaes para que o agent GoCD realmente as
execute.

Um server pode delegar que um processamento seja realizado


por mais de um agent ao mesmo tempo, caso esse seja um
processamento possvel de ser realizado concorrentemente.

Uma vez que o server e agent sejam instalados, o GoCD pode ser
acessado atravs da URL: http://localhost:8153. Ao acess-lo, o
usurio da ferramenta se depara com a seguinte tela:

4.2 GOCD 87
Figura 4.9: Tela principal do GoCD

A figura anterior exibe informaes sobre o build realizado em


um pipeline.

1. Nome do pipeline.
2. Acesso ao painel de configuraes do pipeline.
3. Rtulo do ltimo build realizado sobre o pipeline.
4. Acesso a um painel de comparao sobre builds
especificamente, o penltimo e ltimo builds executados.
5. ltimas alteraes realizadas sobre o projeto da aplicao.
6. Estgios do pipeline com status de sucesso ou falha.
7. Botes para iniciar um build padro, build customizado e
pausar o build corrente, respectivamente.

Na figura apresentada, j existe um pipeline criado com nome


de RachaContaAndroid . Antes de apresentar o passo a passo para

88 4.2 GOCD
Figura 4.10: Projeto de pipeline de deployment no GoCD

Construindo o pipeline
Para a criao desse pipeline, deve ser acessada, via navegador, a
URL http://localhost:8153. Aps, selecionar no menu do GoCD a
opo Admin > Pipelines . Por fim, criar o pipeline, como
mostrado a seguir:

Figura 4.11: Criao do pipeline no GoCD

Ento, o pipeline deve ser nomeado:

90 4.2 GOCD
Figura 4.12: Nomeao do pipeline

A seguir, detalhes sobre o material devem ser preenchidos. O


tipo de material usado pelo pipeline um repositrio Git, o qual
acionar a execuo do pipeline quando um novo push for realizado
sobre o repositrio. Tambm deve ser informada a URL do
repositrio Git e a branch sobre a qual devem ser enviadas
alteraes no projeto do aplicativo, para que o pipeline seja ativado.

4.2 GOCD 91
Figura 4.13: Definio do material

A prxima etapa iniciar a configurao do primeiro stage e job.


O stage Compile contm jobs responsveis por compilar o projeto
da aplicao. No caso, esse responsvel ser o job Compile .

92 4.2 GOCD
Figura 4.14: Definio de stage e job

4.2 GOCD 93
O GoCD suporta a execuo de tasks Gradle atravs da
instalao de um plugin. O arquivo .jar referente ao plugin
pode ser acessado em https://github.com/jmnarloch/gocd-
gradle-plugin/releases. Em seguida, o plugin deve ser
armazenado no folder $GO_SERVER_HOME/plugins/external
( $GO_SERVER_HOME o caminho no sistema de arquivos onde
est instalado o server do GoCD).

Neste ponto, j possvel executar o pipeline


RachaContaAndroid . Porm, ele somente compilar o projeto do
aplicativo. Assim, continuando a construo do pipeline, ser criado
o stage Tests pelo painel de configuraes do pipeline.

Figura 4.15: Criao de novo stage

No stage Tests , ser definido o tipo de trigger ( On Success


ou Manual ) que indica se o prximo stage ser iniciado
automaticamente, ou se dever ser iniciado de forma manual pelo
operador do GoCD. No mesmo dilogo, deve ser definido o nome
do primeiro job desse stage, no caso, o job Units (este responsvel
pela execuo de testes unitrios).

94 4.2 GOCD
Figura 4.16: Definio do stage Tests 1

Figura 4.17: Definio do stage Tests 2

O stage Tests , porm, deve conter o job responsvel por


realizar a anlise esttica de cdigo sobre o projeto da aplicao.
Esse ser o job Quality . A criao do novo job para o stage
Tests , j criado, deve ser realizada da seguinte forma:

4.2 GOCD 95
Figura 4.18: Criao de novo job

A criao de cada stage e job restantes se d de forma similar


aos j criados. As tasks executadas pelo pipeline so exatamente
as mesmas usadas pelo Travis CI.

Uma vez que todos os componentes do pipeline estejam


definidos, ele dever assumir a seguinte estrutura:

96 4.2 GOCD
Figura 4.19: Esqueleto do pipeline RachaContaAndroid

Com o pipeline pronto, a cada vez que forem comitadas


alteraes no repositrio no GitHub (no contexto do GoCD, o
material), o pipeline ser executado automaticamente para
construir, validar e publicar o app Android para o Google Play.

No arquivo build.gradle , em nvel de mdulo, esto


descritas instrues como estas:
storePassword System.getenv("KEYSTORE_PASSWORD")
keyAlias System.getenv("ALIAS_NAME")
keyPassword System.getenv("ALIAS_PASSWORD")

Essas instrues acessam variveis de ambiente. Informaes


sigilosas, como por exemplo, senha de chave criptografada
usada para assinar o apk do aplicativo, no devem estar
explcitas no build.gradle . Dados como esses devem ser
setados nas variveis de ambiente do software de integrao

4.2 GOCD 97
contnua, como o Travis CI e GoCD. Dessa forma, uma vez
que o script de build seja processado por servidores de
integrao, o dado sigiloso ser obtido pelo script diretamente
do servidor de integrao, onde estar protegido, tal como
mostrado a seguir na configurao do pipeline do GoCD:

Figura 4.20: Definio de variveis de ambiente

O exemplo da imagem anterior, vale tambm para qualquer


servidor de integrao contnua.

4.3 JENKINS
Um dos softwares de integrao contnua mais conhecidos pela
comunidade de desenvolvimento de software o Jenkins. Uma de
suas principais caractersticas sua extensibilidade por meio do uso
de plugins.

98 4.3 JENKINS
O Jenkins pode ser obtido em https://jenkins.io/. fortemente
recomendvel o uso de uma verso estvel. Tambm est
disponvel para download verses no estveis. Porm, nesse
ltimo caso, muitas funcionalidades podem apresentar
comportamento inesperado.

Ao finalizar a instalao do Jenkins, ele ser iniciado


automaticamente no navegador padro. Caso contrrio, para
acessar seu painel principal, deve ser digitada a seguinte URL no
navegador: http://localhost:8080. O navegador dever mostrar a
seguinte tela:

Figura 4.21: Painel principal do Jenkins

Plugins do Jenkins
Como mencionado anteriormente, Jenkins suporta uma
infinidade de plugins que permitem sua extensibilidade. Logo, para
a construo de um pipeline de deployment para o aplicativo Racha
Conta, alguns plugins devero ser instalados. Dentre eles, alguns

4.3 JENKINS 99
Duas observaes merecem ser feitas sobre os plugins. Sobre os
plugins relativos anlise esttica de cdigo, vale relembrar
que eles tm funes complementares. Ou seja, cada
mecanismo realiza um tipo de anlise sobre o cdigo, de forma
que a adoo desses plugins em conjunto faz-se plausvel.

Por fim, sobre o plugin para emular um dispositivo Android,


uma coisa precisa ser dita: ele problemtico. Apesar de ser o
plugin mais recomendvel para emulao de dispositivos
Android, conforme novas verses so lanadas, algumas
caractersticas do plugin que, em verses anteriores
funcionavam normalmente, podem passar a deixar de
funcionar.

Dependncias de sistema operacional (Linux, Windows etc.) e


sobre a mquina ser 32 ou 64 bits tambm so elementos
difceis de serem tratados adequadamente pelo plugin. Logo, a
execuo de testes funcionais sobre apps Android pode ser
dificultada no Jenkins. A sua viabilidade depender muito de
experimentos durante a configurao desse plugin.

Todavia, para fins de demonstrar a configurao do estgio de


testes funcionais no Jenkins, ser usada uma verso estvel
desse plugin, mesmo no sendo a verso mais atual. E uma boa
fonte de informaes sobre esse plugin seu GitHub
(https://github.com/jenkinsci/android-emulator-plugin).

A definio da varivel de ambiente ANDROID_HOME tambm


necessria no Jenkins, para que ele conhea onde est localizado o
SDK Android. Para isso, a partir do seu painel principal, navegue
atravs de Gerenciar Jenkins > Configurar o sistema .
Ento, defina a varivel de ambiente ANDROID_HOME e tambm o

4.3 JENKINS 101


valor para o campo Android SDK root.

Figura 4.22: Definio da varivel de ambiente ANDROID_HOME

Figura 4.23: Definio do caminho para a pasta do SDK Android

Construindo o pipeline
O pipeline construdo no Jenkins conter estgios com as
mesmas responsabilidades que os estgios usados para a construo
do pipeline no GoCD.

Os estgios do pipeline no Jenkins so construdos atravs de


jobs. Assim, na tela principal do Jenkins, deve ser selecionado Novo
job e, ento, o job nomeado como RachaContaAndroidCompile .

102 4.3 JENKINS


Figura 4.24: Definindo o job Compile

Algumas configuraes do job so triviais, tais como nome do


job e descrio. Outras, porm, merecem destaque.

Figura 4.25: Descartando builds antigos

Essa configurao determina que somente sero persistidos logs,


relatrios e artefatos resultantes de builds durante um determinado
perodo de tempo ou somente de um certo nmero de builds. Como
mostrado na figura, somente os trs ltimos builds do job tero suas
informaes persistidas, o que auxilia no gerenciamento de espao
em disco da mquina que hospeda a ferramenta.

A seguir, deve ser definido o endereo do repositrio de


gerenciamento de cdigo-fonte, o qual o Jenkins obter o projeto do

4.3 JENKINS 103


aplicativo a ser construdo.

Figura 4.26: Configurando URL do repositrio remoto

Uma vez que o projeto seja adquirido do sistema de controle de


verso para a mquina na qual o Jenkins est hospedado, o processo
de compilao poder ser executado. Para defini-lo, selecione
Adicionar passo de build e, ento, a opo para invocar o
script Gradle. Uma nova subseo de formulrio estar disponvel.
Nela, devem ser descritas quais tasks do Gradle sero executadas por
este estgio.

Figura 4.27: Definindo tasks Gradle para estgio Compile

104 4.3 JENKINS


A importncia de um estgio de compilao em um pipeline de
integrao contnua, alm de compilar a aplicao, fornecer
rpido feedback sobre falhas triviais.

Por fim, basta salvar as configuraes do job. Com as


configuraes salvas, o projeto Racha Conta pode ser construdo.

Figura 4.28: Compilando projeto Racha Conta

Caso o job tenha sido executado com sucesso, seu status atual
ser exibido na tela principal do Jenkins com o cone de um sol.

Figura 4.29: Status do job Compile

4.3 JENKINS 105


Caso contrrio (com uma falha na execuo do build), um cone
em formato de chuva com trovoadas ser mostrado.

Seguindo com o prximo job a ser configurado, que trata da


execuo de testes unitrios, este ser nomeado como
RachaContaAndroidUnits . Sua configurao em muito se
assemelha ao job anterior. Logo, sero mencionados somente os
pontos relevantes para essa configurao.

Na seo Opes avanadas do projeto , deve ser


selecionada a opo Usar workspace customizado . Uma vez que
o projeto da aplicao obtido do repositrio de cdigo remoto
pelo job RachaContaAndroidCompile , ele armazenado em um
diretrio na mquina local denominado de workspace. Para que no
seja necessrio repetir esse procedimento, na configurao do job
RachaContaAndroidUnits (e nas configuraes dos prximos
jobs), o projeto do aplicativo Racha Conta ser referenciado para
esse workspace j definido.

Figura 4.30: Referenciando workspace j existente

Em seguida, deve ser adicionado um passo de build com a


invocao de um script Gradle. Nele, deve ser descrita a task
responsvel pela execuo de testes unitrios.

106 4.3 JENKINS


Figura 4.31: Descrevendo task de execuo de testes unitrios

Adicionalmente, deve ser configurada uma ao ps-build. Essa


ao executada uma vez que o passo de build tenha sido finalizado,
ou seja, a task testReleaseUnitTest . A ao a ser selecionada
Publicar relatrio de testes do JUnit . Aps a execuo
dos testes unitrios sobre o aplicativo, gerado um relatrio
contendo detalhes dos resultados alcanados com a execuo dos
testes unitrios.

Figura 4.32: Configurando ao de ps-build

Com o relatrio disponvel, o Jenkins vai analis-lo e, ento,


exibir informaes sobre os resultados na forma de um grfico.

4.3 JENKINS 107


Dentre as informaes, esto o nmero de testes unitrios
executados e, dentre eles, quantos passaram e falharam.

Figura 4.33: Grfico de resultados de testes unitrios

Com dois jobs configurados ( RachaContaAndroidCompile e


RachaContaAndroidUnits ), j possvel encadear a execuo dos
estgios e visualizar esse encadeamento na forma de um pipeline de
deployment. Assim, voltando configurao do job
RachaContaAndroidCompile , deve ser definida uma ao ps-
build que permita o trigger de build parametrizados. No caso, o
trigger no ser parametrizado, e sim, ser uma simples inicializao
da execuo do estgio de testes unitrios quando o estgio de
compilao tiver sido finalizado com sucesso. Essa ao ps-build
deve ser definida como a seguir:

Figura 4.34: Encadeando execuo de estgios em um pipeline

108 4.3 JENKINS


Tendo sido disparada a execuo do estgio
RachaContaAndroidCompile , em caso de execuo com sucesso,
automaticamente o estgio RachaContaAndroidUnits ser
executado. Isso de forma que a aplicao no somente seja
verificada quanto sua correta compilao, como tambm quanto
validao dos seus mdulos atravs de testes unitrios.

Essa configurao de encadeamento no somente valida para


os estgios RachaContaAndroidCompile e
RachaContaAndroidUnits , como tambm entre os estgios:

RachaContaAndroidUnits e RachaContaAndroidQuality ,

RachaContaAndroidQuality e
RachaContaAndroidInstrumented ,

RachaContaAndroidInstrumented e
RachaContaAndroidAssemble ,

RachaContaAndroidAssemble e
RachaContaAndroidPublish .

O prximo estgio a ser configurado aquele responsvel pela


anlise esttica de cdigo, atravs do job
RachaContaAndroidQuality . Em relao s suas configuraes,
ele se assemelha ao job configurado anteriormente. O que distingue
um do outro so as tasks responsveis pela anlise esttica e a
configurao de publicao dos relatrios com os resultados dessas
anlises. Elas se do da seguinte forma:

4.3 JENKINS 109


Figura 4.35: Descrevendo tasks de anlise esttica de cdigo

110 4.3 JENKINS


Figura 4.36: Configurao da publicao dos resultados das anlises de cdigo

Da mesma forma que na publicao de resultados do relatrio


de testes unitrios no estgio RachaContaAndroidUnits , gerada
uma publicao semelhante aps a execuo do estgio

4.3 JENKINS 111


RachaContaAndroidQuality .

Figura 4.37: Publicao dos resultados das anlises de cdigo

So gerados grficos para os resultados da anlise esttica de


cdigo de cada ferramenta de anlise. Na figura mostrada, possvel

112 4.3 JENKINS


ver que a ferramenta Lint detectou quatro issues. J as outras
ferramentas no detectaram issues nas anlises realizadas.

O estgio seguinte a ser preparado encarregado pela validao


das funcionalidades disponibilizadas pelo app. Esse estgio, que
executar uma bateria de testes funcionais sobre a aplicao, se
chamar RachaContaAndroidInstrumented (o nome origina-se
da expresso "testes de instrumentao").

A configurao do job referente a esse estgio tem uma


particularidade: seu build parametrizado. Ou seja, a execuo do
job necessita de informaes previamente determinadas na
configurao do job. Os valores fornecidos devem ser preenchidos
pelo responsvel pela configurao do job, pois, para a gerao de
um pacote de aplicativo Android, so necessrias informaes que
requerem confidencialidade, tais como a senha da chave do
certificado usado para assinar o arquivo apk .

Tais informaes no podem estar descritas explicitamente no


arquivo build.gradle da aplicao. Porm, podem estar descritas
de forma protegida no software de integrao que construir o
projeto, no caso o Jenkins:

Figura 4.38: Configurando build parametrizado

Outro diferencial da configurao do job referente a este estgio


est relacionado preparao do emulador a ser disparado para a
execuo dos testes funcionais.

4.3 JENKINS 113


Figura 4.39: Configuraes do emulador

Na figura, so exibidas caractersticas do dispositivo emulado


para a execuo dos testes, como a verso do sistema operacional
Android, densidade da tela e resoluo da tela. importante notar
que a opo Reset emulator state at start-up est
selecionada. Ela determina que, a cada incio de execuo do estgio
RachaContaAndroidInstrumented , seja usado um emulador novo
sem resduos de execues anteriores, de modo que os resultados
dos testes funcionais sejam confiveis.

114 4.3 JENKINS


Como mencionado anteriormente, o Android Emulator Plugin
do Jenkins pode apresentar muitos problemas. Logo,
sugerido obter uma verso estvel dele, de modo a viabilizar a
construo do estgio RachaContaAndroidInstrumented .
No GitHub desse plugin
(https://github.com/jenkinsci/android-emulator-
plugin/releases) so disponibilizadas diversas verses. Uma
verso que considerada mais estvel que outras esta:

Figura 4.40: Verso estvel do Android Emulator Plugin

Deve ser realizado o download do arquivo android-


emulator.hpi . Ento, pelo Jenkins, acesse o menu
Gerenciar Jenkins > Gerenciar plugins . Em seguida,
acesse a aba Avanado e, por fim, realize o upload do plugin
atravs da seo Atualizar plugin .

Uma vez que o Jenkins seja reiniciado, o estgio de testes


funcionais tende a ser executado sem problemas. Vale frisar:
tende. Lembrando, trata-se de um plugin instvel. Pode ser
necessrio algum esforo adicional para seu correto
funcionamento.

O prximo estgio a ser configurado responsvel pelo

4.3 JENKINS 115


empacotamento do app Racha Conta na forma de um arquivo de
aplicativo Android (ou seja, com extenso .apk ), que se chama
RachaContaAndroidAssemble .

A task Gradle, responsvel pelo processo de empacotamento da


aplicao, deve ser definida, como tambm a disponibilizao do
artefato resultante do processo de empacotamento, ou seja, do apk
do aplicativo Android.

Figura 4.41: Definindo task do processo de empacotamento

Figura 4.42: Configurao para disponibilizao do arquivo do aplicativo Racha Conta

Uma vez que a execuo do job RachaContaAndroidAssemble


tenha sido finalizada com sucesso, o arquivo apk do Racha Conta
estar disponvel.

116 4.3 JENKINS


Figura 4.43: Disponibilizao do arquivo do aplicativo Racha Conta

O ltimo job a ser configurado responsvel pela publicao do


aplicativo Racha Conta no Google Play. O job
RachaContaAndroidPublish tem somente duas diferenas
significativas em relao aos jobs anteriormente configurados.

A primeira a necessidade de fornecimento do service account


usado para publicao no Google Play. Um service account um
mecanismo que permite o uso da Google Play Developer Publishing
API (que ser melhor explicada em sees posteriores) atravs de
uma aplicao em vez de um usurio comum. A aplicao, no
contexto dessa seo, o Jenkins. Assim como, em sees
anteriores, a aplicao foi o Travis CI e o GoCD.

A informao sobre o service account fornecida na seo de


build parametrizado da configurao do job. Logo, o job
RachaContaAndroidPublish executa um build parametrizado.

4.3 JENKINS 117


Figura 4.44: Fornecimento do service account

Por ltimo, necessria a configurao da task Gradle de


publicao.

Figura 4.45: Configurao da task de publicao

Agora temos todos os estgios do pipeline finalmente


configurados! Porm, apesar de sempre fazermos referncias aos
jobs como estgios, intuitivamente no temos at o momento o
pipeline como se estivesse composto por estgios, pela falta de uma

118 4.3 JENKINS


representao visual do pipeline. Essa representao, contudo, ser
possvel com o uso do Build Pipeline Plugin. Para a criao dessa
representao visual, segue sua definio:

Figura 4.46: Estgios do pipeline do Racha Conta

Figura 4.47: Definindo a representao visual do pipeline

A configurao essencial do pipeline simples. Basta determinar


o job inicial. No caso do pipeline do Racha Conta, esse job o
RachaContaAndroidCompile . Tendo o pipeline configurado, o
painel de visualizao exibido como a seguir:

4.3 JENKINS 119


Figura 4.48: Opo de menu para o pipeline do Racha Conta

Figura 4.49: Representao visual do pipeline do Racha Conta (retngulos verdes e vermelhos)

primordial que pipelines de deployment sejam visuais, pois


eles fornecem feedback com muito eficcia. Por exemplo, cada
retngulo na figura anterior representa um estgio. Retngulos de
cor verde expressam que a execuo do pipeline naquele estgio foi
finalizada com sucesso. J retngulos de cor vermelha expressam
algum tipo de falha em seu processamento.

Como demonstrado no captulo 3, esse pipeline construdo pelo


Jenkins poderia ser exibido em um monitor em uma sala ampla, por
exemplo, de modo que todas as pessoas interessadas no atual estado
do aplicativo saberiam imediatamente caso algo de errado estivesse

120 4.3 JENKINS


acontecendo durante o processamento do build.

Analisando individualmente a representao visual de um


estgio do pipeline, temos:

Figura 4.50: Detalhes de um estgio de pipeline

1. Rtulo de execuo do estgio


2. Nome do estgio
3. Data e horrio da execuo do estgio
4. Quantidade de tempo gasta para execuo do estgio
5. Indica que o estgio requer parmetros para sua execuo
6. Sada do console contendo logs da execuo do estgio
7. Boto para reexecuo do estgio

Ainda, um cenrio possvel do pipeline o seguinte:

Figura 4.51: Trigger manual de um estgio

No boto sinalizado na figura, o estgio


RachaContaAndroidPublish pode somente ser ativado
manualmente. Esse contexto em especfico vivel quando, por

4.3 JENKINS 121


exemplo, por estratgia da rea comercial da empresa proprietria
do aplicativo, prefere aguardar uma data ou ocasio para sua
publicao. Isso continuous delivery. Em caso de continuous
deployment, 100% do pipeline seria automatizado, sem a
necessidade de interveno manual.

Para viabilizar esse


cenrio, o estgio
RachaContaAndroidAssemble precisa ser reconfigurado, pois
ele estava anteriormente preparado para ativar o estgio
RachaContaAndroidPublish automaticamente. Logo, a
configurao de trigger automtico excluda e, em seu lugar,
habilitada a configurao de trigger manual:

Figura 4.52: Configurando trigger manual do prximo estgio

4.4 COMPARAO ENTRE FERRAMENTAS


Comparaes so sempre polmicas. A melhor ferramenta
dentre as apresentadas ... Depende! Desenvolver software
profissionalmente de forma correta difcil.

Complexidade algo presente e constante no dia a dia de um


time de desenvolvimento de software. Prazos, necessidades, custos,
nvel tcnico dos membros de equipe, tudo deve ser levado em
considerao na tomada de decises. E a ferramenta usada para
integrao do software tambm merece ser avaliada

122 4.4 COMPARAO ENTRE FERRAMENTAS


minuciosamente, segundo um conjunto de fatores.

Existem muitos elementos que podem ser levados em conta na


escolha da ferramenta de integrao ideal. A importncia de tais
elementos subjetiva. A lista a seguir resultante de pesquisa (sobre
a documentao de cada ferramenta e opinies de usurios),
experimentos realizados e experincia acumulada do uso frequente
delas. Tais fatores so descritos a seguir.

Conteinerizao
Contineres provm ambientes que isolam a dependncia de
mquina para os softwares que so manipulados dentro deles. Eles
tambm fazem uso de primitivas do sistema operacional onde so
instalados, de modo que eles possam ser instanciados e destrudos
rapidamente, em contrapartida a mquinas virtuais convencionais.

O Travis CI permite o build sobre aplicaes em ambientes


conteinerizados, de forma que a construo de aplicaes sob esses
ambientes no ser afetada sobre problemas tpicos em integraes,
como: dependncia de sistema operacional, mquinas trabalharem
com sistemas de 32 ou 64 bits, dependncias de softwares auxiliares
para seus builds, dentre outras preocupaes.

J o GoCD e Jenkins, pelo fato serem self-hosted, podero


apresentar dependncias. Contudo, viavelmente possveis de serem
tratadas.

Visibilidade do pipeline
Durante a execuo de um build no Travis CI, possvel
somente ver o log dessa execuo em tempo real e se algo est
errado. Ao final do build, tambm possvel saber se o build falhou
ou passou. Porm, no possvel com essa ferramenta mostrar o
pipeline com seus estgios dispostos, de modo a permitir a gesto

4.4 COMPARAO ENTRE FERRAMENTAS 123


visual por partes interessadas no atual status da integrao do
aplicativo.

J com as ferramentas GoCD e Jenkins (atravs do uso de


plugins), essa disposio possvel por padro. Isso muito
importante, j que feedback rpido uma das caractersticas mais
importantes em ferramentas de integrao.

Complexidade de workflows
Jobs podendo ser executados em paralelo, com deploys sendo
disparados em mltiplos ambientes e monitoramento de vrias
branches simultaneamente... Em cenrios nem to complexos como
esse, o Travis CI pode no oferecer suporte total, sendo necessrio o
auxlio de um shell script para a customizao do workflow.

J o GoCD e o Jenkins so ferramentas poderosas em relao a


gerenciamento de workflows complexos. Alm de permitirem o
suporte de um shell script no gerenciamento de seu pipeline, por
vezes ele no se faz necessrio.

Atravs de suas IDEs (principalmente do GoCD), essa


complexidade de workflows pode ser gerenciada. Ademais, quando
o Jenkins no oferece suporte suficiente, por default, basta a adio
de plugins ferramenta para que ela seja capaz de suprir tal tarefa.

Extensibilidade por plugins


O servidor de integrao Travis CI no permite a instalao de
plugins para que o possibilite ser mais extensvel quanto a novas
funcionalidades. J o GoCD e, principalmente, o Jenkins tm isso
como uma de suas principais caractersticas.

O GoCD (ao menos no momento em que este livro est sendo


escrito) ainda oferece poucos plugins compatveis que sejam teis

124 4.4 COMPARAO ENTRE FERRAMENTAS


para integrao de aplicaes Android. O principal deles o Gradle
Plugin. J o Jenkins tem entre suas principais qualidades um amplo
espectro de plugins disponveis, inclusive para integrao de apps
Android.

necessrio reaproveitar os dados de um relatrio para exibi-los


visualmente? Existe um plugin que trata esse problema. Preciso de
um plugin que notifique por SMS stakeholders quando um build
quebra. Existe tambm um plugin para isso. Preciso de um plugin em
que o Chuck Norris d uma bronca no time de desenvolvimento
quando o build quebra. At para isso existe plugin, acredite. Ou seja,
desde plugins essenciais at os no to essenciais, permitem com
que o Jenkins fique com a cara que seus responsveis desejam e
atenda seus problemas da forma mais conveniente.

Usabilidade da ferramenta
Preciso simplesmente integrar meu app Android do repositrio de
cdigo-fonte ao Google Play. Essa uma tarefa simples com o uso do
Travis CI, pois, para um simples workflow como aquele descrito, a
interface grfica da ferramenta oferece uma experincia de usurio
muito intuitiva. O mesmo vale para o GoCD.

Contudo, quando analisando a usabilidade do Jenkins, isso no


vale. Apesar do poder dessa ferramenta, o seu operador precisa
descobrir como extrair todo o seu potencial, ou experimentando-a,
ou atravs de fontes na internet que explicam como resolver
determinados problemas encontrados durante sua configurao.

Confiana na ferramenta
O que significa "confiana na ferramenta"? Por exemplo, no
Travis CI e GoCD, uma vez que o usurio interaja diretamente com
sua interface grfica para o ajuste de determinada configurao, essa
imediatamente aplicada. A mesma experincia com o Jenkins,

4.4 COMPARAO ENTRE FERRAMENTAS 125


uma boa quantidade de vezes, no verdadeira, fazendo-se
necessria a sua reinicializao para que a configurao seja
aplicada.

O problema desse cenrio so vrios jobs j estarem


configurados (com alguns em execuo) e ser necessria a
reinicializao da ferramenta devido a um especfico job. Ou seja, o
Jenkins no costuma ser to confivel quanto as outras ferramentas,
o que no significa que seja uma ferramenta ruim diante de suas
tantas outras qualidades.

Expondo todos esses fatores relatados, visualmente temos:

Figura 4.53: Comparao entre ferramentas

Apesar de no ser a melhor ferramenta avaliada de acordo com


os prs e contras expostos na tabela, o Jenkins muito mais
malevel graas a seu arsenal de plugins. Em consequncia disso, o
que ele entrega de valor ao usurio maior em relao s outras
ferramentas.

Como profissionais da rea de produo de software,


fundamental que tenhamos a naturalidade em realizar
experimentos. O Jenkins no resolve tal problema. Pesquise por
plugins que possam resolver esse problema (ou mesmo,

126 4.4 COMPARAO ENTRE FERRAMENTAS


experimente desenvolv-los do zero).

O Jenkins tem um bug quando certo plugin aplicado. V ao


GitHub onde est hospedado o Jenkins
(https://github.com/jenkinsci/jenkins) e entre nas discusses de
issues abertas para ele. Algumas respostas para problemas estaro
expostas l. Sendo um profissional de desenvolvimento de software
ou responsvel no setor de infraestrutura, quase um requisito esse
interesse constante em construir e desconstruir solues. E isso
essencialmente o que o Jenkins permite atravs de seus plugins.

J est disponvel o Jenkins 2.0 para download. Essa verso do


Jenkins permite com que um pipeline por completo seja
descrito como cdigo (pipeline as code) atravs de um arquivo
com scripts de build, semelhante ao Travis CI. Pipelines
expressos dessa forma permitem que, em um ambiente com
cultura DevOps, tanto responsveis pela rea de
desenvolvimento (Dev) quanto pela rea de operao (Ops)
comuniquem-se por uma linguagem compreensvel a todos.

Alm disso, outro ponto a favor permitir compartilhar a


configurao do pipeline como cdigo por meio de um
repositrio compartilhado, tal como o GitHub. Apesar da
possibilidade de codificar um pipeline inteiro como cdigo, a
verso 2.0 do Jenkins (no momento em que este livro est
sendo escrito) apresenta ainda muitos bugs. Porm, conforme
o passar do tempo, a tendncia esse cenrio melhorar e ser
recomendada sua adoo.

4.5 PUBLICAO NO GOOGLE PLAY

4.5 PUBLICAO NO GOOGLE PLAY 127


Todos os estgios que compem um pipeline de integrao
contnua so igualmente importantes. Porm, um estgio merece
especial ateno, pois, tendo sido determinado que uma aplicao
ser construda e validada de forma automatizada, outra pergunta
cabe: automatizar ou no o deploy?

No existe resposta correta para essa pergunta. A resposta mais


apropriada (mais uma vez) depende! Depende da necessidade do
proprietrio da aplicao. Alm disso, automatizar a etapa de
publicao o que diferencia o processo de entrega em continuous
delivery e continuous deployment. Ou seja, uma vez que o pipeline
inicie sua execuo, caso a aplicao tenha sido corretamente
construda e validada, ela sempre ser automaticamente publicada
no Google Play (no caso de apps Android), ou depender da ao de
algum determinar se ela ser publicada ou no.

Independente se o estgio de publicao ser engatilhado


automaticamente ou no, quem despachar o apk em direo ao
Google Play ser a ferramenta de automao, seja ela o Travis CI,
GoCD ou Jenkins. E para que isso seja possvel, elas faro uso da
Google Play Developer Publishing API. Essa API serve como
interface entre a ferramenta de automao e o Google Play:

128 4.5 PUBLICAO NO GOOGLE PLAY


Figura 4.54: Publicao pela Google Play Developer Publishing API

O uso desta Web API requer o entendimento dessa atravs de


sua documentao (https://developers.google.com/android-
publisher/). Porm, existe um caminho muito mais simples. Trata-
se do plugin gradle-play-publisher. Ele simplifica a publicao de um
arquivo apk e seus metadados ao Google Play por meio de tasks
Gradle, sem a necessidade da implementao de chamadas
explcitas Web API.

4.5 PUBLICAO NO GOOGLE PLAY 129


Figura 4.55: Publicao atravs do gradle-play-publisher

O GitHub do gradle-play-publisher a principal fonte de


informaes sobre configurao e uso desse plugin:
https://github.com/Triple-T/gradle-play-publisher.

Ou seja, como mostra a figura, o gradle-play-publisher uma


espcie de invlucro sobre a Google Play Developer Publishing API,
tal que solicitaes HTTP explcitas a essa Web API tornam-se
desnecessrias.

Automatizando a publicao
Para viabilizar a automatizao de um app Android no Google
Play, o primeiro passo public-lo manualmente. Sim, a primeira
publicao deve ser manual, pois necessrio o registro do
applicationId do aplicativo na plataforma de distribuio do
Google, e isso no pode ser realizado atravs da Web API de
publicao.

130 4.5 PUBLICAO NO GOOGLE PLAY


A publicao manual do aplicativo no Google Play requer que o
arquivo apk seja gerado. Todo apk Android deve ser assinado
por um certificado digital. Portanto, esse certificado deve ser gerado.

Para ger-lo, selecione a opo de menu do Android Studio


Build > Generate Signed APK... e preencha todas as
informaes solicitadas. Ao final do processo, um arquivo
denominado keystore (com extenso .jks ) ser gerado e o
arquivo apk referente ao aplicativo poder ser criado.

Mais detalhes sobre o ato de assinar apps Android podem ser


encontrados em
https://developer.android.com/studio/publish/app-
signing.html.

Ao determinar onde o apk dever ser armazenado ao final do


processo de sua gerao, preferencialmente, escolha o seguinte local:

Figura 4.56: Localizao de apk gerado

4.5 PUBLICAO NO GOOGLE PLAY 131


Tambm possvel gerar o mesmo apk atravs da execuo da
task Gradle assembleRelease no console do Android Studio.
Porm, para que isso seja possvel, as devidas configuraes devem
ser adicionadas ao arquivo build.gradle em nvel de mdulo:

Figura 4.57: Configurando apk release 1

Figura 4.58: Configurando apk release 2

O arquivo keystore , gerado pela opo de menu Generate


Signed APK... , deve ser adicionado no folder raiz do projeto do
app, para que possa ser indexado atravs da instruo
rootProject.file . O restante das configuraes faz uso da
instruo System.getenv , que permite que valores sejam
acessados de variveis de ambiente do sistema.

No contexto de uma ferramenta de integrao contnua como,


por exemplo, o Jenkins, ser possvel configurar builds

132 4.5 PUBLICAO NO GOOGLE PLAY


parametrizados, em que os parmetros do build (isto , variveis de
ambiente) podem ser definidos, obtidos durante o processamento
do build da aplicao e substitudos nas instrues contidas no
arquivo build.gradle , que fazem referncias a esses parmetros.
Isso permite que informaes sigilosas, tais como senhas, no
estejam explcitas no arquivo de configurao, e sim na ferramenta
de integrao, o que mais conveniente quanto ao quesito
segurana.

Alm disso, vale mencionar a instruo signingConfig


signingConfigs.release , que determina que apk s gerados com
o tipo de build release sejam construdos com as informaes
fornecidas para esse tipo de build na seo signingConfig . Uma
vez que as configuraes para assinatura sejam todas fornecidas,
executando a task Gradle assembleRelease , em caso de sucesso
no build, far com que o apk gerado seja armazenado no folder
apk , como mostrado na figura anteriormente.

Uma vez com o apk do aplicativo disponvel, preciso acessar


o painel do Google Play Developer Console. O painel pode ser
acessado em: https://play.google.com/apps/publish/.

Uma informao importante: para publicar apps no Google


Play, necessrio o pagamento de uma taxa nica de US$25,00.

Estando no painel de configurao, o boto Add new


application deve ser pressionado e o nome do app preenchido.
Por fim, deve ser selecionado o boto Upload APK , resultando na
exibio do painel de administrao para o app:

4.5 PUBLICAO NO GOOGLE PLAY 133


Figura 4.59: Racha Conta no Google Play Developer Console

Antes que o app seja publicado no Google Play, informaes


sobre ele tero de ser preenchidas em formulrios contidos neste
painel, como descrio do app a ser exibida no Google Play,
classificao de faixa etria recomendada para o app, cone do app,
dentre outras informaes. Uma vez que todas as informaes sejam
preenchidas, o boto Upload your first APK to Production
deve ser pressionado.

Ento, ser realizado o upload do arquivo apk do aplicativo


Racha Conta gerado atravs do Android Studio. E o app est
oficialmente publicado no Google Play! Daqui em diante, todas as
futuras publicaes sero automatizadas. Assim, vamos configurar o
processo.

Para permitir publicaes de apps por ferramentas, em vez de


seres humanos, necessria a gerao do service account. Ele
permite com que servidores automatizados, tais como o Jenkins,
faam uso da Google Play Developer Publishing API para a
publicao de apps no Google Play. Para ter acesso seo para a
gerao de um service account, no Google Play Developer Console,

134 4.5 PUBLICAO NO GOOGLE PLAY


selecione a opo de menu Settings > API access .

Informaes mais detalhadas sobre como gerar um service


account podem ser consultadas em:
https://developers.google.com/android-
publisher/getting_started.

Uma vez finalizado o processo de gerao, ser disponibilizado o


e-mail do service account e um arquivo com extenso .p12 , que se
trata de uma chave.

Figura 4.60: E-mail do service account

J a chave p12 deve ser colocada na raiz do projeto do aplicativo


Racha Conta.

4.5 PUBLICAO NO GOOGLE PLAY 135


Figura 4.61: Chave p12

Outra configurao a ser definida o conjunto de permisses


que a ferramenta automatizada estar habilitada a exercer sobre a
API de publicao. O conjunto mnimo de permisses para
viabilizar a publicao de um app no Google Play deve ser setada
desta forma:

Figura 4.62: Permisses para o service account

136 4.5 PUBLICAO NO GOOGLE PLAY


Prosseguindo com as configuraes, chega-se etapa de
obteno e aplicao do plugin gradle-play-publisher ao projeto do
aplicativo. No arquivo build.gradle , em nvel de projeto, o
plugin deve ser obtido atravs da seguinte configurao:

Figura 4.63: Obteno do plugin gradle-play-publisher

Em seguida, esse plugin deve ser aplicado ao projeto no arquivo


build.gradle , em nvel de mdulo.

Figura 4.64: Aplicao do plugin gradle-play-publisher

Nesse mesmo arquivo build.gradle , deve ser configurado o


bloco play . Esse bloco deve conter o e-mail do service account e a
referncia para a chave p12.

Figura 4.65: Configurao do bloco play

4.5 PUBLICAO NO GOOGLE PLAY 137


Como mostrado na figura anterior, o e-mail do service account
estar parametrizado na configurao do build da ferramenta de
integrao, pois esse trata-se de um dado sigiloso que
recomendado no estar literalmente exposto no build.gradle .

Por fim, devem ser configurados os metadados referentes ao app


para exibio no Google Play. Metadados estes que tratam de
informaes exibidas ao usurio do app quando este estiver
interessado em mais informaes sobre o aplicativo, como a
descrio do app, imagens de telas do app em execuo, vdeo, e-
mail de contato etc.

Os metadados devem ser dispostos sobre folders especficos


dentro do projeto do aplicativo. A seguir, mostrado que as ltimas
alteraes sobre o app devem ser descritas no arquivo whatsnew
no local especificado:

Figura 4.66: Recentes alteraes sobre o app

Os folders de armazenamento de outros metadados podem ser


consultados no GitHub do plugin gradle-play-publisher. E isso!

138 4.5 PUBLICAO NO GOOGLE PLAY


Sim, todas as configuraes para publicao automatizada de um
app Android no Google Play foram definidas.

Para o prximo build sobre o app, o plugin gradle-play-publisher


criar um conjunto de tasks Gradle. A mais importante delas a
task publishApkRelease . Ela realiza o upload do apk e recentes
alteraes sobre o app (contidas no arquivo whatsnew ) para o
Google Play. Essa task, como j mostrado anteriormente, invocada
pelas ferramentas de integrao, tal que seja possvel a elas
publicarem um app ao final de um pipeline de integrao contnua.

Criei um projeto de app Android do zero, implementei uma srie


de testes unitrios, de integrao, algumas regras de anlise esttica
de cdigo, testes funcionais, subi todos eles para o GitHub, configurei
a ferramenta de integrao para monitorar a estabilidade e validao
do meu app e, ento, publiquei-o para o Google Play atravs de um
pipeline de entrega contnua. E agora?

Opa! Meus parabns! Se voc chegou at aqui, tenha em mente o


seguinte: voc agregou valor a seu app. Custo menor; confiabilidade
sobre o app; maior proteo contra regresses; feedback rpido em
caso de falha na integrao; tarefas repetitivas automatizadas e
tarefas de criao para o desenvolvedor.

O Google Play uma possvel alternativa para publicao de


apps Android. Existem outras. O prximo captulo tratar disso. So
os mecanismos de distribuio denominados over-the-air.

4.5 PUBLICAO NO GOOGLE PLAY 139


CAPTULO 5

DISTRIBUIES OVER-
THE-AIR

Imagine uma pessoa diante de uma espcie de painel de


operaes em um website. Nesse painel, em um submenu, est
disponvel a opo Instalar aplicativo . Ao selecionar essa
opo, o operador se depara com a possibilidade de realizar o
upload de um arquivo correspondente a um app mobile, uma lista
de nomes de dispositivos (smartpthones e tablets) e um boto
Instalar .

O operador realiza o upload do app, um dispositivo em especial


selecionado o do prprio operador e pressionado o boto
Instalar . E a seguinte mensagem exibida no painel: App
instalado no(s) dispositivo(s) com sucesso. Ento, o operador tira seu
smartphone do bolso e, como um "passe de mgica", o novo app est
instalado e disponvel para uso no launcher do dispositivo.

O operador era eu mesmo em 2012. At ento, com o mercado


de mobilidade recm-despontando. No tinha noo de que algo
assim era possvel de ser feito. Hoje, muitos ainda no conhecem
sobre essa possibilidade.

5.1 O CONCEITO
Uma distribuio over-the-air (OTA) um mecanismo de
instalao (ou atualizao) de sistemas (ou apps) sobre rede sem fio.

140 5 DISTRIBUIES OVER-THE-AIR


Ou seja, no necessria a conexo do dispositivo mobile com um
host via cabo para a transferncia do software.

Atualizaes do sistema operacional Android em dispositivos


podem ser categorizadas como over-the-air, assim como
atualizaes de apps. Elas podem ser instalados/atualizados via over-
the-air de diferentes formas. A primeira realizada pelo despacho
de um app atravs do site do Google Play, em que o usurio deve
estar autenticado com sua conta do Google e um dispositivo mobile
associado a ela.

Figura 5.1: Over-the-air 1

Outra categoria de distribuio over-the-air faz uso de polling.


Atravs desse mecanismo, uma entidade faz consultas peridicas a
outra entidade para verificar uma possvel alterao de um status de
interesse.

Um app instalado em um dispositivo Android pode estar


associado a um servio sendo executado em background que realiza
consultas a um status contido em um servidor. Nesse caso, o status

5.1 O CONCEITO 141


de interesse seria o nmero da verso do app, de modo que, uma vez
que a verso tenha sido incrementada e, logo, o app atualizado, uma
distribuio over-the-air ativada e o app atualizado enviado ao
dispositivo para que seja, em seguida, instalado nele.

Figura 5.2: Over-the-air 2

Um meio pelo qual tambm possvel realizar distribuies


over-the-air se d por ferramentas que, alm de conter essa
funcionalidade de distribuio, contm um aparato para
monitoramento de trfego de informaes sobre apps. O
mecanismo dessas ferramentas responsvel pela distribuio de
apps conhecido como mdulo de distribuio beta. As
ferramentas permitem que um operador despache um novo app, ou
sua atualizao, para um dispositivo ou um grupo de dispositivos
previamente selecionado.

142 5.1 O CONCEITO


Figura 5.3: Over-the-air 3

Apesar de ser beta em seu nome, no necessariamente a verso


do app distribudo necessita ser beta. O nome vem do conceito
de o app ser enviado a um conjunto de testadores em um
ambiente controlado. Porm, permitido distribuir apps em
um ambiente controlado de usurios finais. Ainda neste
captulo, sero tratadas duas ferramentas que dispem dessas
funcionalidades: o HockeyApp e o Crashlytics.

5.2 REQUISITOS PARA ATUALIZAES OTA


Uma vez que a distribuio via over-the-air de um app
realizada, deve-se ter em mente um aspecto fundamental: arquivos
do dispositivo-alvo sero modificados. Logo, o mecanismo pelo qual
ser efetuada essa distribuio deve, preferencialmente, atender ao
conjunto de requisitos. Isso de modo que, aps a instalao do app,

5.2 REQUISITOS PARA ATUALIZAES OTA 143


Mas o que isso significa? Digamos que um usurio do app,
obtido via HockeyApp, enquanto esteja interagindo com o app em
seu smartphone, ao pressionar um boto se depara com o seguinte
alerta:

Figura 5.4: O app parou

Imediatamente, sero disparados para o HockeyApp detalhes do


stacktrace da aplicao que vo auxiliar o desenvolvedor a
compreender a causa do bug encontrado. Alm disso, fornecida
pela soluo uma poro de mtricas que auxiliam no
monitoramento do ciclo de vida da aplicao, como nmero total de
usurios da aplicao, nmero total de crashes, nmero de novos
usurios por dia, dentre outras.

Figura 5.5: Mtricas de usurio HockeyApp

5.3 HOCKEYAPP 145


A soluo HockeyApp est disponvel em
https://www.hockeyapp.net.

Distribuindo apps via HockeyApp (sem CI)


Um app pode ser distribudo via HockeyApp para apenas um
usurio. Porm, comum a prtica de criao de times de usurios,
tal que, uma vez que uma nova verso de um app Android esteja
disponvel, seja possvel a escolha de qual time de usurios receber
essa nova verso. E essa categoria de distribuio que ser
abordada tendo em vista que se trata de uma prtica muito comum
na indstria de apps mobile.

Ser demonstrada uma distribuio sem CI (Continuous


Integration) primeiramente, para, na seo posterior, o mesmo
mecanismo ser tratado atravs do estgio de publicao de um
pipeline automatizado de CI.

Em primeiro lugar, deve ser criada uma conta de administrador


no HockeyApp. Ento, ser acessvel o painel de gerenciamento de
apps. Atravs dele, ser registrado um novo app.

Figura 5.6: Distribuindo app via HockeyApp (etapa 1)

146 5.3 HOCKEYAPP


Ser requerido que seja realizado o upload de um arquivo apk
de release (no captulo 4, h um passo a passo de como ger-lo).
Ento, ser solicitado que seja dada a autorizao para que o app
esteja disponvel para download.

Figura 5.7: Distribuindo app via HockeyApp (etapa 2)

Assim, o app estar devidamente registrado, e todas atividades


realizadas sobre ele por usurios devidamente monitoradas.

Figura 5.8: Distribuindo app via HockeyApp (etapa 3)

Em seguida, deve ser criado um novo time de usurios.

5.3 HOCKEYAPP 147


Figura 5.9: Distribuindo app via HockeyApp (etapa 4)

Figura 5.10: Distribuindo app via HockeyApp (etapa 5)

Ao ser criado o time, j possvel a adio de novos membros a


ele.

148 5.3 HOCKEYAPP


Figura 5.11: Distribuindo app via HockeyApp (etapa 6)

Uma vez com o time criado, ele deve ser registrado na lista de
membros a serem notificados quando uma nova verso do app
estiver disponvel para download.

5.3 HOCKEYAPP 149


Figura 5.12: Distribuindo app via HockeyApp (etapa 7)

Figura 5.13: Distribuindo app via HockeyApp (etapa 8)

150 5.3 HOCKEYAPP


Figura 5.14: Distribuindo app via HockeyApp (etapa 9)

Figura 5.15: Distribuindo app via HockeyApp (etapa 10)

5.3 HOCKEYAPP 151


Figura 5.16: Distribuindo app via HockeyApp (etapa 11)

Quando o app atualizado, usurios sero notificados por e-


mail sobre a nova atualizao. Porm, na primeira notificao, ser
solicitado ao usurio para que ele cadastre-se no HockeyApp e
tambm o dispositivo usado por ele para uso do app.

152 5.3 HOCKEYAPP


Figura 5.17: Distribuindo app via HockeyApp (etapa 12)

Estando o dispositivo registrado, o usurio ter acesso ao app


Android do HockeyApp, pois esse ser o meio pelo qual esse
usurio ter acesso a novas verses distribudas de apps de seu
interesse.

5.3 HOCKEYAPP 153


Figura 5.18: Distribuindo app via HockeyApp (etapa 13)

Por fim, o usurio pode acessar novas atualizaes a cada vez


que elas estiverem disponibilizadas, via o app HockeyApp.

Figura 5.19: Distribuindo app via HockeyApp (etapa 14)

Distribuindo apps via HockeyApp (com CI)


Seria preciso a gerao e publicao manual dessa atualizao
toda vez que fosse necessrio distribuir uma nova atualizao de app
sem um mecanismo automatizado. um processo tedioso e sujeito
a erros.

154 5.3 HOCKEYAPP


Mas agora com diverso! possvel configurar o estgio de
publicao em um servidor de CI para que esse despache uma nova
atualizao de app Android para usurios via HockeyApp.

Para viabilizar esse mecanismo automatizado, ser usado o


gradle-hockeyapp-plugin. Trata-se de um plugin open source que
facilita a implantao desse mecanismo.

Mais informaes sobre o plugin podem ser obtidas em


https://github.com/x2on/gradle-hockeyapp-plugin.

O plugin configurado pelos arquivos build.gradle em


nveis de mdulo e projeto do app. No build.gradle , em nvel de
projeto, deve ser adicionada a seguinte dependncia:
classpath 'de.felixschulze.gradle:gradle-hockeyapp-plugin:3.4'

J no build.gradle , em nvel de mdulo, deve ser aplicado o


plugin e definidas suas configuraes.
apply plugin: 'de.felixschulze.gradle.hockeyapp'

hockeyapp {
apiToken = System.getenv("HOCKEY_APP_API_TOKEN")
notify = 1
teams = 72599
}

O atributo apiToken pode ser obtido a partir da seo de


configuraes de conta do HockeyApp.

5.3 HOCKEYAPP 155


Figura 5.20: Obtendo o token de API

Deve ser concedido direitos de upload e release ao token.

Voltando ao build.gradle , o atributo notify permite com


que, sempre que haja uma nova atualizao do app tratado, o
usurio seja notificado sobre isso. J o atributo teams especifica
para quais times deve ser distribuda a nova atualizao. O
identificador dos times pode ser obtido atravs da URL (mostrada
na barra de endereos do navegador) quando aberto o painel de
informaes sobre esse time.

Figura 5.21: Identificador do time de usurios

Agora necessria a configurao do estgio de publicao no


servidor de CI. Ele ser configurado no Jenkins. Porm, poderia ser
configurado em quaisquer das ferramentas de integrao contnua
tratadas neste livro.

O job associado ao estgio


levar o nome de
RachaContaAndroidPublishHockeyApp . Muitas das configuraes
do job so as mesmas usadas pelo job
RachaContaAndroidPublish , tratado no captulo anterior, mas

156 5.3 HOCKEYAPP


com alguns detalhes adicionais. Na seo sobre parametrizao do
build, deve ser definido o token de API do HockeyApp.

Figura 5.22: Configurando o token de API no Jenkins

Por fim, deve ser


configurada a task
uploadReleaseToHockeyApp , responsvel pela
publicao/distribuio do app via HockeyApp.

Figura 5.23: Configurao da task de publicao do HockeyApp

Sendo assim, quando disparada a execuo do pipeline de


deployment, todos os usurios pertencentes ao time definido no
arquivo build.gradle sero notificados da existncia de uma
nova atualizao do app. Isso faz do processo de distribuio menos
tedioso e mais confivel, pela falta de necessidade de interveno
humana.

5.4 CRASHLYTICS
5.4 CRASHLYTICS 157
Assim como o HockeyApp, esta plataforma hospedada na
nuvem e trata-se de um kit de solues de crash reporting, analytics
e de distribuio de apps com enfoque em plataformas mveis. Ele
faz parte de um conjunto maior de ferramentas denominado Fabric,
pertencente ao Twitter.

Porm, apesar da diversidade de solues fornecidas atravs do


Crashlytics, estamos interessados, nesta publicao, em saber como
entregar software Android da melhor forma possvel. E a soluo do
kit que permite que isso seja possvel tem o nome de Beta by
Crashlytics.

Figura 5.24: Dashboard do Beta by Crashlytics

A figura anterior retrata o dashboard de monitoramento de


atividades sobre um app especfico. Uma vez que um app Android
distribudo a usurios, todas as atividades relevantes ocorridas sobre
o app sero expostas sobre esse dashboard. Uma atividade de
interesse , uma vez que um app tenha sido distribudo, como saber
se esse app j foi instalado por algum de seus usurios?

158 5.4 CRASHLYTICS


Figura 5.25: Dissecando o Beta by Crashlytics 1

O subpainel anterior exibe no somente a resposta para a


pergunta anterior como tambm informaes adicionais, tais como:

1. Total de usurios habilitados a receberem distribuies do


app.
2. Total de convites enviados, total de convites aceitos, total de
usurios que instalaram o app, total de usurios que j
utilizaram o app e total de issues detectadas no app,
respectivamente.
3. Lista dos usurios habilitados a receberem distribuies do
app.

Outro subpainel do dashboard exibe no somente crashes


detectados sobre o app, como tambm a classe e a linha no cdigo-
fonte em que um bug foi manifestado.

5.4 CRASHLYTICS 159


Figura 5.26: Dissecando o Beta by Crashlytics 2

O ltimo subpainel fornece informaes sobre as ltimas


distribuies recebidas e operadas por usurios do app de interesse.

Figura 5.27: Dissecando o Beta by Crashlytics 3

O kit de solues Crashlytics pode ser acessado em


http://try.crashlytics.com/.

Distribuindo apps via Crashlytics (sem CI)


Para distribuir um app Android via Crashlytics, primeiramente

160 5.4 CRASHLYTICS


necessrio o cadastro de uma conta de administrador no site da
soluo.

A seguir, acessando a opo de menu File > Settings , deve


ser selecionada a seo Plugins . Depois, o boto Browse
repositories... deve ser pressionado. Ento, deve ser feita a
busca por "Fabric for Android Studio", para que o plugin do Fabric
seja integrado ao Android Studio.

Figura 5.28: Instalando plugin do Fabric

Ser solicitado que o Android Studio seja reiniciado. Em


seguida, o Crashlytics ser integrado ao projeto do app. Porm, em
vez da necessidade de definir configuraes nos arquivos
build.gradle manualmente, o plugin do Fabric facilita (e muito)
essa tarefa, pois ele analisa cada arquivo que dever sofrer alteraes

5.4 CRASHLYTICS 161


para adio do Crashlytics e, automaticamente, adiciona as
instrues necessrias aos arquivos. Para isso, o plugin do Fabric
deve ser acessado, ou pela barra de menu do Android Studio, ou de
seu menu lateral.

Figura 5.29: Acesso ao plugin do Fabric

Uma vez acessado, basta confirmar a adio proposta pelo


plugin.

Figura 5.30: Adio de configurao para o Crashlytics

E o projeto est preparado para distribuio a usurios via

162 5.4 CRASHLYTICS


Crashlytics. Para essa distribuio ocorrer, o app de interesse dever
ser executado, no mnimo, uma vez para que seja registrado no
Crashlytics e, ento, arrastado sobre o painel disponibilizado pelo
plugin do Fabric.

Figura 5.31: Distribuindo app via Crashlytics

E para quais usurios dever ser distribuda a nova verso do


app? o que a prxima tela do painel do plugin solicitar. E isso se
d atravs do fornecimento do e-mail desses usurios.

5.4 CRASHLYTICS 163


Figura 5.32: Definindo usurios de app no plugin do Fabric

Aps a confirmao dos usurios, o app ser distribudo a eles. E


cada usurio receber o convite pra uso desse app em sua caixa de e-
mail.

164 5.4 CRASHLYTICS


Figura 5.33: Recebimento do convite para uso do app via Crashlytics

Atravs desse e-mail, o usurio estar habilitado a realizar o


download do app Android "Beta by Crashlytics", pois por ele que
todos os apps distribudos via Crashlytics estaro disponveis aos
seus usurios. Logo, pelo e-mail, usurios sero direcionados ao
navegador para obter o Beta by Crashlytics.

5.4 CRASHLYTICS 165


Figura 5.34: Download do Beta by Crashlytics

Uma vez instalado o Beta by Crashlytics no dispositivo mobile


do usurio, ele ter acesso ao app distribudo.

Figura 5.35: Download do app via Beta by Crashlytics

Distribuindo apps via Crashlytics (com CI)

166 5.4 CRASHLYTICS


Nossa empresa faz, em mdia, dez deploys por dia para grupos de
usurios. O processo ainda no automatizado, mas, em breve, ser..
Pobre do responsvel por essa tarefa. Relembrando o processo de
distribuio: gerar a nova verso do app; arrast-la at o painel do
plugin do Crashlytics; selecionar os usurios-alvo; e, finalmente,
despachar o app. Isso, dez vezes ao dia. 50 vezes toda semana. 200
vezes por ms. um absurdo!

Tenha sempre em mente: mquinas so excelentes para


realizarem tarefas repetitivas. Ento, vamos automatizar as
distribuies!

Para exemplificar a automatizao de uma distribuio via


Crashlytics, vamos configur-la para distribuir apps para um grupo
de usurios (assim como exemplificado na seo sobre HockeyApp).
Ento, um grupo de usurios ser criado no dashboard do Beta by
Crashlytics. Ele ser nomeado Racha Conta Testers e um
usurio adicionado a ele. Contudo, o grupo poderia ter dezenas de
usurios, caso necessrio, de modo que todos eles seriam notificados
a cada nova verso distribuda para o grupo.

Um novo diretrio ser criado na raiz do projeto do app no


Android Studio e ser nomeado crashlytics . Esse diretrio
conter informaes para viabilizar a distribuio do app via
Crashlytics de forma automatizada.

Figura 5.36: Definindo configuraes para distribuio automatizada via Crashlytics

O arquivo release_notes.txt contm as novidades na nova


verso do app a ser distribuda. A cada nova distribuio ele dever
ser atualizado (caso necessrio). J o arquivo group_aliases.txt

5.4 CRASHLYTICS 167


conter os identificadores dos grupos de usurios (separados por
vrgula) que recebero a distribuio. Esse identificador trata-se de
um alias, que pode ser obtido atravs do dashboard do Beta by
Crashlytics, na opo de menu Manage Groups .

Figura 5.37: Alias do grupo de usurios

Tambm no arquivo build.gradle . em nvel de mdulo,


devem ser apontados os arquivos group_aliases.txt e
release_notes.txt , para que a task Gradle de distribuio
conhea as configuraes desse processo de distribuio. O seguinte
trecho de cdigo deve ser adicionado ao corpo do build type de
interesse:
ext.betaDistributionGroupAliasesFilePath="${rootProject.getRo
otDir()}/crashlytics/group_aliases.txt"
ext.betaDistributionReleaseNotesFilePath="${rootProject.getRo
otDir()}/crashlytics/release_notes.txt"

Assim como realizado para o HockeyApp, ser configurado um


job no Jenkins para deployar novas distribuies para grupos de
usurios. O job contm todas as configuraes iguais ao job
RachaContaAndroidPublishGooglePlay , com a exceo da
configurao da task, que deve ser executada durante o build. Neste
caso, ser a task crashlyticsUploadDistributionRelease .

168 5.4 CRASHLYTICS


Figura 5.38: Configurao da task de publicao do Crashlytics

Deste modo, a cada nova alterao enviada sobre o projeto do


app para o repositrio de cdigo remoto, ao final do pipeline de
deployment, um estgio de nome
RachaContaAndroidPublishCrashlytics ser responsvel por
distribuir o app via Crashlytics.

5.5 CONCLUSO
Se voc chegou aqui, parabns! Voc sabe implementar um
pipeline de deployment para apps Android. Entrega contnua?
Depende. Trata-se uma prtica. O time de desenvolvimento deve
querer lev-la ao p da letra em seu dia a dia.

O build do app foi quebrado? Por acaso o time dedicou toda sua
ateno em consertar o build e "rebuildar" a aplicao? O build
terminou com sucesso e foi decidido publicar o app para o Google
Play? E toda vez que ocorre uma quebra, esses passos so repetidos?

E se uma nova funcionalidade agregada ao app, testes


automatizados so escritos para cobrir esse cenrio com um novo
build sendo processado atravs do pipeline, como forma a detectar

5.5 CONCLUSO 169


uma possvel regresso? O build foi um sucesso novamente? E foi
decidido j publicar o artefato resultante desse build? E a postura do
time a mesma vrias vezes ao dia durante todo o ciclo de vida da
aplicao?

Meus parabns! Bem-vindo entrega contnua em Android. :)

170 5.5 CONCLUSO


CAPTULO 6

BIBLIOGRAFIA

ANICHE, M. Test-Driven Development: Teste e Design no


Mundo Real. So Paulo: Casa do Cdigo, 2012.

BAPTISTA, V. Continuous Integration for Android Apps with


Jenkins and Maven3. Jul. 2011. Disponvel em:
http://vitorbaptista.com/continuous-integration-for-android-apps-
with-jenkins-and-maven3/. Acessado em: 14 fev. 2016.

BRISON, V. How to Improve Quality and Syntax of Your


Android Code. Jul. 2014. Disponvel em:
http://vincentbrison.com/2014/07/19/how-to-improve-quality-and-
syntax-of-your-android-code/. Acessado em: 29 abr. 2016.

CADET, A. Android Continuous Integration Using Gradle,


Android Studio and Jenkins. Mar. 2015. Disponvel em:
https://www.coshx.com/blog/2015/03/31/android-continuous-
integration-using-gradle-android-studio-and-jenkins/. Acessado
em: 17 abr. 2016.

COHN, M. User Stories Applied: For Agile Software


Development. Boston: Pearson Education, 2004.

COMPTON, M. Continuous Delivery for Android. Fev. 2015.


Disponvel em: https://www.bignerdranch.com/blog/continuous-
delivery-for-android/. Acessado em: 28 mar. 2016.

CONTINUOUSAGILE.COM. Continuous Stories - Mobile App.

6 BIBLIOGRAFIA 171
Disponvel em:
http://www.continuousagile.com/unblock/cd_mobile.html.
Acessado em: 02 mar. 2016.

DRIESSEN, V. A Successful Git Branching Model. Jan. 2010.


Disponvel em: http://nvie.com/posts/a-successful-git-branching-
model/. Acessado em: 03 abr. 2016.

DUVALL, P. M.; MATYAS S.; GLOVER, A. Continuous


Integration: Improving Software Quality and Reducing Risk.
Boston: Pearson Education, 2007.

HAMBRICK, R. Continuous Delivery for Android (Part 1). Dez.


2014. Disponvel em: http://blog.stablekernel.com/continuous-
delivery-android-part-1/. Acessado em: 15 mar. 2016.

HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable


Software Releases Through Build, Test, and Deployment
Automation. Boston: Pearson Education, 2010.

MAAS, E. L. Automating Android Development. Mai. 2015.


Disponvel em: https://medium.com/google-developer-
experts/automating-android-development-
6daca3a98396#.d57bdpfro. Acessado em: 23 abr. 2016.

MARTINEZ, J. Use GoCD for Android and Get Rid of Jenkins.


Abr. 2016. Disponvel em: http://jeremie-
martinez.com/2016/04/19/gocd-android/?
utm_source=androiddevdigest. Acessado em: 11 jun. 2016.

ROMER, T. Using Jenkins to Build Pipelines, Chain and


Visualize Jobs. Maio 2014. Disponvel em:
http://zeroturnaround.com/rebellabs/how-to-use-jenkins-for-job-
chaining-and-visualizations/#outofthebox. Acessado em: 15 abr.
2016.

172 6 BIBLIOGRAFIA
SWANSON, M. Integration Testing against REST APIs in
Android. Fev. 2014. Disponvel em:
http://mdswanson.com/blog/2014/02/24/integration-testing-rest-
apis-for-android.html.

6 BIBLIOGRAFIA 173