Automatisation du déploiement continu avec GitLab CI/CD pour Spring Boot et Angular

Introduction

Automatisation du déploiement continu avec GitLab CI/CD permet d'orchestrer la chaîne de construction, de test et de livraison pour des applications Spring Boot (backend) et Angular (frontend). Cet article décrit une approche pratique, reproductible et sécurisée pour construire, tester, empaqueter en image Docker et déployer automatiquement vers un cluster Kubernetes ou un hôte Docker.

Prérequis

Un dépôt GitLab hébergeant le code backend (Spring Boot) et frontend (Angular), ou deux dépôts avec pipelines croisés.

Un GitLab Runner configuré avec Docker-in-Docker (pour construire et pousser des images) ou des runners spécialisés pour Maven/Node.

Accès au GitLab Container Registry ou à un registre externe, et variables CI/CD sécurisées pour les credentials.

Un environnement de déploiement : Kubernetes, Docker Swarm ou une machine de staging/production avec accès SSH/CI.

Structure type du projet

Exemple de mono-repo classique :

/project-root /backend # Spring Boot (Maven ou Gradle) /frontend # Angular (Node/npm) /k8s # manifests Kubernetes .gitlab-ci.yml

Exemple minimal de fichier .gitlab-ci.yml

Exemple illustratif combinant build, test, image et déploiement. Les variables sensibles doivent être définies dans Settings > CI/CD > Variables du projet GitLab.

variables: MAVEN_CLI_OPTS: "--batch-mode --no-transfer-progress" DOCKER_TLS_CERTDIR: "" IMAGE_REGISTRY: "$CI_REGISTRY" IMAGE_NAME: "$CI_PROJECT_PATH" IMAGE_TAG: "$CI_COMMIT_SHORT_SHA" stages: - build - test - package - image - deploy build-frontend: image: node:18 stage: build script: - cd frontend - npm ci - npm run build -- --configuration=production cache: paths: - frontend/node_modules test-frontend: image: node:18 stage: test script: - cd frontend - npm ci - npm test -- --watch=false --browsers=ChromeHeadless build-backend: image: maven:3.8-jdk-17 stage: build script: - cd backend - mvn $MAVEN_CLI_OPTS clean package -DskipTests cache: paths: - backend/.m2/repository test-backend: image: maven:3.8-jdk-17 stage: test script: - cd backend - mvn $MAVEN_CLI_OPTS test docker-build-and-push: image: docker:24 services: - docker:dind stage: image script: - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY - docker build -t $IMAGE_REGISTRY/$IMAGE_NAME:$IMAGE_TAG -f backend/Dockerfile . - docker push $IMAGE_REGISTRY/$IMAGE_NAME:$IMAGE_TAG only: - main deploy: image: bitnami/kubectl:1.27 stage: deploy script: - kubectl --kubeconfig="$KUBECONFIG" set image deployment/backend backend=$IMAGE_REGISTRY/$IMAGE_NAME:$IMAGE_TAG -n production environment: name: production url: https://example.com only: - main

Explications des éléments clés

Gestion des artefacts et du cache

Le cache améliore la rapidité en réutilisant les dépendances Node et Maven. Les artefacts (par ex. build Angular ou jar Spring Boot) peuvent être stockés entre jobs à l'aide de la clé artifacts pour éviter de reconstruire inutilement.

Variables et secrets

Les credentials vers le registre Docker, les kubeconfig et autres secrets doivent être stockés dans les variables CI/CD protégées et masquées. Éviter d'inclure des secrets directement dans le dépôt. Utiliser des variables par environnement pour séparer staging et production.

Gestion des images et du tagging

Utiliser un tag immuable basé sur l'ID de commit ($CI_COMMIT_SHORT_SHA) pour faciliter le rollback. Conserver également un tag latest ou stable si nécessaire pour l'intégration avec des outils externes.

Déploiement et stratégies d'environnement

GitLab permet de définir des environments et des review apps pour chaque merge request. Pour Kubernetes, privilégier des déploiements progressifs (rolling update) et vérifier les probes (liveness/readiness) pour garantir des mises à jour sans interruption.

Rollback et résilience

En cas d'échec après le déploiement, le rollback peut être automatisé en réappliquant la dernière image stable ou en utilisant les fonctionnalités de rollback du contrôleur d'Ingress/deployment. Surveiller les métriques et définir des alertes pour déclencher des actions manuelles ou automatiques.

Bonnes pratiques

Travailler en pipelines parallèles pour réduire la latence : lancer les builds frontend et backend en parallèle lorsqu'ils sont indépendants. Intégrer des tests unitaires, d'intégration et des analyses statiques (SonarQube) dans des jobs séparés.

Limiter la durée des jobs et utiliser les caches pertinents. Favoriser des images Docker légères et des étapes idempotentes. Automatiser la promotion d'images entre environnements (staging → production) via des approbations manuelles si nécessaire.

Auditer les permissions : limiter les accès CI/CD aux variables sensibles et utiliser des rôles GitLab pour restreindre qui peut déclencher des déploiements en production.

Conclusion

La mise en place d'un pipeline GitLab CI/CD pour un stack Spring Boot + Angular unifie la chaîne de livraison et réduit les risques grâce à l'automatisation des tests, la construction d'images et le déploiement contrôlé. En appliquant les pratiques ci-dessus, l'équipe obtient des déploiements reproductibles, traçables et rapides, tout en conservant la sécurité des secrets et la capacité de rollback.