CI/CD pour projets Kotlin : GitHub Actions de A à Z

Introduction au CI/CD pour Kotlin avec GitHub Actions

Dans le développement moderne, l'automatisation des processus de compilation, de test et de déploiement est devenue une partie intégrante d'une approche professionnelle. Pour les projets Kotlin, qu'il s'agisse d'applications Android, de services backend avec Ktor ou de bibliothèques multiplateformes, la configuration du CI/CD (Continuous Integration / Continuous Deployment) permet de réduire considérablement le temps de mise sur le marché et de diminuer le risque d'erreurs.

GitHub Actions est un outil puissant et flexible intégré à l'écosystème GitHub. Il permet de créer des pipelines personnalisés qui s'exécutent automatiquement lors des pushs, de la création de pull requests ou selon un calendrier. Dans cet article, nous allons parcourir le cycle complet de configuration CI/CD pour Kotlin : de la vérification de base du code au déploiement automatique.

Fondamentaux de GitHub Actions : structure et syntaxe

Avant de plonger dans les spécificités de Kotlin, il est important de comprendre les concepts de base de GitHub Actions. Le pipeline est décrit dans des fichiers YAML stockés dans le répertoire .github/workflows/ de votre dépôt.

Éléments clés d'un workflow

• Event (événement) : déclencheur qui lance le pipeline (push, pull_request, release, etc.).
• Job (tâche) : ensemble d'étapes exécutées sur un même runner (machine virtuelle).
• Step (étape) : action spécifique — exécution d'une commande, lancement d'un script ou utilisation d'un action prêt à l'emploi.
• Runner : environnement d'exécution (Ubuntu, Windows, macOS).

Structure de base du fichier kotlin-ci.yml :

name: Kotlin CI

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

Configuration CI pour Kotlin : compilation, tests et linting

La première et la plus importante étape est l'intégration continue. Elle garantit que chaque nouveau code compile et ne casse pas les tests existants.

Mise en cache des dépendances Gradle

Pour accélérer la compilation, utilisez impérativement la mise en cache. Sans elle, chaque exécution téléchargera à nouveau toutes les bibliothèques.

- name: Cache Gradle packages  uses: actions/cache@v3  with:    path: |      ~/.gradle/caches      ~/.gradle/wrapper    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}    restore-keys: |      ${{ runner.os }}-gradle-

Exécution des tests et vérification du style

Ajoutons des étapes pour exécuter les tests unitaires et le linter (detekt ou ktlint). Cela permet de maintenir la qualité du code.

- name: Run tests  run: ./gradlew test

- name: Run linter  run: ./gradlew detekt

Exemple de workflow CI complet pour un projet Kotlin

jobs:  test:    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: Cache Gradle        uses: actions/cache@v3        with:          path: ~/.gradle/caches          key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle.kts') }}      - name: Build and test        run: ./gradlew check

Continuous Deployment : déploiement automatique des applications Kotlin

Après une intégration réussie vient l'étape du déploiement. Pour les projets Kotlin, cela peut signifier la publication d'une bibliothèque sur Maven Central, le déploiement d'un backend sur un serveur ou la compilation d'un APK pour Android.

Déploiement d'un service backend avec Ktor

Supposons que nous ayons une application Kotlin utilisant le framework Ktor. Nous voulons automatiser