Olá caros, neste artigo mostrarei como a integração contínua pode automatizar nosso fluxo de trabalho, liberando versões para testers através de e-mail e para google play que será nosso ambiente de produção.
O que é uma integração contínua?
Seguindo as boas práticas de desenvolvimento de software utilizamos repositórios de versionamento de código para realizar desenvolvimento incremental, compartilhar código com a equipe e principalmente evitar o retrabalho.
Agora imagine que a cada nova funcionalidade desenvolvida a gente consiga compilar a aplicação, realizar todos os testes e enviar uma versão para uma equipe de homologação do produto ou até mesmo publicar a versão na loja (Google play | Apple Store), tudo isto de forma automática. Seria incrível não é mesmo?
Pois é, isto existe e está presente, cada vez mais, em projetos modernos, todo este processo é conhecido como pipeline de integração contínua.
Por onde começo a integração contínua do meu projeto mobile?
Empresas de serviços em nuvem como a Microsoft, Amazon, Google Cloud, Alibaba Cloud, IBM Cloud, Circle CI e entre outras oferecem estes recursos.
Para dispositivos móveis utilizaremos o App Center da Microsoft, vamos visualizar nosso cenário.
A nossa aplicação é uma listagem de séries que precisa ser migrada para um banco de dados não relacional, visando aumento no desempenho e ela também precisará que seja desenvolvida uma tela com mais detalhes do filme selecionado pelo usuário.
Nosso repositório terá a seguinte configuração. Se você ainda não se sente confortavel trabalhando com repositórios, recomendo a leitura do Fluxo de trabalho do Gitflow.
- Master : o nosso projeto final, o código que está no ambiente de produção, ou seja, o código do aplicativo que está na loja e vários usuários estão utilizando.
- Develop: branch (ramo) do Master – terá o código de uso interno da empresa, a versão com novas funcionalidades desenvolvidas, testadas ou disponíveis para testes, basicamente a nossa versão alfa da aplicação.
- A feature 1: branch do Develop – é onde a equipe de desenvolvimento está trabalhando na migração do banco de dados.
- feature 2: também branch do Develop – é onde outras pessoas estão desenvolvendo a tela de detalhamento do filme.
Como a feature 1 e feature 2 são filhas de develop, ambos desenvolvimentos podem ser executados simultaneamente sem impactos, visto que a feature 2 por exemplo, não conhece nada sobre a construção de banco de dados e terá o foco exclusivo na sua tarefa.
Após a finalização de cada feature será realizado o processo de merge, onde a nova funcionalidade será inclusa na develop, automaticamente será iniciada todo processo de compilação do projeto e disponibilizado o executável da aplicação (.apk) para a uma equipe de testers via e-mail.
Quando decidirmos que a aplicação está preparada para ser entregue aos usuários finais, acontecerá o merge do develop para o master, iniciando o processo automático de compilação da aplicação novamente, testes de interface e gerando uma versão na Google Play.
O primeiro passo é entender quais tecnologias e repositórios o App Center suporta.
- Repositórios: GitHub, GitLab, Azure DevOps e Bitbucket
- Tecnologias : Android (Java ou Kotlin), iOS (Swift ou Objective-C), Aplicações Windows, React Native, Xamarin, Cordova, MacOS, Unity e TvOS.
Criei um repositório chamado DevOpsMobile e subi o projeto de listagem de filmes no master, criei uma branch develop e as features conforme nosso cenário.
Vamos iniciar a configuração da nossa integração continua. Fazendo login no App Center e adicionando um novo app, preencheremos o nome da aplicação (DevOpsMobile), o sistema operacional (Android) e a plataforma (Xamarin).
No menu a esquerda temos as opções de Build, Test, Distribute, Diagnostics e Analitics. Vamos detalhar cada uma destes serviços.
- Build: Aqui é onde tudo começa, iremos conectar o nosso repositório e determinar a configuração de cada branch, cada push que houver no branch configurado aqui neste serviço iniciará uma compilação, será restaurado os pacotes ou dependências, o aplicativo será assinado (Keystore) e será disponibilizado o artefato (.Apk). Se a aplicação foi construída corretamente no nosso serviço de build temos a garantia que o código não possui erros e chega de ouvir aquela velha frase “na minha máquina funciona.” ou ficar perdendo tempo configurando dependências manualmente cada vez que baixar um projeto.
- Test: Temos a possibilidade de realizar testes em dispositivos reais, armazenar os resultados por 6 meses, validar distribuição apenas para testes de sucesso, interessante aqui é o suporte as principais ferramentas de testes de interface como Apium, Espresso, Xamarin UI Test e XCUITest
- Distribute: Aplicação compilada e testada, é hora de disponibilizar uma versão da aplicação para um grupo de testadores via e-mail ou até mesmo para os usuários finais na própria google play.
- Diagnostics: Podemos também monitorar a “saúde” da nossa aplicação, tendo feedback de falhas durante testes e erros no uso do aplicativo. Este serviço precisa ser configurado previamente e está disponível para Android, Xamarin, Unity e aplicações windows.
- Analitics: O analitics permite mapear quais telas estão tendo mais acesso durante o uso, basicamente permite identificar os perfis dos usuários, dispositivos que estão consumindo a aplicação, países e etc
Para configurar o build, primeiramente vamos conectar no repositório do projeto.
Ao realizar login na plataforma, no meu caso, no GitHub será listado todos os repositórios disponíveis.
automaticamente será listado todos os branch deste repositório, permitindo que seja configurado individualmente, é partir daqui que vamos dizer o que vai acontecer quando houver commit em cada um destes branches.
- Status da compilação
- Nome do branch
- Comentário e autor do último commit
- Gatilho que iniciará a compilação
- Data da última compilação
Vamos convidar os testadores para que eles recebam a versão da aplicação sempre que houver build do develop, para isto iremos no último menu (Settings), selecionar People/Collaborators e aqui podemos convidar pessoas para participar do projeto.
é possível configurar se esta pessoa poderá gerenciar os serviços de build, distribuição, testes ou irá apenas receber o aplicativo para instalação, após o convite, o usuário receberá um e-mail para aceitar a participação no processo de integração do app center.
Passo a passo na configuração do nosso build para grupo de e-mail.
- Podemos notar que será apresentado nosso projeto xamarin.android, projeto que irá gerar o artefato
- configuração de debug ou release
- SDK que vai ser compilado a aplicação
- Se a frequência de build será a cada push ou manualmente.
Eu gerei uma keystore, este arquivo é nescessário para gerar aplicativos android assinado, para detalhes deste processo de criação da keystore estou deixando o link oficial da Microsoft aqui.
Escreverei o processo de testes separadamente, visto a importância do tema e conseguir detalhar passo a passo com vocês em um artigo separado.
Vamos então entender a distribuição da aplicação, ou seja, para onde será enviado o artefato da aplicação após o sucesso do build deste branch. já temos selecionado o grupo colaboradores, mas de onde veio isto?
São os usuários que a gente convidamos anteriormente. No menu distribuição/grupos, podemos criar vários grupos e gerenciar como preferirmos, lembrando que a cada convite novo por padrão será convidado para o grupo colaboradores.
Finalizando a configuração do build, vamos testar se tudo deu certo clicando em Save & Build.
Build com sucesso para criação da aplicação, podemos entrar no build e acompanhar todo o processo
- Commit do repositório, para validar as alterações que iniciou o processo de build
- Log de todo processo de build.
- Status, tempo e download da versão
E todos os usuários do grupo colaboradores configurados no build do develop receberam este e-mail, permitindo realizar o download do apk para validar as funcionalidades inclusas.
Configuração do build para Google Play.
Agora que entendemos a distribuição por e-mail e finalizamos a configuração do build do branch de develop, vamos disponibilizar o master para loja a cada push.
Primeiramente é necessário criar o aplicativo na google play , Lembrando que para isto você precisá ter uma conta de desenvolvedor google, que custa 25 dólares.
A criação do aplicativo na loja é bem intuitiva e deixa claro os campos obrigatórios, como recursos gráficos, termos de uso, políticas e etc. Basta ir preenchendo passo a passo que o google se encarregará de informar o que está faltando, finalizando o aplicativo vai para revisão e após aprovado estará disponível na google play.
O nosso aplicativo DevOps está publicado na loja e pode ser baixado/visualizado aqui.
No App Center vamos configurar a opção lojas em distribuição
É nescessário criar uma chave para aplicação, que pode ser acompanhada detalhadamente no site oficial da microsoft
realize o upload do arquivo .Json gerado no google play console
Último passo é configurar o nome do pacote que está publicado na loja
Prontinho estamos conectados com a nossa loja (google play).
Agora podemos voltar e configurar o build para o branch master, irei realizar as mesmas configurações que realizamos anteriormente para o develop.
Modo release, Xamarin.Android 10.3, Build a cada push, assinatura do aplicativo.
Nossa única mudança deve ser na distribuição, que desta vez será para loja e não para o grupo colaboradores.
Desta vez fiz um Merge no master e, consequentemente, foi iniciado um build daquele push no master.
Eu tive alguns problemas no build do master, que geraram falhas no processo de publicação na loja, a ideia do artigo é também mostrar os erros que podem vir a ocorrer, porem são bem claros nos logs do app center. Vamos ver o que houve.
O primeiro foi pacote com nome inválido, alterei no projeto e realizei um novo commit e push
Os dois próximos foram referente a versão 2 já está publicada na loja, foi a versão que eu subi para google play como versão inicial na publicação do app.
Versão na loja.
Prontinho, corrigido o nome do pacote e a versão da aplicação, gerou o aplicativo automático na loja
Em distribuição podemos acompanhar o status da versão gerada automaticamente perante a loja.
Para finalizar, eu configurei os branches feature1 e feature2 como debug, sem assinatura e sem distribuição apenas para validar que o código desenvolvido naquela funcionalidade não possui erros, e se houver conseguir notificar a equipe responsável antes que este erro suba para o branch develop.
Todas as fases de desenvolvimento citadas acima e toda tecnologia utilizada no projeto estão disponível no github.
Este foi o começo do conteúdo de DevOps para mobile.
Um spoiler do que vem por ai. Processo de teste de interface e integração do app center com o azure devops, onde iremos utilizar o scrum, para criar historias, tarefas, vincular commit a tarefas, acompanhar todo o ciclo de desenvolvimento do projeto podendo tomar decisões com maior qualidade.
Fagner Muniz