CI/CD Pipeline — o que é, etapas de automação e ferramentas

O que é CI/CD Pipeline

CI/CD Pipeline é um conjunto formalizado e automatizado de processos que o código percorre desde a confirmação de alterações no repositório até a implantação em produção. O termo combina duas práticas: Continuous Integration (integração contínua) e Continuous Delivery (entrega contínua), que juntas formam um pipeline de entrega de software.

História do CI/CD

O conceito de Continuous Integration foi descrito por Grady Booch em 1991 e popularizado por Martin Fowler nos anos 2000. Continuous Delivery como termo consolidou-se após o livro “Continuous Delivery” de Jez Humble e David Farley (2010). O CI/CD Pipeline moderno tornou-se o padrão de facto no desenvolvimento móvel após 2015 — com o surgimento de servidores CI na nuvem e automação de lojas de aplicações.

Por que o CI/CD Pipeline é necessário no desenvolvimento móvel

As aplicações móveis têm requisitos específicos de compilação e publicação: assinatura de certificados, múltiplas configurações (debug, release, staging), ofuscação ProGuard/R8, vários tipos de builds (APK, AAB, IPA) e integração com lojas de aplicações. A execução manual destes passos leva horas e é propensa a erros — o CI/CD Pipeline automatiza a rotina.

Etapas do CI/CD Pipeline para apps móveis

Um CI/CD Pipeline padrão para aplicações Android ou iOS consiste em sete etapas principais. Algumas etapas são executadas em paralelo, outras sequencialmente. O conjunto exato de etapas depende da stack tecnológica e da maturidade da equipa, mas o núcleo permanece o mesmo.

1. Checkout e instalação de dependências

O pipeline começa clonando o repositório e instalando dependências: Gradle/Maven para Android, CocoaPods ou SPM para iOS. O cache de dependências entre execuções reduz o tempo de instalação de 3–5 minutos para alguns segundos — todos os serviços CI modernos suportam esta otimização.

2. Análise estática e linting

Antes de compilar, o código é verificado por linters (ktlint, detekt para Android, SwiftLint para iOS) e analisadores estáticos (Android Lint, SonarQube). O linting deteta potenciais erros, violações de estilo de código e APIs obsoletas antes de executar os testes — o princípio fail-fast poupa tempo à equipa.

3. Compilação do projeto

Na etapa de compilação, todo o projeto é compilado e são gerados artefactos: APK e AAB para Android, IPA para iOS. Para Android são usadas tarefas Gradle (assembleDebug, bundleRelease), para iOS — xcodebuild ou xcrun. A compilação é executada num ambiente isolado do servidor CI, garantindo reprodutibilidade.

# Exemplo de Pipeline CI/CD para Android no GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Testes automatizados

Após a compilação, são executados testes unitários, de integração e de UI. JUnit e MockK para testes unitários, Espresso e Compose Test para UI em Android, XCTest e XCUITest em iOS. Os resultados são publicados num relatório e bloqueiam o pipeline se testes críticos falharem.

5. Assinatura e ofuscação

Para builds de lançamento, é realizada a assinatura com certificado digital (APK Signer para Android, codesign para iOS) e a ofuscação do código. ProGuard ou R8 para Android reduz o tamanho do APK entre 15 e 30%. As chaves de assinatura são armazenadas nos segredos do servidor CI — nunca são commitadas no repositório.

6. Entrega e implantação

A etapa final do pipeline é a publicação de artefactos: upload de APK para testes internos da Google Play Console, envio de IPA para TestFlight ou publicação no Firebase Distribution. Continuous Delivery implica que este passo requer aprovação manual, enquanto o Continuous Deployment é executado automaticamente.

7. Notificações e relatórios

Após a conclusão do pipeline, a equipa recebe uma notificação com os resultados: sucesso/insucesso, tempo de execução, link para os artefactos. Slack, Telegram ou email — os canais de notificação são escolhidos conforme as necessidades da equipa. Quando uma etapa falha, a notificação inclui um link para o registo de erro específico.

Diferenças entre CI e CD

Os termos CI e CD são frequentemente usados como um conceito único CI/CD, mas existe uma diferença fundamental entre eles. CI (Continuous Integration) é responsável por verificar a qualidade em cada integração de código, enquanto CD (Continuous Delivery) garante que o código está pronto para lançamento. Compreender a diferença é crítico ao projetar um pipeline.

Continuous Integration — controlo de qualidade

O CI é executado em cada push ou pull request e inclui compilação, análise estática e testes. O objetivo do CI é detetar problemas o mais cedo possível, quando o custo de os corrigir é mínimo. Se o CI falhar — o código não entra na ramificação principal. O tempo médio de execução de CI para um projeto móvel é de 5 a 15 minutos.

Continuous Delivery — preparação para lançamento

O CD adiciona ao CI as etapas de preparação do lançamento: assinatura, ofuscação, criação de notas de versão, verificação de licenças, publicação em armazenamento para testers. O CD garante que qualquer commit na ramificação principal pode ser publicado em produção com um clique, mas o lançamento em si requer aprovação manual.

Ferramentas para construir CI/CD Pipeline

O ecossistema de ferramentas CI/CD para desenvolvimento móvel inclui serviços cloud, soluções self-hosted e plataformas especializadas. A escolha da ferramenta depende do tamanho da equipa, orçamento e requisitos de segurança. Abaixo estão as opções mais populares.

GitHub Actions

CI/CD integrado no GitHub com limite gratuito de 2000 minutos por mês para repositórios públicos. O GitHub Actions é popular graças ao enorme ecossistema de ações prontas (marketplace), facilidade de configuração via YAML e integração perfeita com repositórios GitHub. Limitação — não suporta runners Windows para builds iOS no plano gratuito.

GitLab CI/CD

Solução self-hosted e cloud com um poderoso configurador YAML. O GitLab CI suporta trabalhos paralelos, cache, artefactos e ambientes. Popular no segmento empresarial pela possibilidade de implantar na própria infraestrutura e controlo total sobre os dados.

Jenkins

Servidor CI clássico de código aberto. O Jenkins é configurado através de plugins (mais de 1800), suporta Declarative Pipeline em formato Groovy e funciona em qualquer ambiente: Windows, macOS, Linux. Requer administração dedicada mas oferece máxima flexibilidade de configuração.

CircleCI

Serviço CI cloud focado em velocidade e simplicidade. O CircleCI armazena automaticamente em cache as dependências, suporta imagens Docker para builds isolados e integra-se com macOS para builds iOS. O preço é baseado em créditos — adequado para equipas que valorizam desempenho.

Exemplo de configuração de CI/CD Pipeline

Vamos ver um CI/CD Pipeline completo para uma app iOS usando GitHub Actions e Fastlane. Fastlane é uma ferramenta de automação para projetos móveis que abstrai operações complexas de compilação, assinatura e publicação em comandos simples.

# Fastfile — configuração do Fastlane para CI/CD iOS
default_platform(:ios)

platform :ios do
  desc   desc "Executar testes e lint"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc   desc "Compilar o release e enviar para o TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match gere certificados e perfis de provisionamento, build_app compila o IPA, pilot envia o build para o TestFlight. O comando fastlane release executa todas as etapas sequencialmente: obtém certificados, compila, assina, envia para o App Store Connect para testers beta.

CI/CD Pipeline para iOS com GitHub Actions

A integração do Fastlane com o GitHub Actions permite executar o pipeline completo automaticamente em pull requests para a ramificação main. É necessário um runner self-hosted em macOS para a compilação de código iOS — o GitHub não fornece runners macOS no plano gratuito.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Melhores práticas de CI/CD Pipeline

Construir um CI/CD Pipeline eficaz requer não só escolher ferramentas mas também seguir práticas comprovadas. Sem uma organização adequada, o pipeline pode tornar-se um gargalo, atrasando o desenvolvimento em vez de o acelerar. Abaixo estão as principais recomendações baseadas na experiência de equipas móveis maduras.

Fail fast

As verificações mais rápidas (linting, testes unitários) são executadas primeiro. Se falharem — o pipeline termina sem executar testes de UI longos ou builds de lançamento. Fail fast poupa minutos de tempo de CI e acelera o feedback ao programador. O tempo médio até à primeira falha não deve exceder 2–3 minutos.

Cache de dependências

O cache do Gradle, CocoaPods e SPM deve ser restaurado entre execuções. O GitHub Actions suporta cache através de actions/cache, o GitLab CI através da palavra-chave cache. Sem cache, cada build descarrega todas as dependências de novo — adicionando 3–10 minutos ao tempo do pipeline.

Execução paralela

Etapas independentes (linter para Android e iOS, testes unitários de diferentes módulos) são executadas como trabalhos paralelos. A paralelização reduz o tempo total do pipeline de 20–30 minutos para 5–10 minutos. A maioria dos serviços CI cobra os trabalhos paralelos separadamente — tenha isso em conta ao escolher um plano.

Isolamento do ambiente

Cada execução do pipeline é realizada num ambiente limpo: contentor Docker, máquina virtual ou runner efémero. O isolamento impede que as compilações anteriores afetem a atual. Evite usar runners partilhados entre projetos — a poluição cruzada do ambiente leva a falhas não determinísticas.

Segurança de segredos

As chaves API, certificados de assinatura e tokens de acesso a lojas de aplicações são armazenados no cofre encriptado do servidor CI. Nunca inclua segredos em registos, artefactos ou variáveis de ambiente sem o prefixo SECRET_. Use ferramentas como Fastlane match para gestão de certificados iOS.