CI/CD для Kotlin: настройка конвейера с нуля на реальном проекте

Вы написали крутой проект на Kotlin. А как теперь доставлять обновления без боли?

Вы закоммитили код, запушили в GitHub и… начали ручной ритуал: собрать jar, залить на сервер, перезапустить, проверить, что ничего не упало. Знакомо? А если проект растёт, появляются тесты, линтеры, несколько окружений — рутина съедает часы, а одна забытая команда может обрушить прод.

Выход есть — CI/CD pipeline для Kotlin. Это автоматический конвейер, который сам собирает проект, прогоняет тесты, проверяет стиль кода и деплоит на сервер после каждого пуша. В этой статье я покажу, как настроить такой пайплайн с нуля на GitHub Actions и Gradle. Вы получите готовый шаблон, который можно адаптировать под свой проект — будь то серверное приложение на Ktor, Android-приложение или библиотека.

Поехали! 🚀

Что такое CI/CD и зачем это Kotlin-разработчику?

CI (Continuous Integration) — непрерывная интеграция. Вы пушите код, а система автоматически его собирает, тестирует и проверяет качество. CD (Continuous Delivery/Deployment) — непрерывная доставка или развёртывание. После успешной сборки код автоматически попадает на сервер (или в магазин приложений).

Для Kotlin-проектов CI/CD особенно важен:

• Экономия времени — не нужно вручную запускать gradle build.
• Качество кода — тесты и линтеры срабатывают на каждый коммит.
• Безопасность — прод обновляется только после зелёного пайплайна.
• Прозрачность — вся команда видит статус сборки.

Сегодня мы построим полноценный CI/CD pipeline для Kotlin на GitHub Actions. Это бесплатно для публичных репозиториев и очень гибко.

Шаг 1. Подготовка Kotlin-проекта

Прежде чем писать пайплайн, убедитесь, что ваш проект готов к CI/CD. Я буду использовать типовую структуру с Gradle (Kotlin DSL).

Вот пример build.gradle.kts для простого консольного приложения:

plugins {
    kotlin("jvm") version "1.9.22"
    application
}

application {
    mainClass.set("com.example.MainKt")
}

repositories {
    mavenCentral()
}

dependencies {
    implementation(kotlin("stdlib"))
    testImplementation("org.jetbrains.kotlin:kotlin-test")
}

tasks.test {
    useJUnitPlatform()
}

Важно: добавьте хотя бы один тест, чтобы пайплайн имел смысл.

Пример теста (src/test/kotlin/com/example/AppTest.kt):

import kotlin.test.Test
import kotlin.test.assertEquals

class AppTest {
    @Test
    fun testGreeting() {
        assertEquals("Hello, Kotlin!", getGreeting())
    }
}

Теперь закоммитьте и запушьте проект в GitHub.

Шаг 2. Создаём первый CI-пайплайн: сборка и тесты

В корне репозитория создайте папку .github/workflows и внутри файл ci.yml.

Вот минимальный GitHub Actions workflow для Kotlin:

name: CI Pipeline for Kotlin

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

jobs:
  build:
    runs-on: ubuntu-latest

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

      - name: Run tests
        run: ./gradlew test

      - name: Archive test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: build/reports/tests/

Что здесь происходит:

• Триггеры: push в main/develop и PR в main.
• Установка JDK 17 (Kotlin 1.9+ требует минимум JDK 17).
• Сборка (./gradlew build).
• Запуск тестов.
• Сохранение отчёта о тестах как артефакта (чтобы можно было скачать и посмотреть).

Закоммитьте файл и запушьте. Перейдите на вкладку Actions в GitHub — вы увидите запущенный workflow.

Если тесты зелёные — первый этап настройки CI/CD для Kotlin пройден! ✅

Шаг 3. Добавляем линтинг и проверку стиля

Код должен быть не только рабочим, но и единообразным. Для Kotlin отлично подходит detekt — статический анализатор.

Добавьте плагин в build.gradle.kts:

plugins {
    id("io.gitlab.arturbosch.detekt") version "1.23.6"
}

detekt {
    buildUponDefaultConfig = true
    allRules = false
    config.setFrom("detekt.yml") // опционально
    baseline = file("detekt-baseline.xml")
}

Создайте конфиг detekt.yml в корне (можно оставить пустым для старта).

Теперь обновим CI-файл, добавив шаг с detekt:

      - name: Run detekt
        run: ./gradlew detekt

Если detekt найдёт проблемы, пайплайн упадёт. Это жёстко, но эффективно. Можно настроить уровень сложности или игнорировать некоторые правила через конфиг.

Также рекомендую добавить ktlint для проверки форматирования:

      - name: Check formatting with ktlint
        run: ./gradlew ktlintCheck

Теперь ваш Kotlin CI/CD pipeline проверяет не только логику, но и стиль кода.

Шаг 4. Автоматическая публикация артефактов

Допустим, вы разрабатываете библиотеку и хотите публиковать её в GitHub Packages или Maven Central. Добавим этап публикации, который срабатывает только при пуше в main.

Дополните ci.yml новым джобом:

  publish:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

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

      - name: Publish to GitHub Packages
        run: ./gradlew publish
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Для публикации в GitHub Packages нужно настроить build.gradle