EN
ES
O ponto principal, na minha opinião, da criação das pipelines de CI/CD é de dar uma garantia maior que o produto que estamos entregando esteja com o menor número de bugs possíveis e a rapidez da entrega do software pro destino final, podendo ser ele um ambiente de testes em estágio de desenvolvimento ou staging como o Firebase App Distribution, ou para o cliente final nos testes internos do Android ou no Testflight do iOS.
Objetivo principal
O artigo busca explicar como configurar o ambiente da Google para utilizar deploys de aplicativos Android para testes internos nas pipelines de CD. Como exemplos, o artigo mostra como utilizar esse conhecimento nas pipelines do Github Actions e Azure DevOps.
Permissões e acessos
Para dar seguimento à leitura do artigo, é de suma importância que:
- O projeto possua vínculo com o Firebase
- O projeto possua uma loja no Google Play Console
- O projeto já tenha sido publicado ao menos uma vez em testes internos
- Você tenha acesso no GCloud do projeto como editor ou cargos superiores
- Você tenha acesso no Google Play Console como admin
Claro, se você estiver lendo o artigo e não possuir esses acessos e permissões, mas o seu colega de time sim, continue lendo o artigo, passe a ele o conhecimento e pratique o pair programming.
Uma vez que todas as condições acima foram satisfeitas, vamos ao passo a passo.
Passo a passo
1. Criar a chave de acesso
Acessar o GCloud → IAM → Contas de serviço.
Ao acessar as contas de serviço, você pode criar uma conta de serviço especificando o nome, como por exemplo: githubactionsdeploy@seuprojeto.iam.gserviceaccount.com. Ou você pode apenas clicar em uma já criada.
Ao clicar na sua conta, vá em: Chaves → Adicionar chave → Criar nova chave e selecione o tipo de chave JSON.
2. Ativando o Google Play Android Developer API
Ainda no GCloud, acesse o menu sanduíche na parte superior esquerda e selecione a opção APIs e serviços → Na aba de procura, digite Google Play Android Developer API → Ativar.
3. Vinculando o serviço na Google Play Console
Uma vez que você baixou a chave JSON, extraia dela o client_email.
Ao acessar a página inicial do Google Play Console e selecionar a loja, acesse na aba lateral esquerda → Usuários e permissões → Convidar novos usuários → Adicione o client_email com acesso ao app correto e adicione as permissões de Acesso de app (exceto adm) e Versões.
Testando no Azure DevOps e Github Actions
O Azure DevOps e o Github Actions trabalham de uma maneira diferente. Enquanto o Azure DevOps tem uma dependência baixa da comunidade, e os pacotes deles são validados antes pela equipe da Microsoft, o Github Actions depende da comunidade, então é possível encontrar diversos pacotes com o mesmo propósito, alguns com mais e outros com menos configurações.
Azure DevOps
No Azure DevOps, para ativar a task de Release na Google, é necessário antes configurar o Service Connection. Para isso, acesse as configurações do projeto do Azure → Service connections → New service connection → Google Play e abrirá uma tela de configuração para inserir as credenciais da conta de serviço gerada no GCloud.
As informações mais importantes são a private key e o service account e-mail. Ambas as informações são encontradas no arquivo JSON, com as chaves client_email e private_key. Service connection name e Description são só identificadores pra facilitar e identificar qual o propósito desse service connection.
Uma vez feito isso, pode ser adicionado na pipeline a task Google Play — Release
E no service connection dela atribuir o service connection criado anteriormente.
2. Github Actions
O Github Actions por ser uma ferramenta que abre espaço pra comunidade cuidar dos pacotes, é importante se atentar à popularidade do pacote e quantas pessoas contribuem pra ele. No caso desse artigo, o mais bem avaliado é o pacote Upload Android Release to Play Store do Drew Heavner que possui 25 contribuidores.
with:
serviceAccountJsonPlainText: ${{ SERVICE_ACCOUNT_JSON }}
packageName: com.example.MyApp
releaseFiles: app/build/outputs/bundle/release/app-release.aab
track: production
status: inProgress
inAppUpdatePriority: 2
userFraction: 0.33
whatsNewDirectory: distribution/whatsnew
mappingFile: app/build/outputs/mapping/release/mapping.txt
debugSymbols: app/intermediates/merged_native_libs/release/out/lib
Importante frisar que alguns desses campos são opcionais e devem ser usados somente se a build for entregue de forma fracionada pra o público geral. A página do Github tem todas as informações importantes que você precisa pra fazer o delivery da forma certa.
Conclusão
A rapidez da entrega no ambiente certo e pra os testadores certos é muito importante pra garantir validações mais rápidas e com isso diminuir o tempo de entrega do produto pro cliente final. Seguindo os passos contidos no artigo o serviço irá funcionar independentemente da plataforma que você utilize pra fazer suas pipelines. Espero que o artigo ajude você e nos vemos em breve.
