Azure DevOps — CI/CD de aplicações Android para iniciantes — Parte 2
Falaaa pessoal. Após deixar uma breve introdução de como operar e construir um esteira CI utilizando os recursos da plataforma Azure Pipelines, volto aqui para deixar a parte 2 desse artigo, que será o responsável por fazer o delivery do projeto na play store.
E se você chegou aqui antes de dar uma olhadinha na parte 1, é indispensável caso você pense em trabalhar dentro do ambiente Azure, mas além disso é uma boa contextualização do que vem a seguir.
Então vamo que vamo, hoje esse Continuous Delivery sai!!
Azure Pipeline
Contextualizando para quem não pegou na primeira parte desse artigo, o Azure Pipelines vem como um agente de execução como diversos outros do mercado, como: Jenkins, GitHub Actions e etc. Essas ferramentas nos permitem criar fluxos de trabalho que automaticamente criam, testam, publicam, lançam e implantam códigos, tornando nosso processo de desenvolvimento automático de ponta a ponta.
Falando de distribuição, surgem duas variantes que acho muito relevante mencionar, o Continuous Delivery e o Continuous Deployment, é possível se aprofundar no assunto neste ótimo artigo. Mas grosseiramente resumido, ambos fazem o mesmo processo e sua principal característica adversa é que o Delivery tem ativação manual do deploy para produção, enquanto o Deployment é automático.
A explicação da contextualização acima fica mais claro com as duas imagens à seguir:
Agora que você já entendeu como funciona a distribuição nessas duas perspectivas, será optado trabalhar com o modelo tradicional, o Continuous Delivery que segue sendo o mais tradicional, pensando que o Deployment é mais utilizado em uma arquitetura de micro serviços com o esquema canary onde releases constantes fazem parte da rotina.
A partir de agora vamos por a mão na massa e configurar nosso CD.
Configurando o CD no Azure Pipelines
Anteriormente quando se tratava de CI usamos a aba Pipelines, justamente para que fosse possível criar uma integração para nossa aplicação, porém agora já possuímos o artefato em mãos e queremos o Release dessa aplicação, então vamos seguir o que o nome nos sugere.
No menu lateral selecione a opção Releases dentro de Pipelines, conforme a imagem acima. Após clicar, vá na opção New release pipeline.
Deve aparecer a opção para selecionar um template, escolha um empty job para iniciar a configuração meu release, pois iremos configurar depois na segunda etapa.
Configurando artifacts e stages
Vamos por partes, após iniciar um novo release pipeline obtemos duas sessões, elas são: artifacts e stages. Deixarei uma breve explicação sobre essas duas etapas.
Os artefatos são nada mais nada menos que no meu caso o .apk que eu desejo enviar. Uma vez que meu CI gerou esse arquivo, basta apenas seleciona-lo.
Aqui eu selecionei tanto o meu repositório git, o qual está dentro do azure repos (_hvn). Também selecionei o build propriamente dito, ou seja, sempre que eu gerar um artefato irei buscar o ultimo (_hvnart).
Obs: Não é necessário manter os dois, apenas deixei como exemplo que pode ser utilizado tanto um quanto o outro. Há diversas maneiras de como obter o artefato.
Agora falando sobre Stages, trata-se do nosso agent job, o serviço que vai realizar de fato essa distribuição que no meu caso é o serviço da play store.
Agent job é um agrupamento lógico de tarefas que define o alvo de tempo de execução no qual as tarefas serão executadas. Um Agent job executa tarefas em um agente em um pool de agentes, que pode rodar em diferentes maquinas. Há muito para entender sobre isso, mas fica como tarefa de casa se aprofundar no assunto.
Então resumindo, vamos precisar de fato adicionar tasks nesse agent job que possuímos dentro de nosso stage. Para o nosso propósito vamos precisar de tasks da Google play, basta pesquisar e instalar como mostro a seguir:
Com isso vamos obter todos as tasks que envolvem esse "pacote".
Neste caso eu irei distribuir diretamente para a minha conta na play store e enviarei meu .apk, mas como mostra a imagem acima existem diversas opção de tasks.
Escolhi a Google Play Release com o objetivo de distribuir o meu artefato para a loja. Agora basta configura-la, confira logo abaixo.
Então vamos para o passo a passo:
- Display name: O nome do seu release, geralmente determina qual é a sua finalidade.
- Authentication method: Aqui é possível escolher se deseja usar a chave da sua aplicação gerada pelo Google Play (JSON Auth File), ou utilizar as credenciais da sua conta (Service Connection).
- JSON key path: O arquivo JSON fornecido pelo Google Play que inclui a identidade da conta de serviço sob a qual você deseja publicar seu APK.
- Service Connection: Conexão de serviço do Google Play configurada com as credenciais da sua conta.
- APK path: Caminho para o arquivo APK que você deseja publicar na faixa especificada. Curingas podem ser usados. Por exemplo, **/*.apk para corresponder ao primeiro arquivo APK, em qualquer diretório. Neste caso eu selecionei meu artefato que já foi gerado por meio do meu CI.
- Track: Faixa na qual você deseja publicar o APK.
Só um detalhe, na foto acima eu configurei ele para internal por se tratar de um teste, mas você deve configurar os detalhes acima conforme o seu objetivo.
Triggers
Agora que já deixamos pronto, vale ressaltar que é possível configurar trigger tanto para criar o release, aqui foi configurado para sempre que houver um include na branch main.
E também uma trigger para liberação desse deploy, na qual coloquei eu como pre-deployment de aprovação.
Após configurar o job, já é possível realizar o deploy manualmente do meu projeto, como a imagem mostra a seguir:
Está feito!
Após realizar o deploy, o interface me atualiza com logs do que está sendo executado e finalizado em tempo real.
Pronto. Meu job está finalizado, já posso ir lá na google play ver o meu .apk pendente de aprovação.
Obs: Não entrarei na configuração da Google Play, mas deixo um artigo que recomendo caso você necessite configurar pela primeira vez a sua conta.
Vale lembrar que este serviço pode ser configurado da maneira que for desejado, a task do Google Play não é o único caminho. O AppCenter também faz a distribuição e gerenciamento de artefatos, então se você possui um projeto híbrido talvez seja a solução ideal, porém é gratuito até um determinado momento.
Esse artigo se voltou totalmente para o mobile, mas explore e aplique sem medo em diversas soluções, mobile, back e front. A ferramenta pode muito mais do que deixei aqui.
Bom pessoal, espero que este artigo juntamente com a parte 1 ajudem todos que tiveram dificuldades como eu a criar e distribuir suas aplicações mobiles. Vale ressaltar que existem inúmeras integrações e que o céu é o limite, então caso não atenda essa solução para você, certamente existe um caso que te atende no meio do nosso mundo de tecnologia.
Muito obrigado por ficar comigo até aqui e até uma próxima! :D
