CI/CD pour Kotlin : configuration d'un pipeline de zéro sur un projet réel

Vous avez écrit un super projet en Kotlin. Mais comment livrer les mises à jour sans douleur ?

Vous avez commité le code, poussé sur GitHub et… commencé le rituel manuel : compiler le jar, le transférer sur le serveur, redémarrer, vérifier que rien n'est tombé. Familier ? Et si le projet grandit, avec des tests, des linters, plusieurs environnements — la routine vous prend des heures, et une seule commande oubliée peut faire planter la prod.

Il y a une solution — le pipeline CI/CD pour Kotlin. C'est un pipeline automatique qui compile le projet, exécute les tests, vérifie le style de code et déploie sur le serveur après chaque push. Dans cet article, je vais vous montrer comment configurer un tel pipeline de zéro avec GitHub Actions et Gradle. Vous obtiendrez un modèle prêt à l'emploi que vous pouvez adapter à votre projet — que ce soit une application serveur avec Ktor, une application Android ou une bibliothèque.

C'est parti ! 🚀

Qu'est-ce que le CI/CD et pourquoi en a-t-on besoin en tant que développeur Kotlin ?

CI (Continuous Integration) — intégration continue. Vous poussez du code, et le système le compile, le teste et vérifie la qualité automatiquement. CD (Continuous Delivery/Deployment) — livraison ou déploiement continus. Après une compilation réussie, le code est automatiquement envoyé sur le serveur (ou dans le magasin d'applications).

Pour les projets Kotlin, le CI/CD est particulièrement important :

\n
• Gain de temps — plus besoin de lancer manuellement gradle build.
\n
• Qualité du code — les tests et les linters s'exécutent à chaque commit.
\n
• Sécurité — la prod n'est mise à jour qu'après un pipeline vert.
\n
• Transparence — toute l'équipe voit le statut de la compilation.
\n

Aujourd'hui, nous allons construire un pipeline CI/CD complet pour Kotlin avec GitHub Actions. C'est gratuit pour les dépôts publics et très flexible.

Étape 1. Préparation du projet Kotlin

Avant d'écrire le pipeline, assurez-vous que votre projet est prêt pour le CI/CD. J'utiliserai une structure typique avec Gradle (Kotlin DSL).

Voici un exemple de build.gradle.kts pour une simple application console :

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}

Important : ajoutez au moins un test pour que le pipeline ait un sens.

Exemple de 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}

Maintenant, commitez et poussez le projet sur GitHub.

Étape 2. Création du premier pipeline CI : compilation et tests

À la racine du dépôt, créez un dossier .github/workflows et à l'intérieur un fichier ci.yml.

Voici un workflow GitHub Actions minimal pour 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/

Ce qui se passe ici :

\n
• Déclencheurs : push