Mettre en place un pipeline CI/CD automatisé avec GitLab pour des projets Spring Boot et Angular

```html

Mettre en place un pipeline CI/CD automatisé avec GitLab pour des projets Spring Boot et Angular

Un pipeline CI/CD dans GitLab permet d’automatiser les étapes de build, tests, analyse et déploiement. Pour un projet combinant Spring Boot (back-end) et Angular (front-end), l’objectif est de garantir une exécution fiable, reproductible et rapide sur chaque commit, tout en sécurisant le passage en production via des environnements maîtrisés.

Architecture recommandée

Une structure mono-repository (monorepo) simplifie souvent la gestion de versions, mais impose une discipline claire sur les chemins et les artefacts. Une séparation logique améliore la lisibilité :

/repository /backend (Spring Boot) /frontend (Angular) /.gitlab-ci.yml /docs /docker

Les images Docker (si utilisées) peuvent être construites séparément pour chaque composant, puis déployées via Helm, Kubernetes, ou des scripts spécifiques à l’infrastructure cible.

Pré-requis

Composants techniques

• GitLab (instance SaaS ou auto-hébergée)

• Runners configurés : shell, Docker, ou Kubernetes runner

• Java et Maven (ou Gradle) côté back-end

• Node.js et Angular CLI côté front-end

• Registry (GitLab Container Registry, Nexus, etc.) si des images Docker sont publiées

Variables GitLab

Les paramètres sensibles (tokens, identifiants) doivent être stockés dans CI/CD Variables.

• REGISTRY_USER / REGISTRY_PASSWORD

• DOCKER_IMAGE_BACKEND et DOCKER_IMAGE_FRONTEND (ex. registry.example.com/group/app-backend)

• KUBE_CONFIG ou variables équivalentes selon la méthode de déploiement

• SPRING_PROFILES_ACTIVE (si nécessaire)

Pipeline GitLab CI/CD : principes et stratégie

Le pipeline peut être organisé en étapes typiques :

• install / build : compilation back-end et front-end

• test : exécution des tests unitaires et éventuellement d’intégration

• scan : analyse de sécurité (dépendances, vulnérabilités)

• package : génération des artefacts (JAR, bundle Angular)

• build-image : construction d’images Docker (optionnel mais courant)

• deploy : déploiement vers dev/stage/prod avec gated releases

Exemple de fichier .gitlab-ci.yml

Le snippet ci-dessous propose une base cohérente. Il privilégie la séparation des jobs, l’utilisation de caches, et un flux “qualité avant déploiement”.

stages: - backend_test - frontend_test - security_scan - build_images - deploy variables: MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode -DskipTests=false" NODE_ENV: "production" cache: paths: - backend/.m2/repository - frontend/node_modules backend_test: stage: backend_test image: maven:3.9.6-eclipse-temurin-17 script: - cd backend - mvn $MAVEN_CLI_OPTS test artifacts: when: always reports: junit: backend/target/surefire-reports/*.xml paths: - backend/target/*.jar expire_in: 7 days rules: - if: $CI_PIPELINE_SOURCE == "push" frontend_test: stage: frontend_test image: node:20 script: - cd frontend - npm ci - npm test -- --watch=false --browsers=ChromeHeadless - npm run build -- --configuration=production artifacts: when: always paths: - frontend/dist/ expire_in: 7 days rules: - if: $CI_PIPELINE_SOURCE == "push" security_scan: stage: security_scan image: alpine:3.20 script: - echo "Exemple : intégration d'un scanner (dependency scanning) requérant un outil" - echo "S'assurer de configurer les rapports et l'échec sur vulnérabilités critiques" rules: - if: $CI_COMMIT_BRANCH build_backend_image: stage: build_images image: docker:26 services: - name: docker:26-dind command: ["--mtu=1460"] variables: DOCKER_TLS_CERTDIR: "/certs" script: - echo "$REGISTRY_PASSWORD" | docker login -u "$REGISTRY_USER" --password-stdin $CI_REGISTRY - docker build -t $DOCKER_IMAGE_BACKEND:$CI_COMMIT_SHORT_SHA backend - docker push $DOCKER_IMAGE_BACKEND:$CI_COMMIT_SHORT_SHA rules: - if: $CI_COMMIT_BRANCH == "main" build_frontend_image: stage: build_images image: docker:26 services: - name: docker:26-dind variables: DOCKER_TLS_CERTDIR: "/certs" script: - echo "$REGISTRY_PASSWORD" | docker login -u "$REGISTRY_USER" --password-stdin $CI_REGISTRY - docker build -t $DOCKER_IMAGE_FRONTEND:$CI_COMMIT_SHORT_SHA frontend - docker push $DOCKER_IMAGE_FRONTEND:$CI_COMMIT_SHORT_SHA rules: - if: $CI_COMMIT_BRANCH == "main" deploy_dev: stage: deploy image: bitnami/kubectl:1.30 script: - echo "Déploiement vers environnement dev (exemple Kubernetes)" - kubectl config set-cluster default --server="$K8S_SERVER" --insecure-skip-tls-verify=true - kubectl config set-context default --cluster=default --user=default - kubectl apply -f k8s/dev/ - kubectl -n dev set image deployment/backend backend=$DOCKER_IMAGE_BACKEND:$CI_COMMIT_SHORT_SHA - kubectl -n dev set image deployment/frontend frontend=$DOCKER_IMAGE_FRONTEND:$CI_COMMIT_SHORT_SHA environment: name: dev rules: - if: $CI_COMMIT_BRANCH == "main" when: manual

Back-end Spring Boot : bonnes pratiques

Tests reproductibles

Les tests doivent être stables et isolés. Les dépendances externes (bases de données, services tiers) gagnent à être simulées via Testcontainers ou des profils dédiés.

Rapports JUnit

Le pipeline doit publier des rapports JUnit pour exploiter les résultats dans l’interface GitLab et permettre un suivi fiable de la qualité.

Front-end Angular : optimiser le build et les tests

Cache Node

Le cache des dépendances node_modules accélère fortement les pipelines. Si une stratégie de cache plus fine est préférée (cache npm), elle peut être appliquée selon l’organisation.

Build “production”

Le build en configuration production garantit que l’artefact deployable correspond au comportement attendu en environnement réel.

Sécurité : scanning et conformité

L’étape de scanning doit idéalement couvrir :

• vulnérabilités de dépendances (Maven/Node)

• secrets (détection de clés accidentelles)

• analyse SAST (selon les outils intégrés)

Pour limiter les interruptions, le pipeline peut être paramétré pour échouer uniquement sur un niveau de sévérité (ex. critique), tout en publiant les rapports pour traitement.

Déploiement : environnements, approbations, stratégie progressive

Un déploiement robuste utilise :

• environments GitLab (dev/stage/prod)

• deployments manuels pour les étapes sensibles (ex. prod)

• rollback via tags d’images Docker immuables

Règle d’or : “qualité avant production”

Le déploiement en prod ne doit démarrer que lorsque les étapes de test et scanning sont passées. GitLab facilite cette approche via des stages ordonnés, des rules et des environnements.

Améliorations avancées

Paralléliser ce qui est indépendant

Back-end et front-end peuvent être testés en parallèle. La séparation des jobs réduit la durée totale du pipeline.

Déploiements basés sur tags

Un déclenchement via tag (ex. v1.2.3) permet des releases reproductibles et traçables.

Artifact immutables

Lorsque des artefacts sont produits, ils gagnent à être versionnés ou stockés (JAR et bundle dist), afin de reproduire exactement la build associée à un déploiement.

Conclusion

Un pipeline CI/CD GitLab pour Spring Boot et Angular combine une exécution structurée (stages), des tests fiables (back-end et front-end), un scanning sécurité (dépendances et secrets), puis un déploiement progressif par environnements. Cette démarche améliore la qualité logicielle, réduit le risque en production et accélère le cycle de livraison.