CI/CD für Kotlin-Projekte mit GitHub Actions: Schritt-für-Schritt-Anleitung

Einleitung: Warum CI/CD für die Kotlin-Entwicklung unverzichtbar ist

Moderne Kotlin-Entwicklung bedeutet nicht nur, prägnanten und sicheren Code zu schreiben, sondern auch dessen kontinuierliche Bereitstellung sicherzustellen. Ob Sie eine Serveranwendung mit Ktor, eine Android-App oder ein Multiplattform-Projekt erstellen, manuelle Builds und Tests werden schnell zum Engpass. CI/CD (Continuous Integration / Continuous Deployment) automatisiert diese Prozesse, reduziert das Risiko menschlicher Fehler und beschleunigt die Auslieferung neuer Features.

GitHub Actions ist eines der beliebtesten Werkzeuge zur Implementierung von CI/CD, insbesondere wenn Ihr Code bereits auf GitHub gehostet wird. Es ist eng in die Kotlin-Ökosystem integriert, unterstützt Gradle und Maven und ermöglicht eine flexible Konfiguration von Pipelines für jeden Bedarf. In diesem Artikel werden wir durchgehen, wie man einen vollständigen Build-, Test- und Deployment-Zyklus für ein Kotlin-Projekt mit GitHub Actions einrichtet.

Grundlagen von GitHub Actions: Struktur eines Workflows

Bevor wir Code schreiben, schauen wir uns die grundlegenden Konzepte an. Ein Workflow in GitHub Actions ist ein automatisierter Prozess, der durch ein bestimmtes Ereignis ausgelöst wird (z. B. ein Push in den main-Branch). Der Workflow wird in einer YAML-Datei beschrieben, die im Verzeichnis .github/workflows/ Ihres Repositorys gespeichert wird.

Eine typische Workflow-Struktur umfasst:

• name — der Name des Workflows (wird in der GitHub-Oberfläche angezeigt).
• on — die Auslöser (z. B. push, pull_request).
• jobs — eine Reihe von Aufgaben, die sequenziell oder parallel ausgeführt werden.
• steps — die Schritte innerhalb eines Jobs (Installation des JDK, Caching von Abhängigkeiten, Ausführen von Tests).

Für Kotlin-Projekte ist der wichtigste Schritt die Konfiguration der richtigen JDK-Version (normalerweise 11, 17 oder 21) und die Verwendung des Gradle Wrappers (./gradlew), der die Reproduzierbarkeit des Builds auf jeder Maschine gewährleistet.

Schritt 1: Basis-Build und Testen eines Kotlin-Projekts

Beginnen wir mit dem Einfachsten: einem Workflow, der bei jedem Push in main oder bei der Erstellung eines Pull Requests die Tests ausführt. Dies ist die Grundlage jedes CI/CD – sicherzustellen, dass der Code die vorhandene Funktionalität nicht beschädigt hat.

Erstellen Sie die Datei .github/workflows/ci.yml mit folgendem Inhalt:

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

Lassen Sie uns die wichtigsten Punkte durchgehen:

• actions/checkout@v4 — klont das Repository in den Runner.
• actions/setup-java@v4 — installiert JDK 17 (Temurin). Sie können eine andere Version wählen, wenn Ihr Projekt z. B. JDK 11 oder 21 erfordert.
• actions/cache@v4 — cached die Gradle-Abhängigkeiten. Dies ist entscheidend für die Geschwindigkeit: Ohne Cache würde jeder Build alle Bibliotheken erneut herunterladen (kann 2-5 Minuten dauern). Der Cache beschleunigt diesen Prozess auf wenige Sekunden.
• ./gradlew build — vollständiger Projekt-Build (Kompilierung + Tests). Wenn Sie nur Tests ausführen möchten, verwenden Sie ./gradlew test.