GitHub Actions — o que é, pipelines CI/CD e automação

O que é GitHub Actions?

GitHub Actions é uma plataforma de automação de fluxos de trabalho integrada ao GitHub e lançada em 2019. Ela permite definir pipelines CI/CD em arquivos YAML armazenados diretamente no repositório. Cada workflow é acionado por um evento: push, pull request, criação de tag ou por agendamento. Ao contrário do Jenkins ou TeamCity, não é necessária infraestrutura separada para hospedar um servidor CI.

No contexto do desenvolvimento móvel, o GitHub Actions automatiza a compilação de APK e IPA, execução de testes unitários e testes de UI em emuladores, verificação de código com linters, assinatura e publicação no Google Play e App Store. A plataforma fornece minutos gratuitos para repositórios públicos e para privados de acordo com o plano de preços. Para projetos móveis de código aberto, é uma solução CI/CD completa sem custos.

Arquitetura do GitHub Actions: Workflows, Jobs e Steps

A arquitetura do GitHub Actions consiste em quatro níveis. Workflow é o arquivo YAML raiz que define a automação. Um Workflow é composto por Jobs, cada Job é executado em um Runner separado. Dentro de um Job, Steps são executados — comandos sequenciais ou actions externas. Events definem os acionadores: push, pull_request, schedule, workflow_dispatch. Um workflow também pode ser acionado manualmente através da guia Actions na interface do GitHub.

O GitHub fornece runners hospedados com SO pré-instalados: Ubuntu, macOS e Windows. Para compilações iOS, um runner macOS é obrigatório, para Android — Linux ou macOS. Self-hosted runners permitem executar jobs em seus próprios servidores com um ambiente personalizado, útil para grandes projetos com requisitos especiais de hardware. O GitHub também suporta grupos de self-hosted runners para organizar filas de execução de jobs.

Estrutura do arquivo workflow

Um arquivo workflow básico contém seções: name, on (acionadores), jobs. Cada job especifica runs-on (tipo de runner), strategy (matriz), steps (lista de ações). Steps podem ser comandos shell ou actions prontas do marketplace, conectadas através da sintaxe owner/repo@version.

Compilação de aplicativos móveis no GitHub Actions

Para compilações Android, um workflow tipicamente inclui etapas: checkout do repositório, instalação do JDK, configuração do cache do Gradle, execução do assembleRelease. Para iOS é necessário um runner macOS, instalação do Xcode via xcode-select, resolução do provisioning profile e execução do xcodebuild. A complexidade das compilações iOS reside no code signing e gerenciamento de certificados. As configurações específicas da Apple incluem gerenciamento de provisioning profile através de apple-actions/import-codesign-certs.

A Matrix strategy permite executar compilações em várias versões simultaneamente. Por exemplo: matriz com versões iOS (15.0, 16.0, 17.0) e Xcode (14, 15). Isso acelera a verificação de compatibilidade do aplicativo com diferentes versões do SO, embora aumente o consumo de minutos dos runners. Para projetos com orçamento CI limitado, a matriz pode ser restrita apenas às configurações principais.

Configuração do ambiente para Android

O GitHub Actions fornece a action setup-java para instalação do JDK e caching para armazenar em cache o Gradle. O Android SDK já está pré-instalado nos runners Ubuntu. Para níveis de API personalizados, o sdkmanager é usado em uma etapa separada. Recomenda-se criar workflows separados para compilações Android e iOS, pois eles usam runners e ferramentas de compilação diferentes.

GitHub Marketplace e actions prontas

O GitHub Marketplace contém mais de 15.000 actions criadas pela comunidade e desenvolvedores oficiais. Para desenvolvimento móvel, as categorias-chave incluem: Code signing (apple-actions/import-codesign-certs), testes (react-native-community/action), implantação (google-github-actions/release-google-play), notificações (slackapi/slack-github-action). Actions para Firebase App Distribution, upload TestFlight e Fastlane também estão disponíveis. Cada action tem um rótulo de compatibilidade com um SO de runner específico.

Cada action tem uma versão, descrição, README e licença. Ao escolher uma action, deve-se dar preferência às oficiais dos fornecedores (Google, Apple, Microsoft) e verificadas através do Verified Badge. É importante especificar uma versão maior fixa (actions/checkout@v4), não @main, para evitar mudanças inesperadas. Se a action necessária não estiver no Marketplace, você pode criar uma action personalizada — localmente no repositório (Docker action ou JavaScript action) ou publicá-la no Marketplace.

Actions populares para CI/CD móvel

• actions/checkout — clona o repositório no runner
• actions/setup-java — instala o JDK para compilações Android
• gradle/actions/setup-gradle — configura e armazena em cache o Gradle
• apple-actions/import-codesign-certs — importa certificados para iOS
• google-github-actions/submit-release — publica no Google Play Console

Exemplo de workflow para projeto iOS

Ao desenvolver aplicativos iOS, é importante configurar o trabalho correto com simuladores e dispositivos. O runner macOS-14 fornece um ambiente com Rosetta 2 para executar compilações Intel na arquitetura ARM. Um workflow pode incluir vários esquemas de compilação — Debug para pull requests e Release para tags. O GitHub Actions suporta análise de xcresult através da action xcparse/sonarqube para exibir resultados de testes. Para enviar notificações de status de compilação, uma action do Slack ou Telegram pode ser adicionada.

O code signing para iOS requer importação de certificados e provisioning profiles. Apple-actions fornecem uma etapa para importar um certificado P12 e instalar um provisioning profile. Os certificados são armazenados como secrets do GitHub Actions e são descriptografados apenas na etapa de compilação. Para automação de assinatura, o Fastlane match é usado, que pode ser chamado como uma etapa separada no workflow.

Vamos considerar um workflow para um aplicativo iOS em Swift que compila o projeto, executa testes e cria uma compilação arquivada. O workflow usa runner macOS-14, Xcode 15.4 e actions para gerenciamento de certificados.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Cache de dependências no GitHub Actions

O armazenamento em cache reduz o tempo de compilação preservando as dependências entre execuções de workflow. O GitHub fornece cache integrado através de actions/cache. Para Gradle, ~/.gradle é armazenado em cache, para CocoaPods — Pods/, para SPM — .build/. A chave de cache inclui um hash do arquivo de lista de dependências — quando as dependências mudam, o cache é automaticamente invalidado.

Atenção especial deve ser dada à estratégia de restauração de cache (restore-keys). Se a chave exata não for encontrada, o GitHub Actions tenta correspondência parcial por restore-keys. Isso é útil quando apenas uma dependência muda — o cache permanece parcialmente utilizável. Para Gradle, recomenda-se adicionalmente habilitar o Gradle Build Cache, que armazena em cache resultados de compilação entre diferentes módulos do projeto.

Exemplo de cache do Gradle

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Eficiência do cache para projetos Android: primeira compilação sem cache — 8–12 minutos, compilação subsequente com cache — 2–4 minutos. Para iOS com CocoaPods, a economia é semelhante. Recomenda-se combinar actions/cache com a action setup-gradle do Gradle para gerenciamento ótimo de cache. Para dependências npm no React Native, actions/cache é usado com hash de package-lock.json. Com configuração adequada de cache, o tempo de compilação pode ser reduzido em até 70%.

O GitHub Actions suporta variáveis de ambiente nos níveis workflow, job e step. Variáveis de ambiente podem ser sobrescritas: o nível de step tem a maior prioridade. Para dados confidenciais, use sempre secrets — eles são criptografados com AES-256 e não são exibidos nos logs. Regras de proteção de ambiente também estão disponíveis — aprovação manual obrigatória antes da implantação. Para segurança adicional, pode-se configurar aprovação obrigatória de usuários ou equipes específicas.

O GitHub Actions também suporta Reusable Workflows — pipelines reutilizáveis que podem ser chamados de outros workflows. Isso permite criar um workflow de compilação centralizado e reutilizá-lo em todos os repositórios da organização. Um reusable workflow é chamado com uma única linha e pode aceitar parâmetros de entrada e secrets. Isso é especialmente útil para padronizar práticas de CI/CD em grandes equipes.

Segurança e melhores práticas

Ao configurar o GitHub Actions para projetos móveis, é importante seguir princípios de segurança. OIDC (OpenID Connect) permite eliminar credenciais de longa duração e obter tokens temporários para provedores de nuvem. Nunca use secrets em texto simples em scripts — o GitHub Actions mascara automaticamente secrets nos logs.

Para projetos móveis, é crítico restringir o acesso ao workflow para forks de terceiros. Use a configuração pull_request_target com cuidado — ela executa código do branch base, não do fork. Para code signing de aplicativos iOS, recomenda-se armazenar certificados criptografados e descriptografá-los apenas na etapa de compilação através de gpg ou openssl.