Mettre en place une pipeline CI/CD robuste avec GitLab CI pour une stack Spring Boot / Angular
Dans le monde du développement logiciel moderne, la vélocité et la fiabilité sont des piliers fondamentaux. L'intégration continue (CI) et le déploiement continu (CD), souvent regroupés sous le terme de CI/CD, sont des pratiques essentielles qui permettent aux équipes de livrer des applications de haute qualité plus fréquemment et avec une plus grande confiance. Pour les architectures composites, telles qu'une stack combinant un backend Spring Boot et un frontend Angular, la mise en place d'une pipeline CI/CD robuste est indispensable pour orchestrer les différentes étapes de build, de test et de déploiement.
GitLab CI, solution intégrée à la plateforme GitLab, offre un cadre puissant et flexible pour définir des pipelines CI/CD directement dans le dépôt de code. Sa capacité à gérer des projets polyglottes et à s'intégrer profondément dans le cycle de vie du développement en fait un choix privilégié pour les développeurs. L'objectif de cet article est de détailler les étapes nécessaires pour construire une pipeline CI/CD efficace avec GitLab CI, spécifiquement adaptée à une application Spring Boot et Angular, une expertise que Laty Gueye Samba, Développeur Full Stack basé à Dakar, mobilise régulièrement dans des applications métier complexes et des systèmes ERP.
En automatisant ces processus, les équipes peuvent réduire les erreurs manuelles, accélérer le cycle de feedback, et garantir que seules les versions stables et testées de l'application atteignent la production. Pour un expert Java Spring Boot Angular, la maîtrise de ces outils est un atout majeur pour optimiser la livraison de valeur client et maintenir un haut niveau de qualité logicielle, que ce soit pour des projets de gestion hospitalière ou des applications de gestion des risques.
Les Fondations d'une Pipeline GitLab CI Efficace
Le cœur d'une pipeline GitLab CI réside dans le fichier .gitlab-ci.yml, situé à la racine du dépôt. Ce fichier YAML décrit l'ensemble des étapes (stages) et des tâches (jobs) qui composent la pipeline. Chaque job s'exécute généralement dans un conteneur Docker isolé, ce qui garantit un environnement de build cohérent et reproductible.
Une pipeline pour une stack Spring Boot / Angular devra typiquement inclure des stages pour le build, les tests, le packaging (Dockerisation par exemple) et le déploiement. L'utilisation d'images Docker spécifiques pour chaque technologie (Java pour Spring Boot, Node.js pour Angular) est une pratique courante pour isoler les dépendances et les environnements d'exécution.
stages:
- build
- test
- package
- deploy
variables:
DOCKER_DRIVER: overlay2 # Recommandé pour la performance de Docker in Docker
DOCKER_TLS_CERTDIR: "" # Désactiver TLS pour Docker in Docker
default:
interruptible: true # Annule les jobs en cours si une nouvelle version est poussée
tags:
- docker # Utilise un runner avec le tag 'docker'
Les variables permettent de définir des paramètres réutilisables, tandis que default applique des configurations communes à tous les jobs, comme l'utilisation d'un type de runner spécifique ou la configuration de l'interruption des jobs.
Intégration et Tests du Backend Spring Boot
Pour le backend Spring Boot, les étapes clés de la pipeline incluent la compilation du code Java, l'exécution des tests unitaires et d'intégration, et la création d'une image Docker de l'application. L'utilisation de Maven ou Gradle est standard pour la gestion du build.
Le Dockerfile.backend devra être optimisé pour Spring Boot, potentiellement avec une image de base multi-étapes pour réduire la taille finale de l'image.
build_backend:
stage: build
image: maven:3.8.7-openjdk-17
script:
- echo "Building Spring Boot application..."
- mvn clean package -DskipTests
artifacts:
paths:
- target/*.jar
expire_in: 1 day # Conserver l'artifact pour un temps limité
test_backend:
stage: test
image: maven:3.8.7-openjdk-17
script:
- echo "Running backend tests..."
- mvn test
needs:
- build_backend
docker_backend:
stage: package
image: docker:20.10.16-alpine
services:
- docker:20.10.16-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- docker build -t "$CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA" -f Dockerfile.backend .
- docker push "$CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA"
needs:
- build_backend
only:
- master # Exécuter uniquement sur la branche master
Ce bloc définit un job build_backend pour compiler l'application et générer le JAR, un job test_backend pour exécuter les tests, et un job docker_backend pour construire et pousser l'image Docker vers le registre GitLab. Les needs garantissent l'ordre d'exécution des jobs.
Automatisation du Frontend Angular avec GitLab CI
La partie frontend Angular nécessite l'installation des dépendances Node.js, la compilation de l'application pour la production, l'exécution des tests unitaires et éventuellement des tests e2e, puis la conteneurisation via Docker, souvent avec un serveur web léger comme Nginx.
Un Dockerfile.frontend typique utilisera Nginx pour servir les fichiers statiques générés par le build Angular.
build_frontend:
stage: build
image: node:18-alpine
script:
- echo "Installing Angular dependencies and building application..."
- npm ci --legacy-peer-deps # npm ci pour une installation propre
- npm run build -- --configuration=production --output-path=./dist/frontend-app
artifacts:
paths:
- dist/frontend-app/
expire_in: 1 day
test_frontend:
stage: test
image: node:18-alpine
script:
- echo "Running frontend tests..."
- npm ci --legacy-peer-deps
- npm test -- --watch=false --browsers=ChromeHeadless
needs:
- build_frontend
docker_frontend:
stage: package
image: docker:20.10.16-alpine
services:
- docker:20.10.16-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- docker build -t "$CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA" -f Dockerfile.frontend .
- docker push "$CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA"
needs:
- build_frontend
only:
- master
Similaire au backend, ces jobs gèrent les étapes de build, de test et de conteneurisation pour l'application Angular, en s'assurant que les dépendances sont installées correctement et que l'application est compilée pour la production.
Point de vue : développeur full stack à Dakar
Pour un développeur travaillant sur des systèmes comme des applications métier complexes, la gestion hospitalière ou des systèmes ERP, la maîtrise des pipelines CI/CD représente un avantage concurrentiel réel sur le marché technologique africain, en pleine expansion. L'automatisation des processus de déploiement, permise par des outils comme GitLab CI, est essentielle pour garantir la qualité et l'efficacité des livraisons dans des contextes à forte exigence. Un expert Java Spring Boot Angular comme Laty Gueye Samba capitalise sur ces compétences pour assurer des livraisons fiables et rapides, cruciales pour la réussite des projets à Dakar et au-delà.
Déploiement Continu : De la Pipeline à la Production
Le stage de déploiement est l'aboutissement de la pipeline. Il peut impliquer diverses stratégies : pousser des images Docker vers un orchestrateur de conteneurs (Kubernetes, Docker Swarm), déployer sur des machines virtuelles via SSH, ou utiliser des services cloud spécifiques.
Il est courant de séparer les jobs de déploiement pour différents environnements (staging, production) et de les conditionner à certaines branches ou à des approbations manuelles.
deploy_staging:
stage: deploy
image: alpine/helm:3.10.0 # Exemple d'image pour un déploiement Kubernetes
script:
- echo "Deploying to staging environment..."
# Exemple: Mettre à jour un déploiement Kubernetes
# - kubectl config use-context your-k8s-context
# - helm upgrade --install my-app ./helm-chart --namespace staging --set backend.image.tag=$CI_COMMIT_SHORT_SHA --set frontend.image.tag=$CI_COMMIT_SHORT_SHA
environment:
name: staging
url: https://staging.example.com
only:
- master
needs:
- docker_backend
- docker_frontend
deploy_production:
stage: deploy
image: alpine/helm:3.10.0
script:
- echo "Deploying to production environment..."
# - kubectl config use-context your-prod-k8s-context
# - helm upgrade --install my-app ./helm-chart --namespace production --set backend.image.tag=$CI_COMMIT_SHORT_SHA --set frontend.image.tag=$CI_COMMIT_SHORT_SHA
environment:
name: production
url: https://prod.example.com
when: manual # Déclenchement manuel pour la production
only:
- master
needs:
- deploy_staging # Assurer que le staging a été déployé avec succès
Ces exemples de jobs deploy_staging et deploy_production illustrent comment les déploiements peuvent être automatisés vers différents environnements. Le déploiement en production est souvent configuré pour être manuel (when: manual) pour permettre une validation finale.
Conclusion
La mise en place d'une pipeline CI/CD robuste avec GitLab CI pour une stack Spring Boot / Angular est un investissement stratégique qui se traduit par une amélioration significative de la qualité logicielle, une réduction des délais de livraison et une meilleure collaboration au sein des équipes de développement. En automatisant les processus de build, de test et de déploiement continu, les développeurs peuvent se concentrer sur l'innovation et la création de valeur.
Pour un Développeur Full Stack comme Laty Gueye Samba, basé à Dakar et expert Java Spring Boot Angular, la capacité à concevoir et à maintenir de telles pipelines est fondamentale. Elle garantit que les projets, qu'ils soient de grande envergure pour des clients institutionnels ou des startups innovantes, bénéficient d'une fondation solide pour une livraison logicielle efficace et durable.
Pour approfondir ce sujet, il est fortement recommandé de consulter la documentation officielle de chaque outil :
À 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