Mise en place d'une chaîne CI/CD complète avec GitLab pour applications Spring Boot Angular

Dans l'écosystème du développement logiciel moderne, la vélocité et la fiabilité des déploiements sont des piliers fondamentaux. Les équipes cherchent constamment des méthodes pour automatiser les processus de build, de test et de déploiement, afin de livrer des applications de haute qualité plus rapidement et avec moins d'erreurs. C'est ici que l'Intégration Continue (CI) et le Déploiement Continu (CD), communément appelés CI/CD, entrent en jeu, transformant radicalement les cycles de vie des projets.

Pour des applications complexes intégrant un backend puissant en Spring Boot et une interface utilisateur réactive en Angular, la mise en place d'une chaîne CI/CD robuste est non seulement un atout, mais une nécessité. Parmi les plateformes disponibles, GitLab se distingue par son approche "tout-en-un", intégrant le gestionnaire de code source, le système CI/CD, le registre de conteneurs, et bien plus encore, dans une seule et même interface. Cet article, rédigé par un expert Java Spring Boot Angular tel que Laty Gueye Samba, développeur Full Stack à Dakar, Sénégal, explorera comment architecturer une chaîne CI/CD complète avec GitLab pour ces architectures.

L'objectif est de détailler les étapes clés pour automatiser le processus de déploiement continu de vos applications Spring Boot Angular, en tirant parti des capacités de Docker et GitLab, assurant ainsi une livraison logicielle agile et efficiente.

Conception de la Pipeline CI/CD sur GitLab

La colonne vertébrale de toute chaîne CI/CD sur GitLab est le fichier .gitlab-ci.yml, un fichier de configuration situé à la racine du dépôt de code. Ce fichier décrit l'ensemble des tâches (jobs) à exécuter et les étapes (stages) par lesquelles ces tâches passent, orchestrant ainsi l'ensemble du processus d'intégration et de déploiement.

Principes clés du .gitlab-ci.yml

• Stages : Définissent l'ordre d'exécution des groupes de jobs. Typiquement, il est recommandé d'utiliser des stages comme build, test, package, deploy.
• Jobs : Sont les unités de travail individuelles. Chaque job est défini avec son stage, les commandes à exécuter, et l'environnement d'exécution.
• Runners : Sont les agents qui exécutent les jobs. Ils peuvent être partagés par GitLab ou spécifiques à l'utilisateur (self-hosted).
• Images Docker : L'utilisation d'images Docker est fortement recommandée pour assurer un environnement d'exécution cohérent et isolé pour chaque job, garantissant que les dépendances et les outils sont toujours les mêmes, quel que soit le runner.

Un exemple simplifié de structure de .gitlab-ci.yml pourrait ressembler à ceci :

stages:
  - build
  - test
  - package
  - deploy

variables:
  DOCKER_IMAGE_NAME_BACKEND: $CI_REGISTRY_IMAGE/backend
  DOCKER_IMAGE_NAME_FRONTEND: $CI_REGISTRY_IMAGE/frontend
  
# Les jobs spécifiques au backend et au frontend seront définis ici

Cette structure prépare le terrain pour des pipelines parallèles et indépendantes pour le backend Spring Boot et le frontend Angular, tout en partageant des étapes logiques.

Intégration Continue et Déploiement du Backend Spring Boot

Pour le backend basé sur Java Spring Boot, la pipeline CI/CD se concentre sur la compilation du code, l'exécution des tests unitaires et d'intégration, la création d'un paquet exécutable (JAR ou WAR) et sa conteneurisation via Docker.

Phases de la Pipeline Spring Boot

Une séquence typique de jobs pour une application Spring Boot inclut :

1. Build : Compilation du code source et résolution des dépendances.
2. Test : Exécution des tests unitaires et d'intégration pour garantir la qualité du code.
3. Package & Dockerize : Création du JAR exécutable et construction de l'image Docker associée.
4. Push to Registry : Téléchargement de l'image Docker vers le GitLab Container Registry.

Voici un extrait de .gitlab-ci.yml illustrant ces étapes pour une application Spring Boot :

# ... (stages et variables définis précédemment) ...

backend-build:
  stage: build
  image: maven:3.8.6-openjdk-17-slim # Utilise une image Docker Maven
  script:
    - echo "Building Spring Boot backend..."
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - backend/target/*.jar
  only:
    - main # Exécuter uniquement sur la branche main

backend-test:
  stage: test
  image: maven:3.8.6-openjdk-17-slim
  script:
    - echo "Running backend tests..."
    - mvn test
  only:
    - main

backend-dockerize:
  stage: package
  image: docker:latest # Utilise l'image Docker pour construire des images Docker
  services:
    - docker:dind # Docker-in-Docker pour construire des images
  script:
    - cd backend
    - docker build -t $DOCKER_IMAGE_NAME_BACKEND:$CI_COMMIT_SHORT_SHA .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $DOCKER_IMAGE_NAME_BACKEND:$CI_COMMIT_SHORT_SHA
    - docker push $DOCKER_IMAGE_NAME_BACKEND:latest # Aussi tagger avec 'latest'
  only:
    - main
  # Le Dockerfile doit être situé dans le dossier 'backend'

Le Dockerfile du backend serait un fichier simple dans le répertoire backend/, ressemblant à ceci :

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

Cette approche garantit que chaque modification validée sur la branche main déclenche automatiquement la construction, le test et la conteneurisation de l'application Spring Boot, poussant l'image vers le GitLab Container Registry, prête pour le déploiement.

Intégration Continue et Déploiement du Frontend Angular

De manière similaire au backend, le frontend Angular nécessite une pipeline d'intégration continue pour garantir la qualité du code et automatiser le processus de build et de déploiement. L'objectif est de compiler l'application, d'exécuter les tests et de créer une image Docker légère qui servira les fichiers statiques de l'application.

Phases de la Pipeline Angular

La chaîne CI/CD pour Angular comprendra les étapes suivantes :

1. Install & Build : Installation des dépendances NPM et compilation de l'application Angular pour la production.
2. Test : Exécution des tests unitaires (Karma) et end-to-end (Cypress/Protractor) si configurés.
3. Dockerize : Création d'une image Docker, souvent basée sur Nginx, pour servir les fichiers statiques.
4. Push to Registry : Téléchargement de l'image Docker vers le GitLab Container Registry.

Voici un exemple de configuration pour le frontend Angular dans .gitlab-ci.yml :

# ... (stages et variables définis précédemment) ...

frontend-build:
  stage: build
  image: node:16-alpine # Utilise une image Node.js pour Angular
  script:
    - echo "Building Angular frontend..."
    - cd frontend
    - npm ci # npm install --ci pour une installation propre et rapide
    - npm run build -- --configuration=production --output-path=dist
  artifacts:
    paths:
      - frontend/dist # Récupère les fichiers compilés
  only:
    - main

frontend-test:
  stage: test
  image: node:16-alpine
  script:
    - echo "Running frontend tests..."
    - cd frontend
    - npm ci
    - npm test -- --no-watch --browsers=ChromeHeadless # Exécution des tests en mode headless
  only:
    - main

frontend-dockerize:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - cd frontend
    - docker build -t $DOCKER_IMAGE_NAME_FRONTEND:$CI_COMMIT_SHORT_SHA .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $DOCKER_IMAGE_NAME_FRONTEND:$CI_COMMIT_SHORT_SHA
    - docker push $DOCKER_IMAGE_NAME_FRONTEND:latest
  only:
    - main
  # Le Dockerfile doit être situé dans le dossier 'frontend'

Un Dockerfile pour l'application Angular (dans frontend/) utilisant Nginx pourrait être :

# frontend/Dockerfile
# Étape 1: Build de l'application Angular
FROM node:16-alpine as builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build -- --configuration=production

# Étape 2: Servir l'application avec Nginx
FROM nginx:alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Cela permet de construire une image Docker optimisée pour la production, réduisant la taille de l'image finale et améliorant la sécurité et les performances.

Conclusion

La mise en place d'une chaîne CI/CD complète avec GitLab pour des applications Spring Boot Angular est un investissement stratégique qui se traduit par une amélioration significative de la vélocité de développement et de la fiabilité des livraisons. En automatisant les processus de build, de test et de déploiement grâce à des outils comme Docker et GitLab, les équipes peuvent se concentrer sur l'innovation et la création de valeur, plutôt que sur des tâches manuelles répétitives et sujettes aux erreurs.

Pour un Développeur Full Stack Dakar Sénégal tel que Laty Gueye Samba, l'intégration de ces pratiques est fondamentale pour répondre aux exigences des projets modernes et pour délivrer des solutions logicielles performantes et maintenables. L'adoption d'un tel pipeline assure un déploiement continu de Spring Boot Angular efficace, renforçant la capacité à livrer des applications métier de haute qualité.

Pour approfondir vos connaissances, il est recommandé de consulter la documentation officielle de ces technologies :

• Documentation GitLab CI/CD
• Documentation Docker
• Guides Spring Boot
• Documentation Angular