GitLab CI: pipelines e integração contínua

O que é GitLab CI?

GitLab CI é parte do aplicativo unificado DevSecOps do GitLab, abrangendo integração contínua, entrega e implantação. O sistema começou como um projeto separado em 2012, mas foi posteriormente integrado diretamente ao GitLab. O princípio fundamental é a configuração como código através de um arquivo .gitlab-ci.yml na raiz do repositório. O GitLab CI está disponível tanto na versão cloud SaaS quanto na instalação auto-gerenciada.

Para desenvolvimento mobile, o GitLab CI oferece automação de compilações APK e IPA, execução de testes instrumentados, análise estática de código, assinatura de aplicativos e publicação em lojas. A plataforma suporta imagens Docker para ambientes personalizados, permitindo pré-instalação de Android SDK, NDK, Xcode e outras ferramentas. O Container Registry integrado simplifica o armazenamento e distribuição de imagens dentro da equipe.

Arquitetura do GitLab CI: Runners, Pipelines e Stages

A arquitetura do GitLab CI consiste em três componentes principais. GitLab Runner é um agente que executa os jobs. Os runners podem ser compartilhados (fornecidos pelo GitLab), de grupo (para um grupo de projetos) ou específicos (para um projeto). Cada runner é registrado com um executor: Shell, Docker, Kubernetes ou VirtualBox. O GitLab Runner suporta escalonamento automático para lidar com picos de carga.

Um pipeline é um conjunto de stages executados sequencialmente. Dentro de um mesmo stage, os jobs são executados em paralelo. Uma estrutura típica para um projeto mobile é: build → test → deploy. Se um job no stage test falhar, deploy não é executado. É possível configurar execução manual (when: manual) para implantação. Gatilhos de pipelines multi-projeto também são suportados para cenários complexos de CI/CD entre repositórios.

Executores do GitLab Runner

O executor Docker é o mais popular para CI/CD de aplicativos mobile. Cada job é executado em um contêiner Docker limpo, garantindo isolamento e reprodutibilidade. Para compilações Android, usa-se a imagem android-sdk com SDK pré-instalado; para iOS, um runner macOS com executor Shell.

Configuração do .gitlab-ci.yml para projetos mobile

O arquivo .gitlab-ci.yml define um pipeline em formato YAML. As principais seções incluem: image (imagem Docker), stages (lista de etapas), variables (variáveis de ambiente), before_script (comandos antes de cada job) e os jobs com seções script, artifacts, cache. O GitLab CI suporta include — inclusão de arquivos YAML externos para reutilizar configurações comuns entre projetos.

As variáveis no GitLab CI podem ser definidas em vários níveis: globalmente na interface do usuário, no arquivo de configuração, nas configurações de grupo e projeto. A prioridade das variáveis segue uma hierarquia: variáveis de gatilho têm a maior prioridade, seguidas pelas variáveis CI/CD da interface e depois do .gitlab-ci.yml. As variáveis podem ser protegidas, tornando-se acessíveis apenas para branches e tags protegidas.

Variáveis básicas e imagem

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job de compilação com artefatos

O job generate-apk compila um projeto Gradle e salva o APK como artefato. Os artefatos são transferidos entre stages — um job de deploy pode usar o APK do stage build. A retenção de artefatos é configurada via expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: principais diferenças

Ao escolher entre GitLab CI e GitHub Actions para um projeto mobile, a infraestrutura da equipe é um fator chave. GitLab CI oferece um Container Registry integrado para armazenar imagens Docker com Android SDK. O GitHub Actions depende do GitHub Packages ou registros externos. O GitLab também possui SAST (Static Application Security Testing) integrado para análise de vulnerabilidades de código.

GitLab CI oferece um modelo de runners mais flexível — suporta executor Kubernetes, escalonamento automático e imagens personalizadas. O GitHub Actions ganha na integração com o ecossistema GitHub e seu marketplace de ações. O GitLab CI requer mais configuração manual para muitas tarefas que o GitHub Actions resolve com ações prontas.

Da perspectiva de CI/CD mobile: GitLab CI é mais adequado para empresas que já usam GitLab Self-Managed e precisam de runners auto-hospedados com Docker/Kubernetes. GitHub Actions é mais conveniente para equipes pequenas no GitHub cloud que valorizam ações prontas e facilidade de configuração.

Comparação de funcionalidades

Exemplo de pipeline para projeto Android

Um pipeline completo para Android inclui: lint, testes unitários, compilação e implantação no Firebase App Distribution. O pipeline utiliza uma imagem Docker com Android SDK, cache do Gradle e execução paralela de lint e test no mesmo stage. Esta abordagem reduz o tempo total do pipeline, pois as tarefas lint e test são independentes entre si.

Para projetos iOS, a estrutura do pipeline difere devido à necessidade de um runner macOS e assinatura de código. Um pipeline iOS típico inclui: instalação de CocoaPods ou SPM, execução de testes no simulador, arquivamento do projeto Xcode, exportação de IPA e envio ao TestFlight. O GitLab CI para iOS usa runners macOS — sejam os runners SaaS do GitLab com limites de tempo ou um runner auto-hospedado em um Mac Mini ou MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Otimização do tempo de compilação no GitLab CI

Otimizar pipelines de compilação mobile no GitLab CI requer atenção aos detalhes. A configuração adequada de cache e artifacts pode reduzir o tempo de compilação várias vezes. Para análise de desempenho, o GitLab oferece CI/CD Analytics — um dashboard com métricas de duração de pipelines, carga de runners e gargalos. Analise estas métricas regularmente para encontrar oportunidades de otimização. Configurar resource_group bloqueia execuções paralelas de pipelines — útil para evitar conflitos de implantação.

A estratégia de branches para CI também é importante. Recomenda-se executar o pipeline completo apenas para branches main e release, e para branches de funcionalidade — apenas lint e testes unitários. Isso economiza minutos dos runners e acelera o feedback aos desenvolvedores. O GitLab CI suporta workflow:rules — regras condicionais para incluir ou excluir jobs com base no branch, arquivos alterados ou variáveis de ambiente.

O cache de dependências é o principal método de aceleração. O GitLab CI armazena em cache .gradle, Pods e node_modules entre execuções. A chave de cache inclui $CI_COMMIT_REF_SLUG ou um hash do arquivo lock. O tempo de compilação de um projeto Android cai de 10–15 para 2–4 minutos com cache adequado. O cache pode ser distribuído — o GitLab suporta cache:key com fallback para chaves anteriores.

Uma imagem Docker com ferramentas pré-instaladas economiza tempo de instalação. Recomenda-se criar uma imagem personalizada com Android SDK, NDK e o nível de API necessário. A execução paralela de jobs (lint, test, assemble) em diferentes stages reduz o tempo total do pipeline. Políticas de pull para imagens (if-not-present) aceleram o início dos jobs. Um proxy de dependências também pode ser usado para armazenar imagens em cache no nível da instância GitLab.

Outro aspecto importante da otimização é o uso de artefatos entre estágios. Arquivos pesados como APK e IPA devem ser transferidos via dependency em vez de serem recompilados em cada job. Para projetos grandes com dezenas de módulos, recomenda-se habilitar o Gradle Build Cache no nível do pipeline e configurar um cache remoto em armazenamento compartilhado. O timeout de cada job deve ser definido com base no tempo de compilação esperado — isso evita processos pendurados.

Exemplo com cache e política de pull

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present