Esse post foi originalmente publicado (em inglês) na Cocoa Academy, no Medium. Veja aqui.

Essa é a terceira parte de uma série de posts sobre como criar um app iOS do início usando diversas pods e ferramentas que farão a sua vida muito mais fácil. Se você perdeu o começo da série, pode clicar aqui para a primeira parte e aqui para a segunda. Hoje, o assunto vai ser integração contínua, Danger e Fastlane.

O código deste projeto está neste repositório. Eu criei uma tag para esse post, que é a v0.3, então você só precisa clonar o repo e trocar para  a tag v0.3. Vamos lá?

Integração Contínua

Integração Contínua (ou CI, na sigla em inglês, é um assunto bem extenso. Tem uma série de tutoriais e livros sobre isso, inclusive temos uma série aqui no Blog (veja aqui) e tem um post legal da Carol Almeida reunindo as dicas para quem quer aprender sobre (olha aqui). Apesar do número de materiais, o conceito é relativamente simples:

Integrar seu código o mais frequentemente possível para achar bugs mais cedo, antes da entrada em produção.

O site da ThoughtWorks define assim (minha tradução):

“Integração Contínua (CI) é uma prática de desenvolvimento que requer que os desenvolvedores integrem seus códigos em um repositório compartilhado várias vezes ao dia. Cada check-in é verificado por um build automatizado, permitindo que times detectem problemas mais cedo. Integrando regularmente você pode detectar erros mais rápido e resolvê-los mais facilmente”

Martin Fowler, por sua vez, diz (tradução minha):

“Integração contínua não te livra dos bugs, mas faz com que eles fiquem muito mais fáceis de achar e remover”.

Depois dessa introdução, vamos a mais algumas informações sobre o assunto.

Basicamente, nós temos que ter um “sentinela” para manter um olho no nosso repositório e rodar um processo de build | teste | deploy automatizado sempre que algo mudar. Esse “sentinela” é um servidor de CI. Eles existem em todos os tamanhos e formatos, se você quiser saber mais tem uma lista legal aqui. Para esse post eu vou usar o Travis, um CI que funciona muito bem com o github e que por isso é a principal escolha para projetos open source.

Travis

Para usar o travis a gente precisa primeiro criar um arquivo .travis.yml.

Você pode notar que nosso build está usando uma variável chamada $MARVEL_API_PRIVATE. Precisamos definir isso porque estamos usando cocoapods-keys, e elas precisam dessa informação durante o tempo de build. Alguém poderia simplesmente colocar o valor dentro do .travis.yml, mas vamos tentar tornar o roubo da nossa api key um pouco mais difícil usando criptografia. Nós podemos criptografar uma variável usando a gem ruby do Travis. Mas antes vamos instalar:

Login usando a gem do Travis:

Criptografar:

Podemos usar essa abordagem para qualquer outra variável que precisarmos durante o build.

 

Criando uma conta no Travis e escolher o repositório

lioy1

Isso é tudo, depois você pode checar seus builds toda vez que aparecer um novo push ou pull request no seu repositório.

lioy2

O Travis é bastante customizável, você pode achar diferentes configurações e eles têm uma documentação bem extensa sobre o assunto. Eu recomendo começar com uma simples e partir daí. Também vale mencionar que você pode ver que na fase de script do Travis podemos só chamar duas coisas:

A primeira delas:

 

É o nosso pipeline automatizado, aquele que criamos na parte 2. Para o nosso exemplo só vamos rodar testes e gerar cobertura, mas tem muita coisa a mais que podemos fazer. O Fastlane pode automatizar todo o seu pipeline, com testes, build, deploy, gerar e subir screenshots, mandar notificações e mais diversas outras cosias. Existem muitos tutoriais na internet sobre todos esses tópicos, é só dar uma olhada. O importante aqui é uma vez que o script do fastlane esteja rodando  na nossa máquina de desenvolvedor, rodá-lo no CI é realmente muito fácil. Tudo o que precisamos é chamar a lane do Fastlane (nosso “teste”, por exemplo) e pronto.

Lembre-se: antes tenha certeza que você tem seu pipeline automatizando funcionando localmente e depois leve ao CI. Isso pode economizar algumas horas.

A segunda:

Danger é um ferramenta que nos permite automatizar partes do code review… Vamos descobrir como.

Danger Systems

Danger é uma nova ferramenta incrível criada pelo orta, pelo Felix Krause e alguns outros ótimos desenvolvedores.

“Danger funciona durante o seu processo de Integração Contínua, e dá aos times a chance de automatizar tarefas comuns de code review. Isso inclui outro passo lógico no seu build, por meio do qual o Danger pode ajudar nas suas tarefas diárias. Você pode usar o Danger para codificar as regras do seu time, deixando humanos pensarem em problemas mais difíceis. A ferramenta deixa mensagens dentro dos seus pull requests baseadas em regras que você cria com Ruby. Ao longo do tempo, conforme novas regra são adicionadas, a mensagem é alterada para refletir o estado atual do code review” – Danger Systems (minha tradução)

Você pode achar um guia de “Getting Started” e um monte de exemplos diferentes de DangerFile no site. A documentação cobre quase tudo o que precisamos, mas vou mencionar alguns pontos que acho que merecem um lembrete.

Também é preciso:

– Criar um usuário bot no github. Você tem que criar outro usuário, para usá-lo como um bot;

– Criar um token para o usuário Bot, permitindo que ele comente no seu repositório. Crie o token aqui. Para projetos open source o bot deve ter só uma permissão public_repo.

– Registrar o token no Travis, isso ainda não está bem documentado.

lioy3 lioy4

Você precisa adicionar uma variável de ambiente chamada DANGER_GITHUB_API_TOKEN contendo um valor para seu Token do Bot. E não esquece de escolher a opção “Display value in build log” antes de clicar em Add.

Dangerfile

Para esse projeto estou usando uma versão com o plugin slather danger. Ele permite que o Danger use informações de slather dentro do comentário do Pull Request. É um ótimo aprimoramento pro Danger e foi desenvolvido pelo Bruno Mazzo, um excelente desenvolvedor que trabalha comigo aqui na Concrete.

O meu Dangerfile é esse:

Isso vai permitir que nosso bot comente em todos os pull requests com informação de cobertura, como:

lioy5

Não é difícil configurar tudo isso no seu projeto, mas tem alguns pontos meio complicados no caminho. Então, vamos a algumas dicas:

Tricks of the trade

Quando estamos falando sobre setup, CI, testes, build e todo esse tipo de coisa, tem alguns princípios que podem ajudar bastante na sua jornada:

Esses princípios simples podem impedir um monte de dor de cabeça.

Dicas para o Danger

Eu passei muito tempo criando pull requests de branchs dentro do meu repositório, como a mesma conta que criou o repo, e eles não são tratados pelo Danger ou pelo Travis como um pull request. Embora sejam listados como PR’s pelo github, e isso pode criar um pouco de confusão.

Resumindo

Chegamos ao fim da terceira parte da nossa série. Na próxima semana, vamos falar sobre como fazer UIs melhores usando o Sketch, Sketch para desenvolvedores. Também vou mostrar como fazer sua página do Github se destacar melhorando o README com badges, cobertura de código, fotos e um monte de coisas legais.

Nosso repo ficará lindo…  $)

Como sempre, opiniões dúvidas e feedbacks são mais que bem-vindos. =) Até a próxima!

É desenvolvedor iOS e quer trabalhar em um time ágil de verdade? Clique aqui.

Sobre o Autor

Consultor especialista da Concrete Solutions, com grande experiência em mobile, desde apps nativas até híbridas e seus respectivos back-ends. Desenvolvedor iOS/Android e Ruby por hobby. Defensor de métodos ágeis e Lean Thinking, acredita que são uma maneira de sintetizar um processo com passos bem definidos para trazer de volta o bom senso para a indústria de software.

cases

rio de
janeiro

Rua São José, 90
Sala 2121 - Centro
(21) 2240-2030
CEP: 20010-020

são
paulo

Av. Nações Unidas
nº 11.541 - 3º andar
(11) 4119-0449
CEP: 04578-000

belo
horizonte

Av. Getúlio Vargas, 671
Sala 800 - 8º andar
(31) 3360-8900
CEP: 30112-021