Retour aux articles

Intégration continue et déploiement avec Docker et GitLab CI/CD pour projets Spring Boot/Angular

Intégration continue et déploiement avec Docker et GitLab CI/CD pour projets Spring Boot/Angular | Laty Gueye Samba - Développeur Full Stack Dakar Sénégal, Expert Java Spring Boot Angular

Intégration continue et déploiement avec Docker et GitLab CI/CD pour projets Spring Boot/Angular

Dans l'écosystème du développement logiciel moderne, la vitesse et la fiabilité du déploiement sont des piliers fondamentaux. Pour les projets complexes combinant un backend robuste comme Spring Boot et un frontend dynamique comme Angular, la mise en place d'une chaîne d'intégration et de déploiement continus (CI/CD) est non seulement un atout, mais une nécessité. Elle permet aux équipes de livrer des fonctionnalités plus rapidement, avec moins d'erreurs, et d'assurer une qualité constante.

Cet article explore comment Docker et GitLab CI/CD peuvent être exploités conjointement pour créer un pipeline de déploiement efficace et automatisé. Pour les développeurs Full Stack comme Laty Gueye Samba, basé à Dakar, Sénégal, la maîtrise de ces outils est essentielle pour gérer des applications métier complexes, garantissant une transition fluide du code source à la production.

L'objectif est de démontrer comment ces technologies s'intègrent pour transformer le processus de livraison, en rendant le déploiement reproductible et prédictible, un aspect crucial pour tout Développeur Full Stack expert Java Spring Boot Angular.

Docker : La conteneurisation pour des environnements uniformes

Le premier défi dans tout projet d'envergure est de garantir que l'application fonctionne de manière identique dans tous les environnements, du poste de développement à la production. Docker résout cette problématique en permettant d'empaqueter une application et toutes ses dépendances dans un conteneur standardisé. Ce conteneur est une unité légère, portable et auto-suffisante.

Pour un projet Spring Boot/Angular, cela signifie créer des images Docker distinctes pour le backend et le frontend. Le backend Spring Boot, par exemple, peut être conteneurisé avec son JVM et les dépendances Maven/Gradle, tandis que le frontend Angular sera empaqueté avec Node.js et un serveur web léger comme Nginx.

Voici des exemples simplifiés de Dockerfile pour chaque partie de l'application :

Dockerfile pour une application Spring Boot

# Base image for Java applications
FROM openjdk:17-jdk-slim AS build

# Set the working directory
WORKDIR /app

# Copy the Maven wrapper files to build faster
COPY mvnw .
COPY .mvn .mvn

# Copy the pom.xml and download dependencies first
COPY pom.xml .
RUN ./mvnw dependency:go-offline -B

# Copy the rest of the application source code
COPY src src

# Build the Spring Boot application
RUN ./mvnw package -DskipTests

# Runtime image
FROM openjdk:17-jre-slim

# Set argument for the JAR file
ARG JAR_FILE=target/*.jar

# Copy the JAR file from the build stage
COPY --from=build /app/${JAR_FILE} app.jar

# Expose the port on which the application will run
EXPOSE 8080

# Run the application
ENTRYPOINT ["java", "-jar", "/app.jar"]

Dockerfile pour une application Angular

# Stage 1: Build the Angular application
FROM node:18-alpine AS build

WORKDIR /app

# Copy package.json and package-lock.json for dependency installation
COPY package.json package-lock.json ./
RUN npm install

# Copy the rest of the application source code
COPY . .

# Build the Angular application for production
RUN npm run build -- --configuration=production

# Stage 2: Serve the Angular application with Nginx
FROM nginx:alpine

# Copy the build output from the previous stage to Nginx's HTML directory
COPY --from=build /app/dist/your-angular-app-name /usr/share/nginx/html

# Copy custom Nginx configuration (optional)
# COPY nginx.conf /etc/nginx/conf.d/default.conf

# Expose port 80
EXPOSE 80

# Start Nginx
CMD ["nginx", "-g", "daemon off;"]

Ces Dockerfile garantissent que le backend et le frontend s'exécutent dans des environnements isolés et prévisibles, peu importe où les conteneurs sont déployés.

GitLab CI/CD : L'orchestration du pipeline de déploiement

Une fois les applications conteneurisées avec Docker, l'étape suivante consiste à automatiser leur construction, leurs tests et leur déploiement. C'est là que GitLab CI/CD entre en jeu. Intégré nativement à GitLab, il utilise un fichier .gitlab-ci.yml à la racine du dépôt pour définir les étapes du pipeline.

Un pipeline GitLab CI/CD typique pour un projet Spring Boot/Angular peut inclure les stages suivants :

  • Build : Compilation du code backend et frontend, création des images Docker.
  • Test : Exécution des tests unitaires et d'intégration pour les deux parties de l'application.
  • Push : Envoi des images Docker construites vers un registre de conteneurs (Registry GitLab intégré ou autre).
  • Deploy : Déploiement des conteneurs mis à jour sur un environnement cible (serveur de développement, staging, production).

Voici un aperçu d'un fichier .gitlab-ci.yml pour un projet monorepo (backend et frontend dans le même dépôt) ou des dépôts séparés qui peuvent être adaptés :

Exemple de .gitlab-ci.yml

stages:
  - build
  - test
  - dockerize
  - deploy

variables:
  DOCKER_IMAGE_BACKEND: $CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA
  DOCKER_IMAGE_FRONTEND: $CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA
  DOCKER_REGISTRY_USER: $CI_REGISTRY_USER
  DOCKER_REGISTRY_PASSWORD: $CI_REGISTRY_PASSWORD
  DOCKER_REGISTRY: $CI_REGISTRY

build_backend:
  stage: build
  image: maven:3.8.6-openjdk-17
  script:
    - echo "Building Spring Boot backend..."
    - cd backend # Assuming backend is in a 'backend' directory
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - backend/target/*.jar
  only:
    - main
    - develop

build_frontend:
  stage: build
  image: node:18-alpine
  script:
    - echo "Building Angular frontend..."
    - cd frontend # Assuming frontend is in a 'frontend' directory
    - npm install
    - npm run build -- --configuration=production
  artifacts:
    paths:
      - frontend/dist
  only:
    - main
    - develop

test_backend:
  stage: test
  image: maven:3.8.6-openjdk-17
  script:
    - echo "Running backend tests..."
    - cd backend
    - mvn test
  needs: ["build_backend"]
  only:
    - main
    - develop

test_frontend:
  stage: test
  image: node:18-alpine
  script:
    - echo "Running frontend tests..."
    - cd frontend
    - npm test -- --watch=false # Run tests once
  needs: ["build_frontend"]
  only:
    - main
    - develop

dockerize_backend:
  stage: dockerize
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  script:
    - echo "Dockerizing backend..."
    - cd backend
    - docker build -t $DOCKER_IMAGE_BACKEND .
    - docker login -u $DOCKER_REGISTRY_USER -p $DOCKER_REGISTRY_PASSWORD $DOCKER_REGISTRY
    - docker push $DOCKER_IMAGE_BACKEND
  needs: ["build_backend"]
  only:
    - main
    - develop

dockerize_frontend:
  stage: dockerize
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  script:
    - echo "Dockerizing frontend..."
    - cd frontend
    - docker build -t $DOCKER_IMAGE_FRONTEND .
    - docker login -u $DOCKER_REGISTRY_USER -p $DOCKER_REGISTRY_PASSWORD $DOCKER_REGISTRY
    - docker push $DOCKER_IMAGE_FRONTEND
  needs: ["build_frontend"]
  only:
    - main
    - develop

deploy_staging:
  stage: deploy
  image: alpine/helm:3.10.0 # Or any suitable image for your deployment method (kubectl, ssh, etc.)
  script:
    - echo "Deploying to staging environment..."
    - # Example: ssh into server and run docker-compose pull/up or update Kubernetes manifests
    - # For simplicity, let's just echo a command
    - echo "Deployment command for staging: docker-compose -f docker-compose.staging.yml up -d"
  environment:
    name: staging
    url: https://staging.example.com
  needs: ["dockerize_backend", "dockerize_frontend"]
  only:
    - develop

Ce fichier .gitlab-ci.yml définit des jobs pour chaque étape, en utilisant des images Docker prédéfinies pour les environnements de build (Maven, Node.js) et pour les opérations Docker (docker:dind). Les variables $CI_REGISTRY_IMAGE, $CI_REGISTRY_USER, $CI_REGISTRY_PASSWORD sont des variables d'environnement prédéfinies par GitLab pour s'authentifier auprès de son registre de conteneurs. Ce pipeline assure un déploiement continu et fiable de chaque mise à jour.

Point de vue : développeur full stack à Dakar

Pour un développeur travaillant sur des systèmes comme des applications de gestion hospitalière ou des plateformes de gestion des risques, la maîtrise de l'intégration et du déploiement continus avec Docker et GitLab CI/CD représente un avantage concurrentiel réel sur le marché technologique africain, en pleine expansion. L'automatisation du déploiement permet de réduire le temps de mise sur le marché et d'améliorer la fiabilité des solutions offertes aux clients, un aspect que Laty Gueye Samba, Développeur Full Stack à Dakar, met régulièrement en œuvre dans ses projets.

Conclusion

L'intégration continue et le déploiement continu, soutenus par Docker et GitLab CI/CD, sont des pratiques indispensables pour tout projet Spring Boot/Angular moderne. Elles permettent de construire des applications plus robustes, de réduire les délais de livraison et d'améliorer la collaboration au sein des équipes de développement. Pour un Développeur Full Stack Dakar Sénégal comme Laty Gueye Samba, l'implémentation de ces pipelines d'automatisation est une marque d'expertise et d'efficacité, offrant une valeur ajoutée significative aux entreprises.

En adoptant ces méthodologies, les développeurs et les équipes peuvent se concentrer davantage sur l'innovation et la création de valeur, sachant que le processus de livraison est géré de manière professionnelle et automatisée.

Ressources Officielles :

À 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