Mettre en place une pipeline CI/CD automatisée avec GitLab pour une stack Spring Boot/Angular et Docker

Dans l'écosystème du développement logiciel moderne, l'automatisation des processus de construction, de test et de déploiement est devenue une pierre angulaire pour la livraison rapide et fiable d'applications. La mise en place d'une pipeline d'intégration continue et de déploiement continu (CI/CD) est une pratique DevOps essentielle qui permet aux équipes de livrer du code plus fréquemment et avec une plus grande confiance. Cet article explore comment une stack technique robuste, composée de Spring Boot pour le backend, Angular pour le frontend, et Docker pour la conteneurisation, peut être orchestrée via GitLab CI/CD pour une automatisation complète.

Le développeur Full Stack, tel que Laty Gueye Samba, qui excelle à la fois en Java Spring Boot et en Angular, comprend l'importance de relier ces composants au travers de processus efficaces. L'intégration de Docker dans cette stratégie permet de garantir la cohérence des environnements, de la machine du développeur à la production. L'objectif est de minimiser les erreurs humaines, d'accélérer le cycle de développement et d'assurer une qualité logicielle constante, des aspects cruciaux pour les projets de toute envergure, y compris les applications métier complexes ou les systèmes ERP.

Principes Fondamentaux de la CI/CD avec GitLab

GitLab CI/CD est un outil puissant intégré à la plateforme GitLab qui permet de définir des pipelines directement dans le dépôt de code source via un fichier .gitlab-ci.yml. Ce fichier configure les étapes (stages) et les tâches (jobs) qui seront exécutées automatiquement à chaque push de code. Les avantages sont multiples : détection précoce des bugs, tests automatisés, et déploiements standardisés.

Une pipeline CI/CD typique se compose généralement de plusieurs stages :

• Build : Compilation du code source, résolution des dépendances.
• Test : Exécution des tests unitaires, d'intégration et end-to-end.
• Package : Création d'artefacts déployables (JAR pour Spring Boot, fichiers statiques pour Angular, images Docker).
• Deploy : Déploiement des artefacts vers un environnement cible (développement, staging, production).

L'utilisation de Docker est ici fondamentale. Chaque job de la pipeline peut s'exécuter dans un conteneur Docker spécifique, garantissant un environnement propre et reproductible pour chaque étape. Cela élimine les problèmes de "ça marche sur ma machine" et assure que la chaîne de construction est toujours exécutée dans les mêmes conditions, un atout majeur pour la fiabilité du déploiement continu.

Mise en œuvre de la CI pour Spring Boot et Angular

La première étape consiste à configurer les jobs de build et de test pour chaque partie de l'application : le backend Spring Boot et le frontend Angular. L'objectif est de vérifier que le code est compilable, que tous les tests passent et que des images Docker peuvent être construites avec succès.

Configuration du Backend Spring Boot

Pour le backend Spring Boot, un job de CI se chargera de compiler le projet (généralement avec Maven ou Gradle) et d'exécuter les tests unitaires et d'intégration. Par la suite, une image Docker pour l'application Spring Boot est créée.

# .gitlab-ci.yml (extrait pour Spring Boot)
stages:
  - build
  - test
  - package
  - deploy

build_backend:
  stage: build
  image: maven:3.8.5-openjdk-17 # Ou gradle
  script:
    - echo "Building Spring Boot backend..."
    - mvn clean install -DskipTests
  artifacts:
    paths:
      - backend/target/*.jar

test_backend:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - echo "Running backend tests..."
    - mvn test
  dependencies:
    - build_backend

docker_build_backend:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - cd backend
    - docker build -t $CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA
  only:
    - main # Ou la branche de votre choix

# backend/Dockerfile (exemple)
FROM openjdk:17-jdk-slim
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
EXPOSE 8080

Configuration du Frontend Angular

De manière similaire, le frontend Angular nécessitera des jobs pour installer les dépendances, compiler l'application, exécuter les tests et enfin, construire une image Docker contenant l'application Angular servie par un serveur web (comme Nginx).

# .gitlab-ci.yml (extrait pour Angular)
build_frontend:
  stage: build
  image: node:16 # Version de Node.js compatible avec Angular
  script:
    - echo "Building Angular frontend..."
    - cd frontend
    - npm install
    - npm run build -- --configuration=production # Compiler en production
  artifacts:
    paths:
      - frontend/dist/

test_frontend:
  stage: test
  image: node:16
  script:
    - echo "Running frontend tests..."
    - cd frontend
    - npm install
    - npm test -- --no-watch --browsers=ChromeHeadless
  dependencies:
    - build_frontend

docker_build_frontend:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - cd frontend
    - docker build -t $CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA
  only:
    - main

# frontend/Dockerfile (exemple pour Angular avec Nginx)
FROM nginx:alpine
COPY ./dist/frontend /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Déploiement Continu avec Docker et GitLab Registry

Une fois les images Docker construites et poussées vers le GitLab Container Registry (qui agit comme un dépôt d'images Docker privé), l'étape de déploiement peut être automatisée. Cela implique généralement de se connecter à un serveur cible et d'y exécuter des commandes Docker pour récupérer et démarrer les nouvelles versions des conteneurs.

# .gitlab-ci.yml (extrait pour le déploiement)
deploy_to_staging:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  script:
    - apk add openssh-client # Installer SSH pour la connexion au serveur
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan $STAGING_SERVER_IP >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - ssh $STAGING_USER@$STAGING_SERVER_IP "
        docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY &&
        cd /path/to/your/app &&
        docker-compose pull &&
        docker-compose up -d --remove-orphans
      "
  environment:
    name: staging
    url: http://$STAGING_SERVER_IP
  only:
    - main

Il est crucial de configurer les variables d'environnement (SSH_PRIVATE_KEY, STAGING_USER, STAGING_SERVER_IP) dans les paramètres CI/CD de votre projet GitLab pour des raisons de sécurité. La commande docker-compose pull && docker-compose up -d permet de mettre à jour les conteneurs avec les dernières images du registry et de les redémarrer.

Conclusion

La mise en place d'une pipeline CI/CD automatisée avec GitLab pour une stack Spring Boot/Angular et Docker est un investissement stratégique qui se traduit par une amélioration significative de la vélocité de développement et de la qualité logicielle. Elle permet aux développeurs, comme Laty Gueye Samba, Développeur Full Stack à Dakar, d'embrasser pleinement les principes DevOps, de réduire les risques de déploiement et de se concentrer sur l'innovation. Cette approche est une composante essentielle pour la réussite des projets dans un environnement technologique en constante évolution.

Pour aller plus loin, il est recommandé de consulter les ressources officielles :

• Documentation GitLab CI/CD
• Site officiel Spring Boot
• Documentation Angular
• Documentation Docker