CI/CD para Android com Bash Puro: Compilação e Publicação sem Ferramentas Extras

Um pipeline de CI/CD é, essencialmente, uma série de requisições HTTP na ordem correta. Iniciar uma compilação, consultar o status, baixar um artefato, publicar no Google Play – tudo isso é feito via REST API. O curl pode lidar com isso! Vamos ver se é possível dispensar Jenkins, plataformas pagas e frameworks Python com dezenas de dependências.

Eu montei um servidor CI/CD para aplicações Android em Bash puro. Ele inicia compilações via CI na nuvem ou Gradle diretamente, publica o resultado no Google Play e monitora notificações de publicação via IMAP. Como interface de gerenciamento, utilizei o Telegram, mas no lugar dele poderia estar Slack, Discord, ntfy, email ou um SSH comum – o transporte é uma peça substituível.

Talvez você diga que fazer tudo em Bash é estranho. Mas afinal, é a linguagem para conectar ferramentas: entrada/saída de arquivos, trabalho com variáveis de ambiente, requisições HTTP via curl, manipulação de JSON com jq. Isso significa que simplesmente aplicaremos o clássico "caminho Unix" às APIs web, e não apenas a programas locais. E, ao mesmo tempo, dispensaremos Docker e Kubernetes.

E o mais importante: será possível modificar qualquer coisa e a qualquer momento sem sofrer com o deploy. Agora a ideia parece mais sensata? Vamos experimentá-la em um exemplo, e ficará claro se isso é aplicável na vida real.

Para começar, vejamos como funcionará o ciclo completo de publicação. Para iniciá-lo, basta clicar em "Publish Beta" – e em alguns minutos você verá o que apareceu no chat.

Ciclo completo: download do artefato, upload para o Google Play, notificação de publicação O bot baixou o AAB do Codemagic, fez o upload para o Google Play, registrou a transação de edição – e depois, quando o Google concluiu a moderação, o monitor de e-mail capturou a mensagem e enviou a notificação final. Tudo sem intervenção humana.

E agora, contarei como construí isso. Se você quiser replicar, aqui está o que você precisará:

• Token de bot do Telegram (solicite ao @BotFather);
• Token da API do Codemagic ou Android SDK local com Gradle;
• Arquivo JSON da Service Account do Google Play com permissões de Release Manager;
• Caixa de e-mail com acesso IMAP (Gmail serve);
• Docker ou qualquer host Linux;
• Dependências: curl, jq, openssl, mbsync;

Arquitetura O sistema consiste em dois processos independentes em um único contêiner Docker.

Orquestrador de compilações (publish_bot.sh) – recebe comandos do operador, inicia a compilação via API de CI ou Gradle local, entrega o artefato, publica no Google Play, responde a requisições de status. Atende vários projetos simultaneamente – cada um com seu processo worker.

Monitor de e-mail (imap_to_telegram.sh) – a cada 30 segundos lê os e-mails recebidos via IMAP, procura por mensagens da Google Play Console, retransmite notificações para o canal correto.

Entre eles – o arquivo channel_ids.json: um mapeamento "nome do pacote → identificador do canal". Ambos os processos o leem independentemente.

Arquitetura do serviço: dois processos, arquivo de mapeamento comum, transporte substituível O transporte – bloco superior (comandos) e inferior (notificações) – é intencionalmente separado da lógica. Quer migrar do Slack para o Telegram ou adicionar envio paralelo para ntfy – edite três funções, sem afetar o núcleo.

Cada outro bloco também é substituível independentemente: mudar o serviço de CI – uma função, adicionar um track de publicação – um case no switch. A arquitetura é intencionalmente plana: sem abstrações, apenas funções.

O deploy é um comando:

bash
docker run -d \
  --name cicd-server \
  --restart unless-stopped \
  -e IMAP_PASSWORD='senha' \
  cicd-server

O script start.sh inicia ambos os processos:

bash
. /publish_bot.sh &
. /imap_to_telegram.sh &
wait

A seguir, detalharemos as tarefas específicas em ordem.

Transporte Antes de mergulhar nos detalhes – um ponto arquitetural importante. No sistema, existem exatamente três pontos de interação com o operador:

Comandos de entrada – de onde o serviço recebe a tarefa (iniciar compilação, mostrar status). Notificações de saída – para onde relatar o resultado. Entrega de artefatos – para onde entregar o APK/AAB compilado. Tudo isso é implementado em três ou quatro funções. Mudar o transporte significa reescrever essas funções.

Apenas notificações Se a interatividade não for necessária – as opções são simples.

ntfy.sh – a opção minimalista. Serviço público, gratuito, com aplicativo móvel. Enviar notificação:

bash
curl -d "✅ Compilação ${PACKAGE} concluída" \
  "https://ntfy.sh/my-secret-build-topic"

O tópico é apenas uma string na URL. Assine no aplicativo – receba push. Sem registro, sem tokens. É possível hospedar seu próprio servidor ntfy para privacidade.

Webhooks do Slack/Discord – se a equipe já o utiliza. Para nós, basta fazer uma requisição POST com JSON:

bash
curl -X POST "$SLACK_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d "{
    "text": "✅ Compilação *${PACKAGE}* concluída"
  }"

No Discord, o campo se chama content em vez de text, a URL é diferente, mas o padrão é o mesmo.

E-mail via msmtp – funciona completamente sem dependência de serviços de terceiros:

bash
echo -e "Subject: Compilação pronta\n\n${PACKAGE} compilou com sucesso" \
  | msmtp recipient@example.com

Canal bidirecional Se precisar de comandos e notificações, a escolha é a seguinte.

Telegram – a opção mais conveniente para esta tarefa: API gratuita, long polling sem IP público, arquivos de até 50 MB podem ser enviados diretamente no chat, botões são criados com um único JSON. Detalharemos abaixo.

Slash commands do Slack – uma opção funcional para desenvolvimento em equipe. O slash command envia um POST para o seu endpoint – o que significa que você precisa de uma URL pública, ao contrário do polling do Telegram. Recebemos respostas via webhook.

Matrix/Element – protocolo aberto com API REST, suporta polling (/sync), é possível hospedar o servidor localmente. O esquema é o mesmo do Telegram: loop, depois curl /sync, processamento do evento e, em seguida, curl /send.

SSH – exótico para uso pessoal, mas as dependências são zero:

bash
ssh user@cicd-host "./publish_bot.sh build_release com.example.app"

Cron – serve se a interatividade não for necessária. Se você tem compilações noturnas e releases beta semanais, pode automatizar tudo e dispensar os mensageiros.

O que é realmente difícil de substituir é o envio de arquivos. O Telegram aceita APKs diretamente no chat, o arquivo é baixado com um toque. O Slack tem um limite de upload no plano gratuito, ntfy não tem arquivos. Alternativa: S3 ou Cloudflare R2 como armazenamento, e o link virá na notificação.

Vinculação do projeto a um canal de notificação O serviço atende vários aplicativos. Como ele sabe para qual projeto veio o comando e para qual canal enviar a notificação?

O restante do conteúdo está disponível apenas para membros. Materiais das últimas edições tornam-se disponíveis separadamente apenas dois meses após a publicação. Para continuar a leitura, é necessário se tornar um membro da comunidade "Xakep.ru". Junte-se à comunidade "Xakep.ru"! A associação à comunidade durante o período especificado lhe dará acesso a TODO o material "Xakep", permitirá baixar edições em PDF, desativará a publicidade no site e aumentará seu desconto acumulado pessoal! Saiba mais Já sou membro "Xakep.ru" ← Anterior Ransomware usa servidores do Microsoft Teams para ocultar tráfego