Mettre en place un pipeline CI/CD GitLab pour un projet Spring Boot et Angular
La mise en place d’un pipeline CI/CD sur GitLab permet d’automatiser la compilation, les tests, la construction et le déploiement. Pour une application Spring Boot côté backend et Angular côté frontend, la stratégie la plus efficace consiste à séparer les étapes, mutualiser les caches et publier des artefacts versionnés.
Architecture recommandée
Le dépôt peut être organisé en deux sous-dossiers principaux :
frontend/
backend/
Le pipeline cible trois objectifs :
- CI : validation rapide à chaque commit (lint, tests, builds).
- Build : génération d’artefacts frontend et backend.
- CD : déploiement en environnement (staging/production) après validation.
Variables GitLab et prérequis
Variables à définir
Dans la section Settings > CI/CD > Variables, définir par exemple :
- DOCKER_REGISTRY : URL du registre (ex. registry.example.com).
- DOCKER_IMAGE : nom de l’image (ex. myapp).
- DOCKER_USERNAME et DOCKER_PASSWORD (ou token).
- SPRING_PROFILES_ACTIVE : profil utilisé en déploiement.
- STAGING_URL / PROD_URL (si déploiement via API).
Dépendances côté outils
Le pipeline s’appuie sur des images Docker officielles pour Node et Java afin d’obtenir une exécution reproductible.
Pipeline GitLab : exemple complet
Le fichier .gitlab-ci.yml ci-dessous montre une approche classique : stages install/build/test pour Angular et Spring Boot, puis build d’image Docker et déploiement.
Fichier .gitlab-ci.yml
stages:
- frontend_test
- backend_test
- build_image
- deploy_staging
- deploy_production
variables:
NODE_ENV: "production"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- frontend/node_modules/
- backend/.m2/repository/
frontend_test:
stage: frontend_test
image: node:20-bullseye
script:
- cd frontend
- npm ci
- npm run lint --if-present
- npm test -- --watch=false
- npm run build -- --configuration=production
artifacts:
paths:
- frontend/dist/
expire_in: 1 week
only:
- merge_requests
- main
backend_test:
stage: backend_test
image: maven:3.9-eclipse-temurin-17
script:
- cd backend
- mvn -B clean test
- mvn -B package -DskipTests=false
artifacts:
paths:
- backend/target/*.jar
expire_in: 1 week
only:
- merge_requests
- main
build_image:
stage: build_image
image: docker:27.1.1
services:
- name: docker:27.1.1-dind
command: ["--mtu=1460"]
variables:
DOCKER_TLS_CERTDIR: "/certs"
before_script:
- echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin "$DOCKER_REGISTRY"
script:
- export TAG="${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
- echo "Building image with tag: $TAG"
- docker build -t "$DOCKER_REGISTRY/$DOCKER_IMAGE:$TAG" .
- docker push "$DOCKER_REGISTRY/$DOCKER_IMAGE:$TAG"
- docker tag "$DOCKER_REGISTRY/$DOCKER_IMAGE:$TAG" "$DOCKER_REGISTRY/$DOCKER_IMAGE:latest"
- docker push "$DOCKER_REGISTRY/$DOCKER_IMAGE:latest"
only:
- main
deploy_staging:
stage: deploy_staging
image: alpine:3.20
script:
- apk add --no-cache curl bash
- export TAG="${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
- >
curl -X POST "$STAGING_URL/deploy"
-H "Content-Type: application/json"
-d "{\"image\":\"$DOCKER_REGISTRY/$DOCKER_IMAGE:$TAG\",\"profile\":\"$SPRING_PROFILES_ACTIVE\"}"
environment:
name: staging
only:
- main
deploy_production:
stage: deploy_production
image: alpine:3.20
script:
- apk add --no-cache curl bash
- export TAG="${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"
- >
curl -X POST "$PROD_URL/deploy"
-H "Content-Type: application/json"
-d "{\"image\":\"$DOCKER_REGISTRY/$DOCKER_IMAGE:$TAG\",\"profile\":\"production\"}"
environment:
name: production
only:
- main
when: manual
Rôle des artefacts et du cache
Artefacts
Les artefacts permettent de conserver des sorties de build, notamment :
- frontend/dist/ généré par Angular.
- backend/target/*.jar produit par Maven.
Ils peuvent être exploités dans des jobs ultérieurs ou pour investiguer un échec de pipeline.
Cache
Le cache accélère les exécutions en réutilisant :
- node_modules côté frontend (à nuancer selon les stratégies de versions).
- .m2/repository côté backend (très efficace pour Maven).
Construction Docker : approche pratique
Un Dockerfile bien conçu permet de packager le backend Spring Boot et de servir le frontend Angular (souvent via le backend qui expose les fichiers statiques).
Exemple de principe de Dockerfile
Le fichier exact dépend du mode de packaging choisi (serving via Spring, ou serveur Nginx séparé). Un exemple conceptuel :
# Stage 1: build frontend
# Stage 2: build backend (ou récupérer jar)
# Stage 3: assembler l'image finale
# Serve static files + run spring boot
Dans tous les cas, la clé est de produire une image reproductible et de la publier avec un tag basé sur CI_COMMIT_SHORT_SHA.
Qualité logicielle : lint, tests et couverture
Frontend (Angular)
Les commandes typiques incluent :
npm ci
npm run lint
npm test -- --watch=false
npm run build -- --configuration=production
Backend (Spring Boot)
Pour Maven :
mvn -B clean test
mvn -B package
En fonction des besoins, le pipeline peut être enrichi avec des rapports de couverture et l’upload vers un outil (ex. SonarQube).
Déploiement : options courantes
Le job de déploiement peut :
- Appeler une API interne (microservice de déploiement).
- Exécuter un script sur une machine cible via SSH (à sécuriser strictement).
- Déclencher un déploiement Kubernetes (kubectl/helm) si un cluster est utilisé.
Meilleures pratiques
- Séparer les stages pour réduire le temps d’attente et simplifier le diagnostic.
- Tagger les images avec commit + SHA pour une traçabilité parfaite.
- Utiliser des environnements GitLab (staging/production) pour une visibilité claire.
- Rendre la production manuelle (when: manual) pour limiter les déploiements accidentels.
- Gérer les secrets via les variables GitLab, jamais en dur dans le repo.
Conclusion
Un pipeline CI/CD GitLab pour Spring Boot et Angular gagne en robustesse lorsqu’il combine : exécution reproductible via images Docker, cache efficace pour Maven/Node, artefacts exploitables, et publication d’images avec tags versionnés. Avec une étape de déploiement contrôlée (staging automatique, production manuelle), la livraison devient à la fois rapide et fiable.
Liens utiles
Documentation GitLab CI/CD : CI/CD & Templates
Angular : Testing & Build
Spring Boot : Testing & Packaging
À propos de l'auteur
Laty Gueye Samba est développeur Full Stack basé à Dakar, Sénégal. Spécialiste des écosystèmes Java / Spring Boot et Angular.
Contact : latygueyesamba@gmail.com | Dakar, Sénégal