Introduction : Pourquoi CI/CD est la norme du développement Java moderne
\nDans le monde du développement Java, la rapidité et la qualité de la livraison du code sont cruciales. Chaque jour, les équipes apportent des centaines de modifications, et sans automatisation, le processus d'intégration devient chaotique. CI/CD (Continuous Integration / Continuous Deployment) résout ce problème : le code est automatiquement compilé, testé et déployé sur les serveurs.
\nL'outil GitHub Actions est une solution CI/CD intégrée directement dans le dépôt. Il permet de créer des pipelines (workflows) en YAML qui réagissent aux push, pull request ou autres événements. Dans cet article, nous allons détailler le cycle complet de configuration CI/CD pour un projet Java : de la construction de base au déploiement dans le cloud.
\nVous apprendrez à accélérer le développement, éviter les erreurs et automatiser les tâches répétitives. C'est parti !
\n\n1. Bases de GitHub Actions : structure d'un workflow
\nQu'est-ce que GitHub Actions ?
\nGitHub Actions est une plateforme d'automatisation des processus de travail. Un workflow (processus de travail) est un ensemble d'étapes exécutées lorsqu'un événement se produit (par exemple, un push vers la branche main). Chaque workflow se compose de :
\n- \n
- Event — le déclencheur (push, pull_request, schedule). \n
- Jobs — les tâches exécutées sur des machines virtuelles (runner). \n
- Steps — les actions spécifiques (exécution d'un script, installation des dépendances). \n
Pour un projet Java, un workflow typique comprend : le téléchargement du code, l'installation du JDK, la compilation avec Maven/Gradle, l'exécution des tests et la publication des artefacts.
\n\nCréation du premier workflow pour Java
\nCréez à la racine du dépôt un dossier .github/workflows/ et un fichier ci.yml. Voici un exemple minimal pour un projet Maven :
name: Java CI with Maven\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n build:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v4\n - name: Set up JDK 17\n uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n - name: Build with Maven\n run: mvn clean compile\n - name: Run tests\n run: mvn test\nCe workflow se déclenche lors d'un push ou d'une pull request vers main. Il vérifie que le code se compile et que les tests réussissent. Si un test échoue, le workflow se termine par une erreur et vous recevez une notification.
\n\n2. Configuration avancée : mise en cache, matrices et artefacts
\nMise en cache des dépendances
\nMaven et Gradle téléchargent les dépendances à chaque fois, ce qui est lent. GitHub Actions prend en charge la mise en cache. Ajoutez une étape avec actions/cache :
- name: Cache Maven packages\n uses: actions/cache@v4\n with:\n path: ~/.m2/repository\n key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}\n restore-keys: |\n ${{ runner.os }}-maven-\nLa clé du cache est basée sur le hachage du fichier pom.xml. Si le fichier n'a pas changé, les dépendances sont restaurées depuis le cache, ce qui réduit le temps de compilation de 2 à 3 fois.
Matrice de builds (Matrix Build)
\nLes projets Java sont souvent testés sur plusieurs versions de JDK et de systèmes d'exploitation. Utilisez la stratégie matrix :
\njobs:\n test:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n java: [11, 17, 21]\n steps:\n - uses: actions/checkout@v4\n - name: Set up JDK ${{ matrix.java }}\n uses: actions/setup-java@v4\n with:\n java-version: ${{ matrix.java }}\n distribution: 'temurin'\n - name: Test with Maven\n run: mvn test\nGitHub créera 3 jobs parallèles — pour Java 11, 17 et 21. Cela garantit la compatibilité du code avec différentes versions du JDK.
\n\nSauvegarde des artefacts
\nAprès la compilation, le fichier JAR peut être sauvegardé comme artefact pour le télécharger manuellement ou l'utiliser dans un job suivant :
\n- name: Upload JAR artifact\n uses: actions/upload-artifact@v4\n with