CI/CD para projetos Kotlin no GitHub Actions: guia completo

Treinador Online de Python para Iniciantes

Aprenda Python facilmente sem sobrecarga teórica. Resolva tarefas práticas com verificação automática e escreva código diretamente no navegador.

Start Course

Introdução: Por que CI/CD é crítico para projetos Kotlin

O desenvolvimento moderno em Kotlin — seja backend com Spring Boot, aplicativo Android ou projeto multiplataforma — exige um ciclo de entrega rápido e confiável. Processos manuais de build e teste não apenas consomem tempo, mas também são propensos a erros. É aqui que o CI/CD (Continuous Integration / Continuous Deployment) entra em ação.

GitHub Actions é um sistema de automação integrado que permite executar workflows diretamente no seu repositório. Para projetos Kotlin, é a escolha ideal: integra-se facilmente com Gradle, suporta cache de dependências e permite implantar aplicativos em qualquer plataforma.

Neste artigo, vamos abordar como configurar um pipeline CI/CD completo para um projeto Kotlin usando GitHub Actions: desde o build básico até o deploy automático.

1. Fundamentos do GitHub Actions: estrutura do workflow

Cada workflow no GitHub Actions é um arquivo YAML localizado no diretório .github/workflows/. Vamos analisar os componentes básicos usando um projeto Kotlin como exemplo.

1.1. Triggers (on)

O workflow é acionado por eventos específicos: push em um branch, criação de Pull Request ou por agendamento (cron).

1.2. Jobs e Steps

Job é um conjunto de etapas executadas em um único ambiente virtual. Steps podem executar comandos, scripts ou actions prontas do marketplace.

1.3. Exemplo de workflow mínimo

Vamos criar o arquivo .github/workflows/ci.yml para um projeto Kotlin com Gradle:

name: CI for Kotlin

on:  push:    branches: [ main, develop ]  pull_request:    branches: [ main ]

jobs:  build:    runs-on: ubuntu-latest

    steps:      - uses: actions/checkout@v4

      - name: Set up JDK 17        uses: actions/setup-java@v4        with:          java-version: '17'          distribution: 'temurin'

      - name: Setup Gradle        uses: gradle/actions/setup-gradle@v3

      - name: Build with Gradle        run: ./gradlew build

      - name: Run tests        run: ./gradlew test

Este pipeline executará o build e os testes a cada push ou PR em main/develop.

2. Otimização do CI: cache e tarefas paralelas

Sem otimização, cada execução baixará as dependências do Gradle novamente. Para projetos Kotlin, isso pode levar de 2 a 5 minutos. A solução é o cache.

2.1. Cache do Gradle

GitHub Actions permite armazenar em cache o diretório ~/.gradle/caches:

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

Após a primeira execução, as subsequentes usarão o cache — a velocidade aumenta de 2 a 3 vezes.

2.2. Jobs paralelos para diferentes tarefas

É possível dividir testes, linting e build em jobs separados que são executados em paralelo:

jobs:  lint:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run detekt        run: ./gradlew detekt

  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run tests        run: ./gradlew test

  build:    needs: [lint, test]    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Build JAR        run: ./gradlew bootJar

Aqui, o build será executado somente após a conclusão bem-sucedida do linting e dos testes.