Essa é a terceira parte de uma série 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 artigo, 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 no blog da Concrete Solutions tem uma série a respeito (veja aqui) e tem um artigo legal da Carol Almeida reunindo as dicas para quem quer aprender sobre (olhe 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 e se você quiser saber mais, tem uma lista legal aqui.

Para esse artigo, 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 tTravis, a gente precisa primeiro criar um arquivo .travis.yml:

language: objective-c
osx_image: xcode8.1
cache:
- bundler
- cocoapods
before_install:
- bundle install
- bundle exec pod keys set MarvelApiKey $MARVEL_API_SECRET Marvel
- bundle exec pod keys set MarvelPrivateKey $MARVEL_API_PUBLIC Marvel
- pod repo update
script:
- fastlane test
- bundle exec danger
env:
  global:
  - secure: somethingScretAndEncryptLike93890329009302uehn32jhn3jk2h4jk32h4j329489032849032u904u3209432b
  - secure: somethingElseScretAndEncryptLike93890329009302uehn32jhn3jk2h4jk32h4j329489032849032u904u3209432b

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:

gem install travis

Login usando a gem do Travis:

travis login

Criptografar:

travis encrypt MARVEL_API_PRIVATE={YOUR_KEY} --add

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

Criar uma conta no Travis e escolher o repositório:

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

O Travis é bastante customizável e 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. Também vale mencionar que você pode ver que na fase de script do Travis podemos só chamar duas coisas:

script:
- fastlane test
- bundle exec danger

A primeira delas:

- fastlane test

É o nosso pipeline automatizado, aquele que criamos na parte 02. 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 diversas outras coisas. Existem muitos tutoriais na internet sobre todos esses tópicos, é só dar uma olhada.

O importante aqui é que, 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:

- bundle exec danger

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

Danger Systems

O 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.

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 na Concrete.

O meu Dangerfile é esse:

# Sometimes it's a README fix, or something like that - which isn't relevant for
# including in a project's CHANGELOG for example
declared_trivial = github.pr_title.include? "#trivial"
 
# Make it more obvious that a PR is a work in progress and shouldn't be merged yet
warn("PR is classed as Work in Progress") if github.pr_title.include? "[WIP]"
 
# Warn when there is a big PR
warn("Big PR") if git.lines_of_code > 500
 
message("Test Comment on PR")
# Don't let testing shortcuts get into master by accident
# fail("fdescribe left in tests") if `grep -r fdescribe specs/ `.length > 1
# fail("fit left in tests") if `grep -r fit specs/ `.length > 1
 
# Slater config
slather.configure("Marvel.xcodeproj", "Marvel", options: {
  workspace: 'Marvel.xcworkspace',
  output_directory: "coverage",
  ignore_list: [
    "**/Storyboard.swift",
    "**/MarvelAPI.swift",
    "**/MarvelAPIManager.swift"
  ],
  ci_service: :travis,
  coverage_service: :terminal,
})
 
slather.notify_if_coverage_is_less_than(minimum_coverage: 80)
slather.notify_if_modified_file_is_less_than(minimum_coverage: 60)
slather.show_coverage

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

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:

• Baby Steps;
• Comece pequeno e parta daí;
• Assim que você atingir um ponto desejado, commit (salve as mudanças) e passe para o próximo ponto;
• Não tente configurar tudo de uma vez, porque esse é o caminho para o fracasso;
• Teste sua configuração, constantemente. Mudanças feitas e não testadas são outra receita para o desastre.

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

Dicas para o Danger

• Crie outra conta do Github;
• Fork seu repo;
• Envie PRs usando essa outra conta.

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 parte, vamos falar sobre como fazer UIs melhores usando o 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!

***

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

***

Artigo publicado originalmente em: http://www.concretesolutions.com.br/2017/01/06/app-ios-marvel-inicio-parte-3/