Bienvenue dans la sixième et dernière partie de notre série de tutoriels sur l’intégration d’Apache Kafka dans une application moderne ! Nous avons déjà accompli un travail considérable. En effet, nous avons posé les bases architecturales dans la première partie, mis en place notre environnement de développement Dockerisé dans la deuxième partie, et construit notre backend Spring Boot avec Kafka dans les troisième et quatrième parties. Plus récemment, la cinquième partie nous a permis de développer et dockeriser notre frontend Vue.js.
Il est maintenant temps d’aborder une étape cruciale pour tout projet moderne et professionnel : l’automatisation du cycle de développement. Dans cette section finale, nous allons donc automatiser le build, les tests, et le packaging Docker de notre projet fullstack grâce à GitLab CI/CD. L’objectif principal est simple : garantir que notre application fonctionne correctement après chaque modification de code, sans avoir à tout relancer manuellement, ce qui améliore considérablement la vélocité et la fiabilité de nos livraisons.
💡 Code source complet de l’exercice
Vous pouvez consulter et cloner le code source correspondant à ce tutoriel sur GitLab :
👉gitlab.com/springboot-kafka-social-lab/tag=v1.0.0
Ce tag v1.0.0 correspond à la version réalisée dans ce tutoriel.
De plus, le projet continuera à évoluer. Par conséquent, vous pouvez également consulter la branche main ou develop pour suivre les mises à jour ultérieures.
1. Introduction à GitLab CI/CD
L’intégration continue (CI) et le déploiement continu (CD) sont des pratiques fondamentales dans le développement logiciel agile. Elles consistent à automatiser les différentes phases du cycle de vie du logiciel : compilation, tests, déploiement. GitLab CI/CD est un outil puissant intégré à GitLab qui permet de mettre en œuvre ces pipelines directement depuis votre dépôt de code.
Pour ce faire, nous allons exploiter les pipelines GitLab pour enchaîner automatiquement trois étapes clés après chaque modification de code poussée sur le dépôt :
- Tester le backend Spring Boot.
- Compiler le frontend Vue.js.
- Dockeriser l’ensemble des composants (backend et frontend) et pousser les images vers un registre.
2. Exemple de fichier .gitlab-ci.yml
Le cœur de notre pipeline CI/CD réside dans le fichier .gitlab-ci.yml. Ce fichier, écrit en YAML, doit être placé à la racine de votre projet GitLab. Il définit toutes les étapes, ou « jobs », qui seront exécutées par les runners GitLab.
Voici un exemple de configuration complète que vous pouvez adapter à votre projet :
# GitLab CI/CD configuration for a fullstack project: Spring Boot (backend) + Vue.js (frontend) + Docker
stages:
- backend-test
- frontend-test
- docker-build
# --- 1. Build and test the backend ---
backend_test:
stage: backend-test
image: eclipse-temurin:21-jdk # Official Java 21 image
script:
- cd backend
- ./gradlew clean build # Compile le backend et exécute les tests unitaires
artifacts:
paths:
- backend/build/libs/
expire_in: 1 hour
# --- 2. Build and test the frontend ---
frontend_build:
stage: frontend-test
image: node:20 # Official Node.js 20 image
script:
- cd frontend
- npm ci # Installation propre des dépendances
- npm run build # Build du frontend
# - npm run test:unit # (optionnel) Ajouter des tests unitaires
artifacts:
paths:
- frontend/dist/
expire_in: 1 hour
# --- 3. Build and push Docker images ---
docker_build:
stage: docker-build
image: docker:latest
services:
- docker:dind # Docker-in-Docker, nécessaire pour builder des images
variables:
DOCKER_HOST: tcp://docker:2375/
before_script:
- docker info # Vérifie que Docker est bien disponible
script:
- docker build -t $CI_REGISTRY_IMAGE/backend:latest ./backend
- docker build -t $CI_REGISTRY_IMAGE/frontend:latest ./frontend
- echo "$CI_JOB_TOKEN" | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
- docker push $CI_REGISTRY_IMAGE/backend:latest
- docker push $CI_REGISTRY_IMAGE/frontend:latest
only:
- main
- master
- develop
2.1. Explication détaillée des étapes du pipeline
- stages : Ce bloc définit l’ordre d’exécution des étapes. Par conséquent, les jobs de la même stage s’exécutent en parallèle, et les stages s’exécutent séquentiellement.
- backend_test :
- Utilise une image Java 21 officielle (eclipse-temurin:21-jdk).
- Se déplace dans le dossier backend et exécute ./gradlew clean build, ce qui compile le projet Spring Boot et lance les tests unitaires éventuels.
- Les artifacts (le fichier .jar généré) sont conservés pendant 1 heure, ce qui est utile pour les jobs suivants ou pour une inspection manuelle.
- frontend_build :
- Utilise une image Node.js 20 (node:20).
- Se positionne dans le dossier frontend puis exécute npm ci (pour une installation propre des dépendances) et npm run build pour compiler l’interface Vue.js en mode production.
- Il est également possible d’ajouter des tests frontend (commenté par # npm run test:unit) si votre projet en contient.
- Les artifacts générés (le dossier dist/ contenant les fichiers statiques) sont aussi conservés.
- docker_build :
- Cette étape s’exécute dans une image docker:latest.
- Le service docker:dind (Docker-in-Docker) est requis pour pouvoir construire des images Docker à l’intérieur du conteneur du runner.
- Les commandes docker build construisent les images Docker du backend et du frontend à partir de leurs Dockerfile respectifs.
- Ensuite, la connexion au registre d’images GitLab (CI_REGISTRY) est effectuée.
- Finalement, les images sont poussées (docker push) vers le GitLab Container Registry, les rendant ainsi disponibles pour d’éventuels déploiements.
- Ce job est configuré pour s’exécuter uniquement sur les branches principales (main, master, develop) grâce à la directive only.
2.2. Visualisation du pipeline GitLab
Après avoir configuré et poussé ce fichier .gitlab-ci.yml vers votre dépôt GitLab, chaque commit déclenchera automatiquement l’exécution de ce pipeline. Vous pourrez suivre l’avancement des jobs directement depuis l’interface de GitLab, dans la section « CI/CD > Pipelines ».
Voici un aperçu visuel de notre pipeline GitLab en action, avec chaque étape exécutée avec succès : les tests backend, la compilation frontend, puis la construction des images Docker.
2.3. Bonnes pratiques CI/CD pour projets multi-services
Pour optimiser et maintenir vos pipelines CI/CD dans un contexte multi-services, quelques bonnes pratiques sont à retenir :
- Séparer les responsabilités : Il est préférable que les étapes de build, de test et de push Docker restent indépendantes. Cela facilite le débogage et la réutilisation des jobs.
- Limiter l’usage de docker:dind : L’utilisation de docker:dind (Docker-in-Docker) ralentit les jobs car il démarre un service Docker complet. Par conséquent, il est recommandé de le limiter aux étapes où la construction d’images Docker est strictement nécessaire, et de l’éviter pour les simples jobs de test ou de compilation.
- Conserver les artefacts : Les fichiers générés (comme les .jar du backend ou le dossier dist/ du frontend) peuvent être conservés en tant qu’artefacts. Cela est particulièrement pratique si vous envisagez un déploiement manuel ultérieur ou si un autre job doit les consommer.
- Filtrer les exécutions par branche : Pour des raisons de stabilité et de performance, ne publiez des images Docker (ou ne déployez) que depuis les branches stables ou de production (comme main, master, develop).
- Utiliser un fichier .env.ci : Si des variables d’environnement spécifiques à l’environnement CI/CD sont nécessaires, privilégiez un fichier .env.ci ou les variables CI/CD sécurisées de GitLab.
Conclusion
Félicitations ! 🎉
Vous avez atteint la fin de ce tutoriel complet. Vous avez réussi à combiner et maîtriser des technologies modernes telles que Spring Boot, Kafka, MySQL, Vue.js, et Docker. Plus important encore, vous avez appris à orchestrer le tout avec GitLab CI/CD. Ce projet constitue désormais une base solide, moderne et modulaire, idéale pour vos futures applications distribuées et pour une approche de développement professionnelle.
En résumé, au cours de cette série, nous avons appris à :
- Structurer proprement un projet backend/frontend.
- Intégrer Kafka comme système de messagerie asynchrone robuste.
- Conteneuriser l’ensemble de l’application avec Docker et Docker Compose.
- Automatiser les builds et les tests grâce à GitLab CI/CD, garantissant ainsi un déploiement plus fiable.
📌 Le code source de cet exercice est disponible sur GitLab :
👉 gitlab.com/springboot-kafka-social-lab/tag=v1.0.0
Le tag Git correspondant à l’état final du tutoriel est :
🔖 v1.0.0
💬 Et vous, qu’en pensez-vous ?
Vous avez rencontré un souci, une amélioration à proposer ou envie d’aller plus loin (authentification, tests automatisés, monitoring, etc.) ? N’hésitez pas à partager vos idées, questions ou retours d’expérience dans les commentaires ! Je réponds à chaque message et serais ravi d’échanger avec vous.
Merci pour votre lecture assidue,
et à très bientôt sur izo-nova.com pour de nouveaux tutoriels pratiques et accessibles 🚀
