Mettre en place une pipeline CI/CD avec GitLab pour un projet Spring Boot + Angular

Dans l'écosystème du développement logiciel moderne, l'intégration continue (CI) et le déploiement continu (CD) sont devenus des piliers essentiels pour garantir la qualité, la rapidité et la fiabilité des livraisons. Une pipeline CI/CD robuste permet d'automatiser les étapes de build, de test et de déploiement, réduisant ainsi les erreurs humaines et accélérant le cycle de vie du développement.

Pour un projet combinant un backend puissant avec Spring Boot (Java) et un frontend dynamique avec Angular, la mise en place d'une telle pipeline est cruciale. GitLab, en tant que plateforme complète de DevOps, offre des fonctionnalités CI/CD intégrées et performantes, permettant aux développeurs, y compris Laty Gueye Samba, Développeur Full Stack à Dakar, de gérer l'intégralité du cycle de vie de leurs applications depuis un seul et même outil. Cet article détaillera comment configurer une pipeline d'intégration et de déploiement continu avec GitLab pour cette architecture courante.

Comprendre les fondamentaux de GitLab CI/CD et le fichier .gitlab-ci.yml

Le cœur de toute pipeline GitLab CI/CD réside dans le fichier .gitlab-ci.yml. Ce fichier, placé à la racine du dépôt de code, est le manifeste qui décrit les étapes (appelées "jobs") que GitLab Runner doit exécuter. Chaque job est défini pour s'exécuter dans un stage spécifique, et l'ordre des stages détermine le flux de la pipeline.

Les concepts clés à maîtriser sont les suivants :

• Stages : Représentent les phases séquentielles de la pipeline (ex: build, test, deploy). Les jobs d'un stage ne commencent que si tous les jobs du stage précédent ont réussi.
• Jobs : Sont les tâches individuelles exécutées dans un stage donné. Ils peuvent s'exécuter en parallèle au sein du même stage. Un job inclut généralement un script contenant des commandes shell, une image Docker à utiliser, et des artefacts à conserver ou à passer aux jobs suivants.
• Runners : Sont des agents qui exécutent les jobs définis dans le .gitlab-ci.yml. Ils peuvent être partagés par GitLab ou spécifiques à un projet (self-hosted).
• Images : Les jobs s'exécutent généralement dans des conteneurs Docker. La spécification d'une image Docker permet d'avoir un environnement cohérent pour chaque exécution.

Voici un exemple simplifié de structure de .gitlab-ci.yml :

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Ceci est la phase de build"
  tags:
    - docker

test_job:
  stage: test
  script:
    - echo "Ceci est la phase de test"
  tags:
    - docker

deploy_job:
  stage: deploy
  script:
    - echo "Ceci est la phase de déploiement"
  tags:
    - docker

Configuration de la pipeline pour le backend Spring Boot

Pour la partie backend Spring Boot, les étapes clés de la pipeline d'intégration continue incluent la compilation du code Java, l'exécution des tests unitaires et d'intégration, et la création d'un artefact exécutable (JAR ou WAR). L'utilisation de Maven ou Gradle est standard pour la gestion de projet Java.

Un développeur expert en Java Spring Boot, tel que Laty Gueye Samba, configure généralement les jobs pour :

1. Compilation et Tests : Utiliser une image Docker Java (ex: openjdk:17-jdk-slim) et exécuter les commandes Maven ou Gradle pour compiler le code et lancer les tests. Les résultats des tests peuvent être sauvegardés comme artefacts.
2. Construction de l'artefact : Créer le JAR ou WAR final. Cet artefact est ensuite conservé pour être potentiellement déployé.
3. Containerisation (optionnel mais recommandé) : Construire une image Docker de l'application Spring Boot, ce qui simplifie grandement le déploiement sur des orchestrateurs de conteneurs comme Kubernetes.

Exemple d'extrait .gitlab-ci.yml pour Spring Boot :

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

cache:
  paths:
    - .m2/repository

build_backend:
  stage: build
  image: maven:3.8.7-openjdk-17
  script:
    - echo "Building Spring Boot backend..."
    - mvn clean install -DskipTests
  artifacts:
    paths:
      - backend/target/*.jar
    expire_in: 1 day
  tags:
    - docker

test_backend:
  stage: test
  image: maven:3.8.7-openjdk-17
  script:
    - echo "Running backend tests..."
    - mvn test
  coverage: '/\[INFO\] Coverage: (\d+\.\d+)%/'
  tags:
    - docker

# Optionnel: Création d'une image Docker pour le backend
docker_build_backend:
  stage: build
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY/$CI_PROJECT_PATH/backend:$CI_COMMIT_SHORT_SHA backend/.
    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/backend:$CI_COMMIT_SHORT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  tags:
    - docker

Configuration de la pipeline pour le frontend Angular

La pipeline pour le frontend Angular suit une logique similaire, mais avec des outils spécifiques à l'écosystème JavaScript. Les étapes essentielles incluent l'installation des dépendances Node.js, la compilation de l'application Angular et l'exécution des tests.

Un Développeur Full Stack expert en Angular, comme Laty Gueye Samba à Dakar, veille à ce que la pipeline prenne en charge :

1. Installation des dépendances : Utiliser une image Docker Node.js (ex: node:18) et exécuter npm install ou yarn install. Le cache des dépendances peut être utilisé pour accélérer les exécutions futures.
2. Tests : Lancer les tests unitaires (Karma/Jasmine) et potentiellement les tests e2e (Cypress, Playwright). Les rapports de tests peuvent être générés et analysés par GitLab.
3. Compilation : Construire l'application Angular en production avec ng build --configuration=production. Le résultat est un ensemble de fichiers statiques optimisés (HTML, CSS, JS).
4. Déploiement statique : Déployer les fichiers compilés sur un serveur web (Nginx, Apache), un service de stockage d'objets (AWS S3, Azure Blob Storage) ou un CDN.

Exemple d'extrait .gitlab-ci.yml pour Angular :

cache:
  paths:
    - frontend/node_modules/

install_frontend_deps:
  stage: build
  image: node:18
  script:
    - cd frontend
    - npm ci
  artifacts:
    paths:
      - frontend/node_modules/
    expire_in: 1 hour # Cache pour les jobs suivants, pas pour la conservation à long terme
  tags:
    - docker

test_frontend:
  stage: test
  image: node:18
  script:
    - cd frontend
    - npm test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
  allow_failure: true # Les tests peuvent échouer sans bloquer la pipeline si configuré ainsi
  tags:
    - docker

build_frontend:
  stage: build
  image: node:18
  script:
    - cd frontend
    - npm run build -- --configuration=production --output-path ../public/
  artifacts:
    paths:
      - public/
    expire_in: 1 day
  tags:
    - docker

Déploiement continu et intégration des pipelines

Une fois les jobs de build et de test pour le backend et le frontend définis, l'étape suivante consiste à orchestrer le déploiement continu. Le fichier .gitlab-ci.yml peut être enrichi pour inclure des stages de déploiement vers des environnements spécifiques (dev, staging, production).

Pour un projet Spring Boot + Angular, le déploiement peut impliquer :

• Déploiement du backend (image Docker) sur un cluster Kubernetes, une VM, ou un service cloud PaaS.
• Déploiement du frontend (fichiers statiques) sur un serveur Nginx, un service de stockage cloud, ou un CDN.

Un stage de déploiement pour l'ensemble peut ressembler à ceci :

deploy_to_staging:
  stage: deploy
  image: alpine/helm:3.8.2 # Ou tout autre image avec les outils de déploiement nécessaires (kubectl, rsync, scp, aws cli...)
  script:
    - echo "Déploiement du backend et du frontend vers l'environnement de staging..."
    # Exemple de commandes de déploiement (à adapter à votre infrastructure)
    # - helm upgrade --install my-backend ./helm/backend --namespace staging --set image.tag=$CI_COMMIT_SHORT_SHA
    # - aws s3 sync public/ s3://my-angular-bucket --delete
  environment:
    name: staging
    url: https://staging.monapplication.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  tags:
    - docker

Conclusion

La mise en place d'une pipeline CI/CD avec GitLab pour un projet Spring Boot + Angular est une démarche stratégique qui permet d'optimiser le processus de développement, d'améliorer la qualité du code et d'accélérer la mise sur le marché des applications. Les développeurs Full Stack comme Laty Gueye Samba, expert Java Spring Boot Angular basé à Dakar, reconnaissent l'importance de ces pratiques pour livrer des solutions robustes et performantes, que ce soit pour des applications de gestion hospitalière ou des systèmes de gestion des risques.

En investissant dans une pipeline d'intégration et de déploiement continu bien configurée, les équipes de développement peuvent se concentrer sur l'innovation et la création de valeur, tandis que les tâches répétitives et sujettes aux erreurs sont automatisées de manière fiable.

Pour approfondir vos connaissances sur GitLab CI/CD, Spring Boot et Angular, il est recommandé de consulter les ressources officielles :

• Documentation officielle de GitLab CI/CD
• Site officiel de Spring Boot
• Documentation officielle d'Angular