CI/CD für Kotlin: Pipeline-Einrichtung von Grund auf an einem realen Projekt

Sie haben ein tolles Projekt in Kotlin geschrieben. Aber wie liefern Sie Updates jetzt ohne Schmerz aus?

Sie haben Code committed, auf GitHub gepusht und … mit dem manuellen Ritual begonnen: jar bauen, auf den Server laden, neu starten, prüfen, ob nichts abgestürzt ist. Kommt Ihnen das bekannt vor? Und wenn das Projekt wächst, Tests, Linter, mehrere Umgebungen hinzukommen – die Routine frisst Stunden, und ein einziger vergessener Befehl kann die Produktion zum Absturz bringen.

Es gibt einen Ausweg – die CI/CD-Pipeline für Kotlin. Das ist ein automatisiertes Förderband, das das Projekt selbstständig baut, Tests durchführt, den Codestil prüft und nach jedem Push auf den Server deployed. In diesem Artikel zeige ich Ihnen, wie Sie eine solche Pipeline von Grund auf mit GitHub Actions und Gradle einrichten. Sie erhalten eine fertige Vorlage, die Sie an Ihr Projekt anpassen können – sei es eine Serveranwendung mit Ktor, eine Android-App oder eine Bibliothek.

Los geht's! 🚀

Was ist CI/CD und warum braucht ein Kotlin-Entwickler das?

CI (Continuous Integration) – kontinuierliche Integration. Sie pushen Code, und das System baut ihn automatisch, testet ihn und prüft die Qualität. CD (Continuous Delivery/Deployment) – kontinuierliche Auslieferung oder Bereitstellung. Nach einem erfolgreichen Build gelangt der Code automatisch auf den Server (oder in den App Store).

Für Kotlin-Projekte ist CI/CD besonders wichtig:

\n
• Zeitersparnis – Sie müssen den gradle build nicht manuell starten.
\n
• Codequalität – Tests und Linter werden bei jedem Commit ausgelöst.
\n
• Sicherheit – Die Produktion wird nur nach einer grünen Pipeline aktualisiert.
\n
• Transparenz – Das gesamte Team sieht den Build-Status.
\n

Heute bauen wir eine vollwertige CI/CD-Pipeline für Kotlin mit GitHub Actions. Das ist für öffentliche Repositories kostenlos und sehr flexibel.

Schritt 1. Vorbereitung des Kotlin-Projekts

Bevor wir die Pipeline schreiben, stellen Sie sicher, dass Ihr Projekt für CI/CD bereit ist. Ich verwende eine typische Struktur mit Gradle (Kotlin DSL).

Hier ist ein Beispiel für build.gradle.kts für eine einfache Konsolenanwendung:

plugins {\n    kotlin("jvm") version "1.9.22"\n    application\n}\n\napplication {\n    mainClass.set("com.example.MainKt")\n}\n\nrepositories {\n    mavenCentral()\n}\n\ndependencies {\n    implementation(kotlin("stdlib"))\n    testImplementation("org.jetbrains.kotlin:kotlin-test")\n}\n\ntasks.test {\n    useJUnitPlatform()\n}

Wichtig: Fügen Sie mindestens einen Test hinzu, damit die Pipeline einen Sinn ergibt.

Beispiel für einen Test (src/test/kotlin/com/example/AppTest.kt):

import kotlin.test.Test\nimport kotlin.test.assertEquals\n\nclass AppTest {\n    @Test\n    fun testGreeting() {\n        assertEquals("Hello, Kotlin!", getGreeting())\n    }\n}

Committen und pushen Sie das Projekt nun auf GitHub.

Schritt 2. Erstellen der ersten CI-Pipeline: Build und Tests

Erstellen Sie im Stammverzeichnis des Repositorys den Ordner .github/workflows und darin die Datei ci.yml.

Hier ist ein minimaler GitHub Actions-Workflow für Kotlin:

name: CI Pipeline for Kotlin\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Checkout code\n        uses: actions/checkout@v4\n\n      - name: Set up JDK 17\n        uses: actions/setup-java@v4\n        with:\n          java-version: '17'\n          distribution: 'temurin'\n\n      - name: Grant execute permission for gradlew\n        run: chmod +x gradlew\n\n      - name: Build with Gradle\n        run: ./gradlew build\n\n      - name: Run tests\n        run: ./gradlew test\n\n      - name: Archive test results\n        if: always()\n        uses: actions/upload-artifact@v4\n        with:\n          name: test-results\n          path: build/reports/tests/

Was passiert hier:

\n
• Auslöser: push