Mettre en place une chaîne CI/CD complète avec GitLab pour un projet Full Stack Dockerisé

Le développement logiciel moderne exige des processus efficaces et automatisés pour garantir la qualité, la rapidité de livraison et la fiabilité des applications. Dans ce contexte, l'intégration continue et le déploiement continu (CI/CD) sont devenus des piliers incontournables. Cet article technique explore comment mettre en place une chaîne CI/CD complète et robuste en utilisant GitLab pour un projet Full Stack typiquement composé d'un backend Java Spring Boot et d'un frontend Angular, l'ensemble étant conteneurisé avec Docker.

Pour un Développeur Full Stack Java Spring Boot + Angular comme Laty Gueye Samba basé à Dakar, Sénégal, la maîtrise de ces outils est essentielle. Un pipeline CI/CD bien configuré permet d'automatiser le cycle de vie du développement, de la validation du code à son déploiement en production, minimisant ainsi les erreurs humaines et accélérant la mise à disposition de nouvelles fonctionnalités. L'objectif est de présenter une approche pragmatique pour construire un tel système, en tirant parti des capacités de GitLab, un outil de choix pour les équipes de développement.

Les fondations : Dockerisation et gestion de dépôt avec GitLab

Avant d'implémenter une chaîne CI/CD, il est impératif que le projet soit correctement conteneurisé. La Dockerisation garantit que l'application s'exécutera de manière identique quel que soit l'environnement, simplifiant ainsi considérablement les phases de test et de déploiement. Un projet Full Stack Dockerisé implique généralement la création de conteneurs séparés pour le backend (Java Spring Boot), le frontend (Angular) et éventuellement une base de données.

Chaque composant aura son propre Dockerfile définissant comment construire son image. Par exemple, pour un backend Spring Boot, le Dockerfile pourrait ressembler à ceci :

# Dockerfile pour le backend Spring Boot
FROM openjdk:17-jdk-slim AS build
WORKDIR /app
COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
RUN ./mvnw dependency:go-offline
COPY src src
RUN ./mvnw package -DskipTests

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
    

Et pour un frontend Angular :

# Dockerfile pour le frontend Angular
FROM node:18-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
RUN npm run build -- --configuration production

FROM nginx:stable-alpine
COPY --from=build /app/dist/votre-projet-angular /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
    

Une fois les Dockerfile en place, le code source du projet, y compris ces fichiers, doit être hébergé dans un dépôt GitLab. GitLab ne se contente pas d'offrir un système de gestion de versions (SCM) robuste ; il intègre également une solution CI/CD puissante qui s'appuie sur la configuration définie dans le fichier .gitlab-ci.yml à la racine du dépôt. C'est à partir de ce dépôt que le pipeline CI/CD de GitLab lira les instructions pour construire, tester et déployer l'application.

Conception du pipeline CI/CD avec GitLab CI

Le cœur de la chaîne CI/CD réside dans le fichier .gitlab-ci.yml. Ce fichier YAML décrit les étapes, ou "stages", et les tâches, ou "jobs", que GitLab Runner exécutera automatiquement lors de chaque modification du code poussée dans le dépôt. Une approche typique pour un projet Full Stack Dockerisé inclut des stages comme la construction (build), les tests (test), la conteneurisation (package/dockerize) et le déploiement (deploy).

Voici un aperçu simplifié de la structure d'un fichier .gitlab-ci.yml pour orchestrer ces étapes :

# .gitlab-ci.yml
stages:
  - build
  - test
  - package
  - deploy

variables:
  DOCKER_IMAGE_BACKEND: $CI_REGISTRY_IMAGE/backend:$CI_COMMIT_SHORT_SHA
  DOCKER_IMAGE_FRONTEND: $CI_REGISTRY_IMAGE/frontend:$CI_COMMIT_SHORT_SHA

build_backend:
  stage: build
  image: openjdk:17-jdk-slim
  script:
    - ./mvnw clean package -DskipTests
  artifacts:
    paths:
      - backend/target/*.jar

build_frontend:
  stage: build
  image: node:18-alpine
  script:
    - npm install
    - npm run build -- --configuration production
  artifacts:
    paths:
      - frontend/dist

test_backend:
  stage: test
  image: openjdk:17-jdk-slim
  script:
    - ./mvnw test

# Pas de test unitaire complexe pour le frontend dans cet exemple simplifié,
# mais des outils comme Jest ou Karma seraient intégrés ici.

dockerize_backend:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE_BACKEND ./backend
    - docker push $DOCKER_IMAGE_BACKEND
  only:
    - main

dockerize_frontend:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE_FRONTEND ./frontend
    - docker push $DOCKER_IMAGE_FRONTEND
  only:
    - main

deploy_production:
  stage: deploy
  image: alpine/helm:3.8.1
  # Pour un déploiement sur un serveur distant via SSH
  before_script:
    - apk add openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan $REMOTE_HOST >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    - ssh $REMOTE_USER@$REMOTE_HOST "docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY"
    - ssh $REMOTE_USER@$REMOTE_HOST "docker pull $DOCKER_IMAGE_BACKEND"
    - ssh $REMOTE_USER@$REMOTE_HOST "docker pull $DOCKER_IMAGE_FRONTEND"
    - ssh $REMOTE_USER@$REMOTE_HOST "docker-compose down && docker-compose up -d" # Ou commandes docker run
  environment: production
  only:
    - main
    

Dans cet exemple, des variables GitLab CI/CD prédéfinies comme $CI_REGISTRY_IMAGE et $CI_COMMIT_SHORT_SHA sont utilisées pour tagger les images Docker, garantissant un suivi précis. Les services docker:dind (Docker in Docker) sont essentiels pour permettre aux jobs de construire et de pousser des images Docker. L'utilisation de only: - main restreint l'exécution de certains jobs (comme la conteneurisation et le déploiement) à la branche principale, assurant ainsi que seul le code stable et validé atteint ces étapes critiques.

Déploiement continu sur des environnements Docker

La dernière étape, et non la moindre, est le déploiement continu. Grâce à la Dockerisation et aux capacités de GitLab CI, le déploiement sur des environnements cibles (staging, production) devient une tâche automatisée et répétable. Les artefacts (images Docker) construits et poussés vers le GitLab Container Registry sont prêts à être tirés et exécutés sur n'importe quel serveur compatible Docker.

Pour un déploiement sur un serveur distant, des techniques comme SSH ou l'intégration avec des orchestrateurs de conteneurs tels que Docker Swarm ou Kubernetes sont couramment employées. L'exemple de déploiement ci-dessus utilise SSH pour se connecter à un hôte distant et y exécuter des commandes Docker. Il est crucial de sécuriser les informations d'identification (clés SSH, identifiants Docker Registry) en utilisant les variables de CI/CD sécurisées de GitLab. Ces variables sont chiffrées et ne sont exposées qu'aux jobs spécifiés, évitant ainsi de les commettre directement dans le dépôt.

Pour des architectures plus complexes, notamment celles utilisées dans des applications métier critiques ou des plateformes ERP, l'utilisation d'outils comme Docker Compose pour gérer plusieurs conteneurs liés sur un seul hôte, ou de Helm pour déployer sur Kubernetes, est une pratique courante. GitLab CI s'intègre naturellement avec ces outils, offrant une flexibilité pour s'adapter à diverses infrastructures cibles.

Conclusion

Mettre en place une chaîne CI/CD complète avec GitLab pour un projet Full Stack Dockerisé est une étape fondamentale vers l'excellence opérationnelle en développement logiciel. Cette approche, adoptée par des experts comme Laty Gueye Samba, Développeur Full Stack à Dakar, permet d'automatiser les tâches répétitives, de garantir la cohérence des environnements et de réduire le temps de mise sur le marché des applications. Les avantages en termes de qualité, de stabilité et de productivité sont considérables.

En intégrant Docker pour la conteneurisation et GitLab CI pour l'orchestration des pipelines, les équipes peuvent se concentrer davantage sur le développement de fonctionnalités innovantes, sachant que la livraison du code est gérée de manière fiable et sécurisée. C'est une démarche stratégique pour tout développeur ou toute entreprise souhaitant rester compétitif dans l'écosystème technologique actuel.

Ressources Officielles :

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