CI/CD para projetos Kotlin: GitHub Actions do A ao Z

Introdução ao CI/CD para Kotlin com GitHub Actions

No desenvolvimento moderno, a automação dos processos de compilação, teste e implantação tornou-se uma parte essencial de uma abordagem profissional. Para projetos Kotlin, sejam aplicativos Android, serviços backend com Ktor ou bibliotecas multiplataforma, configurar CI/CD (Continuous Integration / Continuous Deployment) permite reduzir significativamente o tempo de lançamento do produto e diminuir o risco de erros.

GitHub Actions é uma ferramenta poderosa e flexível, integrada ao ecossistema GitHub. Ela permite criar pipelines personalizados que são executados automaticamente em pushes, criação de pull requests ou por agendamento. Neste artigo, vamos abordar o ciclo completo de configuração de CI/CD para Kotlin: desde a verificação básica de código até o deploy automático.

Fundamentos do GitHub Actions: estrutura e sintaxe

Antes de mergulharmos nas especificidades do Kotlin, é importante entender os conceitos básicos do GitHub Actions. O pipeline é descrito em arquivos YAML, que são armazenados no diretório .github/workflows/ do seu repositório.

Elementos-chave de um workflow

• Event (evento): gatilho que inicia o pipeline (push, pull_request, release, etc.).
• Job (tarefa): conjunto de etapas executadas em um único runner (máquina virtual).
• Step (etapa): ação específica — execução de um comando, execução de um script ou uso de uma action pronta.
• Runner: ambiente de execução (Ubuntu, Windows, macOS).

Estrutura básica do arquivo kotlin-ci.yml:

name: Kotlin CI

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: Build with Gradle        run: ./gradlew build

Configuração de CI para Kotlin: compilação, testes e linting

A primeira e mais importante etapa é a integração contínua. Ela garante que cada novo código seja compilado e não quebre os testes existentes.

Cache de dependências do Gradle

Para acelerar a compilação, certifique-se de usar o cache. Sem ele, cada execução baixará todas as bibliotecas novamente.

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

Execução de testes e verificação de estilo

Vamos adicionar etapas para executar testes unitários e linters (detekt ou ktlint). Isso ajuda a manter a qualidade do código.

- name: Run tests  run: ./gradlew test

- name: Run linter  run: ./gradlew detekt

Exemplo de workflow CI completo para um projeto Kotlin

jobs:  test:    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: Cache Gradle        uses: actions/cache@v3        with:          path: ~/.gradle/caches          key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle.kts') }}      - name: Build and test        run: ./gradlew check

Continuous Deployment: deploy automático de aplicações Kotlin

Após a integração bem-sucedida, chega a etapa de deploy. Para projetos Kotlin, isso pode significar publicar uma biblioteca no Maven Central, implantar um backend em um servidor ou compilar um APK para Android.

Deploy de um serviço backend com Ktor

Suponha que temos uma aplicação Kotlin usando o framework Ktor. Queremos automaticamente