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/