CI/CD para projetos Kotlin com GitHub Actions: guia passo a passo

Introdução: Por que CI/CD é indispensável para o desenvolvimento Kotlin

O desenvolvimento moderno em Kotlin não se resume apenas a escrever código conciso e seguro, mas também a garantir sua entrega contínua. Seja você criando uma aplicação server-side com Ktor, um aplicativo Android ou um projeto multiplataforma, as compilações e testes manuais rapidamente se tornam um gargalo. CI/CD (Continuous Integration / Continuous Deployment) automatiza esses processos, reduzindo o risco de erro humano e acelerando o lançamento de novas funcionalidades.

GitHub Actions é uma das ferramentas mais populares para implementar CI/CD, especialmente se seu código já está armazenado no GitHub. Ele se integra perfeitamente com o ecossistema Kotlin, suporta Gradle e Maven, e permite configurar pipelines de forma flexível para qualquer necessidade. Neste artigo, vamos detalhar como configurar um ciclo completo de compilação, teste e deploy para um projeto Kotlin usando GitHub Actions.

Fundamentos do GitHub Actions: Estrutura do workflow

Antes de escrever código, vamos entender os conceitos básicos. Um workflow (fluxo de trabalho) no GitHub Actions é um processo automatizado que é acionado por um evento específico (por exemplo, um push para a branch main). O workflow é descrito em um arquivo YAML, armazenado no diretório .github/workflows/ do seu repositório.

A estrutura típica de um workflow inclui:

• name — nome do workflow (exibido na interface do GitHub).
• on — gatilhos de execução (por exemplo, push, pull_request).
• jobs — conjunto de tarefas que são executadas sequencialmente ou em paralelo.
• steps — etapas dentro de um job (instalação do JDK, cache de dependências, execução de testes).

Para projetos Kotlin, uma etapa chave é configurar a versão correta do JDK (geralmente 11, 17 ou 21) e usar o Gradle Wrapper (./gradlew), que garante a reprodutibilidade da compilação em qualquer máquina.

Passo 1: Compilação e teste básicos de um projeto Kotlin

Vamos começar com o mais simples: um workflow que executa testes a cada push para a main ou ao criar um Pull Request. Esta é a base de qualquer CI/CD — garantir que o código não quebrou a funcionalidade existente.

Crie o arquivo .github/workflows/ci.yml com o seguinte conteúdo:

name: CI for Kotlin

on:  push:    branches: [ main ]  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: Grant execute permission for gradlew        run: chmod +x gradlew

      - 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-

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

      - name: Run tests        run: ./gradlew test

Vamos analisar os pontos-chave:

• actions/checkout@v4 — clona o repositório no runner.
• actions/setup-java@v4 — instala o JDK 17 (Temurin). Você pode escolher outra versão se seu projeto exigir, por exemplo, JDK 11 ou 21.
• actions/cache@v4 — armazena em cache as dependências do Gradle. Isso é crucial para a velocidade: sem cache, cada compilação baixará todas as bibliotecas novamente (pode levar de 2 a 5 minutos). O cache acelera esse processo para alguns segundos.
• ./gradlew build — compilação completa do projeto (compilação + testes). Se você quiser apenas os testes, use ./gradlew test.