GitHub Actions vs GitLab CI para backend, web e mobile

Com o que as pessoas têm dificuldade em CI para multi-apps

Quando um repositório constrói um backend, um app web e apps mobile, o CI deixa de ser "apenas rodar testes". Ele vira um controlador de tráfego para diferentes toolchains, tempos de build e regras de release distintas.

A dor mais comum é simples: uma pequena mudança aciona trabalho demais. Uma edição na documentação inicia a assinatura iOS, ou um ajuste no backend força uma recompilação completa do web, e de repente cada merge parece lento e arriscado.

Em setups multi-app, alguns problemas aparecem cedo:

• Runner drift: versões de SDK diferem entre máquinas, então builds se comportam de forma diferente entre CI e local.
• Sprawl de segredos: chaves de API, certificados de assinatura e credenciais de loja se duplicam entre jobs e ambientes.
• Confusão de cache: a chave de cache errada cria builds obsoletos, mas sem cache tudo fica dolorosamente lento.
• Regras de release mistas: backends querem deploys frequentes, enquanto releases mobile são controladas e precisam de checagens extras.
• Legibilidade do pipeline: a configuração cresce até virar um muro de jobs que ninguém quer tocar.

Por isso a escolha entre GitHub Actions e GitLab CI importa mais em monorepos do que em projetos de app único. Você precisa de formas claras de dividir trabalho por caminho, compartilhar artefatos com segurança e evitar que jobs paralelos pisem uns nos outros.

Uma comparação prática se resume a quatro coisas: setup e escala de runners, armazenamento e escopo de segredos, caching e artefatos, e quão fácil é expressar "compilar apenas o que mudou" sem transformar o pipeline numa sopa frágil de regras.

Isto é sobre confiabilidade e manutenção do dia a dia, não sobre qual plataforma tem mais integrações ou uma UI mais bonita. Também não substitui decisões sobre suas ferramentas de build (Gradle, Xcode, Docker etc.). Ajuda a escolher o CI que torna mais fácil manter uma estrutura limpa.

Como GitHub Actions e GitLab CI se organizam

A maior diferença é como cada plataforma organiza pipelines e reuso, e isso começa a importar quando backend, web e mobile compartilham o mesmo repositório.

GitHub Actions armazena automação em YAML sob .github/workflows/. Workflows disparam em eventos como push, pull request, agendamentos ou execuções manuais. GitLab CI gira em torno de .gitlab-ci.yml na raiz do repositório, com arquivos incluídos opcionais; pipelines tipicamente rodam em pushes, merge requests, schedules e jobs manuais.

GitLab é construído em torno de stages. Você define estágios (build, test, deploy) e atribui jobs aos estágios que rodam em ordem. GitHub Actions é construído em torno de workflows que contêm jobs. Jobs rodam em paralelo por padrão, e você adiciona dependências quando algo precisa esperar.

Para rodar a mesma lógica em muitos alvos, a matrix do GitHub é um encaixe natural (iOS vs Android, múltiplas versões do Node). GitLab consegue fan-out similar usando jobs paralelos e variáveis, mas muitas vezes você acaba montando mais peças manualmente.

Reuso também parece diferente. No GitHub, times geralmente usam reusable workflows e composite actions. No GitLab, o reuso costuma vir de include, templates compartilhados e anchors/extends em YAML.

Aprovações e ambientes protegidos também divergem. GitHub costuma usar environments protegidos com revisores obrigatórios e secrets por environment para que deploys de produção pausem até aprovação. GitLab combina frequentemente branches/tags protegidos, ambientes protegidos e jobs manuais para que apenas papéis específicos possam rodar um deploy.

Setup de runners e execução de jobs

O setup de runners é onde as duas plataformas começam a se diferenciar no uso diário. Ambas podem rodar jobs em hosted runners (você não gerencia a máquina) ou self-hosted (você tem a máquina, atualizações e segurança). Hosted runners são mais simples para começar; self-hosted costumam ser necessários por velocidade, ferramentas especiais ou acesso a redes privadas.

Uma divisão prática em muitas equipes é: runners Linux para backend e web, e macOS somente quando for preciso compilar iOS. Android roda em Linux, mas é pesado, então tamanho de runner e espaço em disco importam.

Hosted vs self-hosted: o que você gerencia

Hosted runners são bons quando você quer setup previsível sem manutenção. Self-hosted fazem sentido quando você precisa de versões específicas de Java/Xcode, caches mais rápidos ou acesso à rede interna.

Se optar por self-hosted, defina papéis de runner cedo. A maioria dos repositórios vai bem com um conjunto pequeno: um runner Linux geral para backend/web, um runner Linux mais robusto para Android, um runner macOS para empacotamento e assinatura iOS, e um runner separado para deploys com permissões mais restritas.

Escolhendo o runner certo por job

Ambos os sistemas deixam você direcionar runners (labels no GitHub, tags no GitLab). Mantenha nomes vinculados às cargas, como linux-docker, android ou macos-xcode15.

Isolamento é onde muitos builds ficam instáveis. Arquivos remanescentes, caches compartilhados corrompidos ou ferramentas instaladas “na mão” em uma máquina self-hosted podem criar falhas aleatórias. Workspaces limpos, versões de ferramentas fixas e limpeza agendada dos runners costumam pagar rápido.

Capacidade e permissões são outras dores recorrentes, especialmente com disponibilidade e custo de macOS. Um padrão razoável: runners de build podem compilar, runners de deploy podem publicar, e credenciais de produção vivem no menor conjunto possível de jobs.

Segredos e variáveis de ambiente

Segredos são onde pipelines multi-app ficam arriscados. O básico é parecido (armazenar segredos na plataforma, injetar em runtime), mas o escopo é diferente.

GitHub Actions geralmente escopa segredos no nível de repositório e organização, com uma camada extra chamada Environment. Esse Environment é útil quando produção precisa de um gate manual e um conjunto de valores separado do staging.

GitLab CI usa CI/CD variables no nível do projeto, grupo ou instância. Também suporta variáveis por environment, além de proteções como “protected” (disponível apenas em branches/tags protegidos) e “masked” (ocultas nos logs). Esses controles ajudam quando um monorepo serve múltiplas equipes.

O modo de falha mais comum é exposição acidental: saída de debug, um comando com falha que ecoa variáveis, ou um artefato que inclui um arquivo de configuração. Trate logs e artefatos como compartilháveis por padrão.

Em pipelines backend + web + mobile, segredos geralmente incluem credenciais de cloud, URLs de banco de dados e chaves de terceiros, material de assinatura (certificados/perfis iOS, keystore e senhas Android), tokens de registro (npm, Maven, CocoaPods) e tokens de automação (provedores de e-mail/SMS, bots de chat).

Para múltiplos ambientes (dev, staging, prod), mantenha nomes consistentes e troque valores por escopo de ambiente em vez de copiar jobs. Isso facilita rotação e controle de acesso.

Algumas regras que previnem a maioria dos incidentes:

• Prefira credenciais de curta duração (como OIDC para provedores cloud quando disponível) em vez de chaves de longa duração.
• Use princípio de menor privilégio: identidades de deploy separadas para backend, web e mobile.
• Masque segredos e evite imprimir variáveis de ambiente, mesmo em falhas.
• Restrinja segredos de produção a branches/tags protegidos e revisores obrigatórios.
• Nunca armazene segredos em artefatos de build, nem mesmo temporariamente.

Um exemplo simples e de alto impacto: jobs mobile só devem receber segredos de assinatura em releases com tag, enquanto jobs de deploy do backend podem usar um token de deploy limitado em merges para main. Isso reduz muito o raio de ação se um job estiver mal configurado.

Caching e artefatos para builds mais rápidos

A maioria dos pipelines lentos é lenta por uma razão chata: eles baixam e recompilam as mesmas coisas repetidamente. Cache evita trabalho repetido. Artefatos resolvem outro problema: preservar saídas exatas de uma execução específica.

O que cachear depende do que você compila. Backends se beneficiam de caches de dependências e compilador (por exemplo, cache de módulos Go). Builds web se beneficiam de caches do gerenciador de pacotes e ferramentas de build. Mobile costuma precisar de Gradle e do cache do Android SDK no Linux, e CocoaPods ou Swift Package Manager no macOS. Cuidado com cache agressivo de outputs iOS (como DerivedData) a menos que você entenda trade-offs.

Ambas as plataformas seguem o mesmo padrão: restaurar cache no início do job e salvar cache atualizado no fim. A diferença do dia a dia é o controle. GitLab deixa comportamento de cache e artefatos explícito em um arquivo, incluindo expiração. GitHub Actions frequentemente depende de actions separadas para cache, o que é flexível mas mais fácil de configurar errado.

Chaves de cache importam mais em monorepos. Boas chaves mudam quando entradas mudam e permanecem estáveis caso contrário. Lockfiles (go.sum, pnpm-lock.yaml, yarn.lock e similares) devem guiar a chave. Também ajuda incluir um hash da pasta específica do app que você está compilando ao invés do repositório inteiro, e manter caches separados por app para que uma mudança não invalide tudo.

Use artefatos para entregáveis que você quer manter daquela execução exata: bundles de release, APK/IPA, relatórios de teste, arquivos de coverage e metadados de build. Caches são aceleradores; artefatos são registros.

Se builds ainda estiverem lentos, procure por caches enormes, chaves que mudam a cada run (timestamps e SHAs completos de commit são culpados comuns) e outputs em cache que não são reutilizáveis entre runners.

Encaixe no monorepo: múltiplos pipelines sem caos

Um monorepo fica bagunçado quando todo push dispara testes de backend, builds web e assinatura mobile, mesmo se você só mudou um README. O padrão limpo é: detectar o que mudou e rodar apenas os jobs relevantes.

No GitHub Actions, isso costuma significar workflows separados por app com filtros de path para que cada workflow rode apenas quando arquivos na sua área mudam. No GitLab CI, costuma significar um único arquivo de pipeline usando rules:changes (ou child pipelines) para criar ou pular grupos de jobs com base em paths.

Pacotes compartilhados são onde a confiança quebra. Se packages/auth muda, backend e web podem precisar ser reconstruídos mesmo que suas pastas não tenham mudado. Trate paths compartilhados como gatilhos para múltiplos pipelines e mantenha fronteiras de dependência claras.

Um mapa de gatilhos simples que reduz surpresas:

• Jobs de backend rodam em mudanças em backend/** ou packages/**.
• Jobs web rodam em mudanças em web/** ou packages/**.
• Jobs mobile rodam em mudanças em mobile/** ou packages/**.
• Mudanças apenas na docs rodam checagens rápidas (formatação, verificação ortográfica).

Parallelize o que for seguro (tests unitários, linting, build web). Serialize o que precisa de controle (deploys, releases em app stores). Tanto o needs do GitLab quanto dependências de jobs do GitHub ajudam a rodar checagens rápidas no começo e parar o resto quando algo falha.

Mantenha assinatura mobile isolada do CI cotidiano. Coloque chaves de assinatura em um environment dedicado com aprovação manual, e rode assinatura apenas em releases taggeados ou em um branch protegido. Pull requests normais ainda podem compilar apps não assinados para validação sem expor credenciais sensíveis.

Passo a passo: um pipeline limpo para backend, web e mobile

Um pipeline multi-app limpo começa com nomes que deixam a intenção óbvia. Escolha um padrão e mantenha-o para que as pessoas possam escanear logs e saber o que rodou.

Um esquema legível que funciona:

• Pipelines: pr-checks, main-build, release
• Environments: dev, staging, prod
• Artefatos: backend-api, web-bundle, mobile-debug, mobile-release

A partir daí, mantenha jobs pequenos e promova só o que passou em checagens anteriores:

1. PR checks (todo pull request): rode testes rápidos e lint apenas para os apps que mudaram. Para o backend, gere um artefato deployable (uma imagem container ou um bundle do servidor) e armazene para que passos posteriores não recompilem.

2. Web build (PR + main): construa o web em um bundle estático. Em PRs, mantenha a saída como artefato (ou faça deploy para um ambiente de preview se houver). No main, produza um bundle versionado adequado para dev ou staging.

3. Mobile debug builds (PR apenas): gere um APK/IPA de debug. Não assine para release. O objetivo é feedback rápido e um arquivo que testadores possam instalar.

4. Release builds (somente tags): quando uma tag como v1.4.0 for pushada, rode builds completos de backend e web mais builds mobile assinados para release. Gere outputs prontos para as stores e mantenha notas de release junto dos artefatos.

5. Aprovações manuais: coloque aprovações entre staging e prod, não antes dos testes básicos. Desenvolvedores podem disparar builds, mas somente papéis aprovados devem fazer deploy em produção e acessar segredos de produção.

Erros comuns que fazem perder tempo

Times frequentemente perdem semanas por hábitos de workflow que criam builds frágilmente.

Uma armadilha é depender demais de runners compartilhados. Quando muitos projetos competem pelo mesmo pool, você tem timeouts aleatórios, jobs lentos e builds mobile que falham somente em horários de pico. Se backend, web e mobile importam, isole jobs pesados em runners dedicados (ou ao menos filas separadas) e deixe limites de recurso explícitos.

Segredos são outro buraco de tempo. Chaves e certificados de assinatura mobile são fáceis de manusear errado. Um erro comum é armazená-los de forma ampla (disponível para todo branch e job) ou vazar via logs verbosos. Mantenha material de assinatura limitado a branches/tags protegidos e evite qualquer passo que imprima valores secretos (mesmo strings em base64).

Caching pode atrapalhar quando equipes cacheiam diretórios enormes ou confundem cache com artefato. Cache só inputs estáveis. Guarde outputs necessários como artefatos.

Por fim, em monorepos, disparar todo pipeline a cada mudança queima minutos e paciência. Se alguém altera um README e você recompila iOS, Android, backend e web, as pessoas param de confiar no CI.

Um checklist rápido que ajuda:

• Use regras baseadas em path para que só apps afetados rodem.
• Separe jobs de teste de jobs de deploy.
• Mantenha chaves de assinatura restritas a workflows de release.
• Cacheie entradas pequenas e estáveis, não pastas inteiras de build.
• Planeje capacidade previsível de runners para builds mobile pesados.

Checagens rápidas antes de se comprometer com uma plataforma

Antes de escolher, faça algumas checagens que reflitam como vocês trabalham de verdade. Isso evita escolher uma ferramenta que parece ok para um app, mas vira dor quando você adiciona mobile, múltiplos ambientes e releases.

Foque em:

• Plano de runners: hosted, self-hosted ou mix. Builds mobile costumam empurrar times para um mix por causa do macOS.
• Plano de segredos: onde vivem os segredos, quem pode lê-los e como funciona rotação. Produção deve ser mais restrita que staging.
• Plano de cache: o que você cacheia, onde fica armazenado e como as chaves são formadas. Se a chave muda a cada commit, você paga sem ganhar velocidade.
• Plano de monorepo: filtros por path e um jeito limpo de compartilhar passos comuns (lint, testes) sem copiar e colar.
• Plano de release: tags, aprovações e separação de ambientes. Seja explícito sobre quem pode promover para produção e que provas são necessárias.

Teste essas respostas com um cenário pequeno. Em um monorepo com backend Go, web em Vue e dois apps mobile: uma mudança só na docs deveria fazer quase nada; uma mudança no backend deveria rodar testes e gerar um artefato de API; uma mudança de UI mobile deveria compilar só Android e iOS.

Se você não consegue descrever esse fluxo numa página (gatilhos, caches, segredos, aprovações), rode um piloto de uma semana em ambas as plataformas usando o mesmo repositório. Escolha a que pareça entediante e previsível.

Exemplo: um fluxo realista de build e release em monorepo

Imagine um repositório com três pastas: backend/ (Go), web/ (Vue) e mobile/ (iOS e Android).

No dia a dia, você quer feedback rápido. Em releases, você quer builds completos, assinatura e passos de publicação.

Uma divisão prática:

• Branches de feature: rode lint + unit tests para as partes que mudaram, construa backend e web, e opcionalmente rode um build Android de debug. Pule iOS a menos que seja realmente necessário.
• Tags de release: rode tudo, crie artefatos versionados, assine apps mobile e envie imagens/binários para seu armazenamento de release.

A escolha de runners muda quando mobile entra. Builds Go e Vue ficam bem em Linux quase em qualquer lugar. iOS exige runners macOS, que podem guiar a decisão mais do que qualquer outra coisa. Se sua equipe quer controle total das máquinas, GitLab CI com runners self-hosted pode ser mais fácil de operar em frota. Se prefere menos trabalho operacional e setup rápido, hosted runners do GitHub são convenientes, mas minutos macOS e disponibilidade entram no seu planejamento.

Caching é onde se economiza tempo de verdade, mas o melhor cache varia por app. Para Go, cacheie downloads de módulos e o cache de build. Para Vue, cacheie o store do gerenciador de pacotes e reconstrua apenas quando lockfiles mudarem. Para mobile, cacheie Gradle e o Android SDK no Linux; cacheie CocoaPods ou Swift Package Manager no macOS, e espere caches maiores e mais invalidações.

Uma regra de decisão que funciona: se seu código já está hospedado em uma plataforma, comece por ela. Mude só se runners (especialmente macOS), permissões ou compliance exigirem.

Próximos passos: escolher, padronizar e automatizar com segurança

Escolha a ferramenta que combina com onde seu código e sua equipe já estão. Na maior parte das vezes, a diferença aparece no atrito diário: reviews, permissões e quão rápido alguém consegue diagnosticar um build quebrado.

Comece simples: um pipeline por app (backend, web, mobile). Quando estiver estável, extraia passos compartilhados para templates reutilizáveis para reduzir copy-paste sem confundir responsabilidades.

Escreva o escopo de segredos como escreveria quem tem chaves de um escritório. Segredos de produção não devem ser legíveis por qualquer branch. Defina um lembrete de rotação (trimestral é melhor que nunca) e concorde sobre como revogar emergencialmente.

Se você está gerando com um gerador no-code que produz código real, trate geração/export como um passo de CI. Por exemplo, AppMaster (appmaster.io) gera backends Go, web em Vue3 e apps mobile Kotlin/SwiftUI, então seu pipeline pode regenerar o código quando houver mudanças e depois compilar só os alvos afetados.

Quando tiver um fluxo em que a equipe confia, torne-o padrão para novos repositórios e mantenha as coisas entediantes: gatilhos claros, runners previsíveis, segredos restritos e releases que rodam só quando você pretende.