Como implementar mobile continuous integration(CI) e delivery(CD) usando bitrise.io

Se você chegou até aqui, vou partir do pressuposto que já sabe o que significa continuos integration(CI) e continuous delivery(CD). Mas se você não sabe, não há problema, vou indicar 2 links, um do Martin Fowler e outro do Jez Humble, as principais referências no mundo para falar sobre essas práticas: Continuous Integration , Continuous Delivery. Também indico o livro Continuous Delivery, dos autores Jez Humble e Dave Farley.

Quem desenvolve aplicativos mobile e gerencia o processo de publicação e liberação de novas versões com certeza sabe o esforço manual de testar, assinar, mudar versão e enviar novos builds para a App Store e para Google Play Store, principalmente se você gera vários builds por dia. Em algum momento, mais cedo ou mais tarde, você irá fazer uma pergunta bem comum: "Como automatizar?".

Felizmente, atualmente existem algumas opções, uma dessas opções poderia ser implementada utilizando Jenkins + Fastlane. Como você chegou até aqui e já sabe o que é CI & CD, provavelmente já conhece ou já ouviu falar de Jenkins, o mordomo responsável por construir, testar e liberar suas novas versões de software enquanto você vai tomar um cafezinho, além de realizar vários outros pedidos. Já o Fastlane é uma ferramenta incrível para automação de várias tarefas "repetitivas e chatas" comuns no processo de desenvolvimento e liberação de apps mobile, criada pelo Felix Krause, foi adquirida pelo Twitter em 2015 e adicionada a suíte de ferramentas de desenvolvimento mobile chamada Fabric, que recentemente foi adquirida pelo Google. Utilizar Jenkins + Fastlane tem como vantagem a maior liberdade e controle para equipe, que estaria utilizando ferramentas open source, podendo ser configuradas da melhor forma em servidores próprios, entretanto tem como desvantagens o custo para manter esses servidores Mac OS X com Xcode para poder realizar builds para iOS.

Depois de muito procurar, acabei encontrando o Bitrise — bitrise.io(Este é meu referral link, mas se não quiser usá-lo, sem problemas pode usar este aqui), uma startup húngara que está desenvolvendo uma ferramenta incrível para implementar CI & CD para aplicações móveis. Decidi testar e simplesmente virei um fã absoluto da plataforma, principalmente devido a sua simplicidade (um belo trabalho de UI/UX) e de seu rápido suporte, aliás, gostaria de fazer um adendo para agradecer ao Viktor Benei, CTO do Bitrise, por algumas vezes precisei sanar algumas dúvidas técnicas e comerciais e fui atendido rapidamente por ele. Com o bitrise nosso pipeline de Continuos Integration e Continuos Delivery ficou assim:

Mas enfim, vamos ao que interessa, como o Bitrise funciona? Como iniciar?

Criar aplicativo e dar acesso ao repositório de código

Iniciar com o Bitrise é relativamente simples. Primeiro você precisa criar um aplicativo no seu dashboard do Bitrise e dar acesso ao seu repositório de códigos. Você pode fazer isso conectando sua conta Github/Bitbucket/Gitlab, neste caso você dará acesso a todos os seus repositórios. Entretanto você também pode adicionar um repositório manualmente, neste caso você precisa adicionar a chave pública do Bitrise em seu repositório, você pode adicionar essa chave nas configurações de seu repositório (Deploy Keys nas configurações do repositório no Github), ou em Access Key (Nas configurações de seu repositório no Bitbucket).

Escolha a branch que será monitorada

Depois você deve escolher a branch que será monitorada, essa branch será utilizada para construir, testar e realizar deploy do seu app.

Configurações de build do projeto

No próximo passo será realizado um scan em seu projeto identificar as melhores configurações de templates de stack(configuração de máquina) e steps(tarefas que serão executadas) para construir seu projeto.

O Projeto que foi utilizado neste artigo foi desenvolvido em Ionic, abaixo podemos ver que ele foi corretamente detectado pelo Bitrise:

Mas caso suas configurações não sejam detectadas corretamente ou não sejam detectadas, você pode tentar escolher manualmente, baseado em alguma das plataformas/framework abaixo.

Se nenhuma das plataformas/framework forem compatíveis com seu projeto, você pode tentar escolher manualmente seu stack e depois você terá que definir seus steps do zero:

Webhook

A última configuração é de Webhook. Em geral essa etapa é ignorada pelo próprio quickstart, mas você pode e deve ativar essa opção nas configurações do seu projeto, caso você queira utilizar os triggers. Veja neste link como ativar webhooks nas configurações de seu projeto.

Quando terminar o quickstart, se as configurações de seu projeto foram detectadas corretamente, você já será capaz de realizar clone, instalar todas as dependências e compilar o seu projeto.

Workflow Editor

Irei falar agora sobre o Workflow Editor, local onde você configura os steps para compilar/testar e fazer deploy/enviar para as lojas (App Store, Google Play Store, etc). No Workflow Editor você também pode adicionar seus certificados/provisioning profiles(iOS) e keystores(Android), criar Variáveis de Ambiente e Secrets, assim como também pode configurar Triggers. Ah! O Workflow Editor, assim como a maioria das ferramentas do Bitrise é Open Source, caso você deseje contribuir ou saber mais informações clique aqui.

Workflow Steps

Para adicionar um novo step basta apenas clicar no ícone "+" na coluna da esquerda do Workflow, na posição do flow que você desejar, existem dezenas de steps criados pela equipe do bitrise e pela comunidade, eles ficam divididos em categorias(Test, Deploy, Notification, etc). Você também pode criar e publicar seu próprio step, clique aqui para saber como. Além disso, os steps podem ser mudados de posição no flow clicando e arrastando, ao melhor estilo Drag & Drop. Você também pode criar vários Workflows em um mesmo projeto, por exemplo, um Workflow de Test que irá executar quando houver um Pull Request e um Workflow de Deploy que irá exercutar quando ocorrer um Push, você pode definir isso em seus Triggers. O Workflow default se chama “Primary”, para criar um novo Workflow basta clicar em "+Workflow".

Code Signing

Para você publicar seu app na Google Play Store(Android) e App Store(iOS) é necessário que você assine seu app. Para saber mais sobre assinatura de aplicativos Android e iOS, vou deixar 2 links: Assinatura aplicativo android, Assinatura aplicativo iOS. Mas enfim, para assinar seu app você precisa de certificados e provisioning profiles (iOS) e Keystore (Android), é nesta seção que você deve fazer o upload dos arquivos de assinatura que serão utilizados pelos steps que serão responsáveis para assinar seu aplicativo.

Dica: Para coletar os arquivos de assinatura necessários para a plataforma iOS, você pode usar o codesigndoc, uma ferramenta bastante útil criada pela equipe do Bitrise.

Alerta de Segurança: Aqui há uma questão de segurança que deve ser considerada por sua equipe, pois você estará "compartilhando" seus arquivos de assinatura com o Bitrise, o que significa que se esses arquivos por algum motivo forem vazados podem comprometer a segurança de seu aplicativo. Neste caso, é importante sua equipe realizar diligências para saber mais detalhes sobre os procedimentos de segurança adotado pela equipe do Bitrise. Reforço que me senti seguro em relação a tais procedimentos e atualmente os aplicativos que desenvolvo na empresa são assinados e enviados para loja diretamente pelo Bitrise.

Secrets

Nesta seção você pode adicionar secrets, que são variáveis que você não quer deixar expostas no arquivo de configuração de build (bitrise.yml). Ex: Usuário e senhas, Tokens, etc. Saiba mais sobre secrets clicando aqui.

Env Vars

Nesta seção você pode adicionar Variáveis de Ambientes que serão utilizadas em seus steps, essas variáveis ficam expostas no arquivo de configuração de build (bitrise.yml). Ex: Paths, Workspace, etc.

Triggers

Como mencionado anteriormente você também pode definir Triggers, que são gatilhos disparados quando há alterações em suas branchs, em eventos de PUSH, PULL REQUEST, TAGS. Então nesta seção você pode executar um Workflow toda vez que ocorrer mudanças nas branchs definidas, para isso seu webhook deve está configurado. Para saber mais sobre triggers no Bitrise, clique aqui.

Build Configuration File & Bitrise CLI

Para finalizar gostaria de falar do Build Configuration File, arquivo no formato YAML que define todos os seus steps, quando você edita seus steps utilizando a ferramenta gráfica seu arquivo de configuração muda. Nesta seção você pode editar os seus steps utilizando código, muito útil quando você quer replicar uma configuração que você já fez em outro projeto. Além disso, você pode testar e editar e configurar seus builds localmente, da mesma forma que serão executados no Bitrise, para isso basta baixar o Bitrise CLI.

Conclusão

Enquanto o desenvolvimento ágil aproximou as equipes de desenvolvimento do negócio, reduzindo os gaps entre essas áreas, o DevOps traz agilidade para as entregas reduzindo os gaps entre desenvolvimento e operações. Atualmente, desenvolver ágil significa adotar as melhores práticas para que sua equipe se concentre ainda mais no negócio/cliente e as entregas sejam cada vez mais curtas e contínuas, fazendo com que sejam mais fáceis de serem testadas. E não deve ser diferente no desenvolvimento Mobile, desta forma o Bitrise traz uma plataforma incrível para ajudar desenvolvedores/equipes/empresas nesse processo, com um trabalho de UI/UX sensacional, com várias opções de integração, o que torna absurdamente simples de se encaixar em qualquer pipeline e começar a aplicar as melhores práticas de CI & CD. Pois, em outras palavras, como respondeu o próprio Jez Humble em um de seus twitters: Se você é averso a riscos, continuos delivery te ajuda a minimizá-los: