CI/CD für Kotlin-Projekte mit GitHub Actions: Vollständiger Leitfaden

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Einleitung: Warum CI/CD für Kotlin-Projekte entscheidend ist

Moderne Kotlin-Entwicklung – ob Backend mit Spring Boot, Android-App oder Multiplattform-Projekt – erfordert einen schnellen und zuverlässigen Lieferzyklus. Manuelle Build- und Testprozesse sind nicht nur zeitaufwendig, sondern auch fehleranfällig. Hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel.

GitHub Actions ist ein integriertes Automatisierungssystem, mit dem Sie Workflows direkt in Ihrem Repository ausführen können. Für Kotlin-Projekte ist es die ideale Wahl: Es lässt sich einfach in Gradle integrieren, unterstützt das Caching von Abhängigkeiten und ermöglicht die Bereitstellung von Anwendungen auf jeder Plattform.

In diesem Artikel werden wir durchgehen, wie man eine vollständige CI/CD-Pipeline für ein Kotlin-Projekt mit GitHub Actions einrichtet: vom grundlegenden Build bis zum automatischen Deployment.

1. Grundlagen von GitHub Actions: Struktur eines Workflows

Jeder Workflow in GitHub Actions ist eine YAML-Datei, die sich im Verzeichnis .github/workflows/ befindet. Betrachten wir die grundlegenden Komponenten am Beispiel eines Kotlin-Projekts.

1.1. Trigger (on)

Ein Workflow wird durch bestimmte Ereignisse ausgelöst: Push in einen Branch, Erstellung eines Pull Requests oder nach einem Zeitplan (cron).

1.2. Jobs und Steps

Ein Job ist eine Reihe von Schritten, die in einer einzigen virtuellen Umgebung ausgeführt werden. Steps können Befehle, Skripte oder vorgefertigte Actions aus dem Marketplace ausführen.

1.3. Beispiel eines minimalen Workflows

Erstellen wir eine Datei .github/workflows/ci.yml für ein Kotlin-Projekt mit 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

Diese Pipeline wird bei jedem Push oder PR in main/develop den Build und die Tests ausführen.

2. CI-Optimierung: Caching und parallele Aufgaben

Ohne Optimierung wird jeder Lauf die Gradle-Abhängigkeiten erneut herunterladen. Für Kotlin-Projekte kann dies 2–5 Minuten dauern. Die Lösung ist Caching.

2.1. Caching des Gradle-Caches

GitHub Actions ermöglicht das Caching des Verzeichnisses ~/.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-

Nach dem ersten Lauf verwenden nachfolgende Läufe den Cache – die Geschwindigkeit erhöht sich um das 2- bis 3-fache.

2.2. Parallele Jobs für verschiedene Aufgaben

Man kann Tests, Linting und Build in separate Jobs aufteilen, die parallel ausgeführt werden:

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

Hier startet build erst, nachdem Linting und Tests erfolgreich bestanden wurden.