Aller au contenu

Déploiement du projet Chocolaterie de Pâques sur GitLab et mise en place d’un pipeline CI/CD complet

Objectif de cette étape

L’objectif de cette nouvelle étape consiste à professionnaliser le projet Spring Boot de la Chocolaterie de Pâques en le plaçant sur GitLab et en mettant en œuvre un pipeline CI/CD complet.

Ce pipeline devra permettre au minimum :


1. Contexte du projet

Le projet Chocolaterie de Pâques est désormais une application Spring Boot structurée en couches :

L’application utilise :

Le projet contient également :

Cette étape vise donc à automatiser tout cela dans un pipeline GitLab.


2. Compétences

À la fin de cette étape, vous serez capable de :


3. Préparation du dépôt GitLab

Avant de mettre en place le pipeline, le dépôt GitLab doit être propre.

3.1 Structure attendue

chocolaterie-paques-springboot-v3/
├── .gitlab-ci.yml
├── .gitignore
├── pom.xml
├── README.md
├── src/
│   ├── main/
│   └── test/
└── docs/

3.2 Fichiers importants à versionner

Vous devez versionner :

3.3 Fichiers à ne pas versionner

Le .gitignore doit au minimum exclure :

target/
.idea/
.project
.classpath
.settings/
*.iml
logs/

4. Principe général du pipeline GitLab

Le pipeline GitLab est défini dans le fichier : .gitlab-ci.yml

Ce fichier permet de décrire :


5. Stratégie de pipeline recommandée

Pour ce projet, une stratégie simple et progressive est recommandée.

5.1 Stages recommandés

Vous pouvez structurer le pipeline en plusieurs étapes :

Dans un premier temps, les 3 premiers suffisent :


6. Pipeline minimal conseillé

Voici une première version propre et réaliste du pipeline.

J’ai mis la version 21, mais on peut utiliser la 17.

image: maven:3.9.9-eclipse-temurin-21

stages:
  - build
  - test
  - package

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"

cache:
  paths:
    - .m2/repository

before_script:
  - java -version
  - mvn -version

build:
  stage: build
  script:
    - mvn $MAVEN_CLI_OPTS clean compile -DskipTests
  artifacts:
    paths:
      - target/
    expire_in: 1 hour

test:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test
  artifacts:
    when: always
    reports:
      junit:
        - target/surefire-reports/*.xml
    paths:
      - target/surefire-reports/
    expire_in: 1 week

package:
  stage: package
  script:
    - mvn $MAVEN_CLI_OPTS clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 week

7. Explication détaillée du pipeline

Pour cette démonstration, nous allons utiliser une image Docker en espérant que cela soit possible pour vous !

7.1 Image Docker

image: maven:3.9.9-eclipse-temurin-21

Le job s’exécute dans un conteneur Docker contenant Maven et Java.


7.2 Stages

stages:
  - build
  - test
  - package

Les jobs sont exécutés dans cet ordre logique.


7.3 Variables Maven

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"

Pourquoi ces variables ?


7.4 Cache Maven

cache:
  paths:
    - .m2/repository

Le cache permet d’éviter de re-télécharger toutes les dépendances Maven à chaque pipeline.


7.5 before_script

before_script:
  - java -version
  - mvn -version

Très utile pour vérifier rapidement dans les logs si les versions sont correctes :


7.6 Job build

build:
  stage: build
  script:
    - mvn $MAVEN_CLI_OPTS clean compile -DskipTests

Ce job vérifie que le code compile.

Il permet d’échouer rapidement si :


7.7 Job test

test:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test

Ce job exécute les tests.

Dans votre projet, cela couvre :

Rapports JUnit

artifacts:
  when: always
  reports:
    junit:
      - target/surefire-reports/*.xml

Cela permet à GitLab de lire les rapports JUnit et d’afficher les résultats de tests dans l’interface.


7.8 Job package

package:
  stage: package
  script:
    - mvn $MAVEN_CLI_OPTS clean package -DskipTests

Ce job construit le fichier JAR final à livrer qui est l’exécutable.


8. Version plus complète du pipeline

Une fois le pipeline minimal validé, vous pouvez passer à une version un peu plus professionnelle.

image: maven:3.9.9-eclipse-temurin-21

stages:
  - validate
  - build
  - test
  - package
  - quality

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"

cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - .m2/repository

before_script:
  - java -version
  - mvn -version

validate:
  stage: validate
  script:
    - mvn $MAVEN_CLI_OPTS validate

build:
  stage: build
  script:
    - mvn $MAVEN_CLI_OPTS compile -DskipTests

test:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test
  artifacts:
    when: always
    reports:
      junit:
        - target/surefire-reports/*.xml
    paths:
      - target/surefire-reports/
    expire_in: 1 week

package:
  stage: package
  script:
    - mvn $MAVEN_CLI_OPTS clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 week

quality:
  stage: quality
  script:
    - mvn $MAVEN_CLI_OPTS verify

9. Cas particulier du projet Chocolaterie

9.1 Pourquoi les tests passent en CI sans PostgreSQL ?

Parce que vos tests utilisent H2 via application-test.yml.

C’est un excellent choix pour la CI, car GitLab n’a pas besoin :

Cela rend le pipeline :


9.2 Point d’attention sur les tests Spring Boot

Votre pipeline doit vérifier que les tests suivants passent :

Autrement dit, votre job test doit valider :


10. Génération d’artefacts utiles

En plus du JAR, vous pouvez conserver :

Exemple :

artifacts:
  when: always
  paths:
    - target/*.jar
    - target/surefire-reports/

11. Ajouter JaCoCo (plus tard)

Une bonne amélioration consiste à intégrer JaCoCo pour mesurer la couverture de tests, mais le rapport semble être généré lorsque tout va bien mais ne l’est pas lorsqu’un test échoue avec notre configuration VDI. Je laisse ce chapitre mais on ne va pas l’aborder.

Intérêt

Cela nécessitera :


12. Ajouter des règles GitLab

Vous pouvez décider que certains jobs ne s’exécutent que dans certains cas. Ici, ce sont des spécificités expliquées dans le cours complet sur Gitlab.

Exemple :

package:
  stage: package
  script:
    - mvn $MAVEN_CLI_OPTS clean package -DskipTests
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_COMMIT_TAG'

Intérêt


13. Préparer le déploiement

Une fois la CI stable, vous pourrez ajouter une vraie étape de déploiement.

13.1 Déploiement possible à terme

13.2 Pipeline cible à terme

Build -> Test -> Package -> Docker Build -> Push Registry -> Deploy

14. Variante avec construction Docker plus tard

Quand vous serez prêt, vous pourrez ajouter un job du type :

docker-build:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t chocolaterie-paques .

Cette partie est à réserver à une étape ultérieure, quand la CI Maven sera parfaitement stable.


15. Variables GitLab CI/CD

Pour les étapes futures, vous pourrez stocker dans GitLab :

Ces variables doivent être placées dans :

Ne versionnez jamais ces secrets dans le dépôt.


16. README conseillé pour le dépôt

Votre README.md devrait au minimum contenir :


17. Travail à faire (si la configuration rend cela faisable)

Partie 1 – Mise en dépôt GitLab

  1. créer un projet GitLab
  2. pousser le projet Spring Boot
  3. vérifier la structure du dépôt

Partie 2 – Pipeline minimal

  1. créer .gitlab-ci.yml
  2. mettre en place les stages build, test, package
  3. lancer un premier pipeline
  4. analyser les logs

Partie 3 – Rapports et artefacts

  1. publier les rapports JUnit
  2. conserver le JAR comme artefact
  3. vérifier les résultats dans GitLab

Partie 4 – Amélioration

  1. ajouter un job validate
  2. ajouter un job quality
  3. ajouter éventuellement JaCoCo (optionnel)
  4. préparer la future phase de déploiement.

18. Livrables attendus

Vous devez rendre :


19. Critères


20. Résultat attendu

À la fin de cette étape, le projet Chocolaterie de Pâques doit :


21. Conseils pratiques

Un pipeline CI/CD se construit comme une boîte de chocolats sérieuse : par couches bien ordonnées, pas en jetant tout dans le moule en espérant un miracle.


22. Version finale recommandée du .gitlab-ci.yml

Voici une version finale prête à tester pour ce projet :

image: maven:3.9.9-eclipse-temurin-21

stages:
  - build
  - test
  - package

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"

cache:
  paths:
    - .m2/repository

before_script:
  - java -version
  - mvn -version

build:
  stage: build
  script:
    - mvn $MAVEN_CLI_OPTS clean compile -DskipTests

test:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test
  artifacts:
    when: always
    reports:
      junit:
        - target/surefire-reports/*.xml
    paths:
      - target/surefire-reports/
    expire_in: 1 week

package:
  stage: package
  script:
    - mvn $MAVEN_CLI_OPTS clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 week

23. Piste d’amélioration ultérieure

Quand cette étape sera maîtrisée, vous pourrez enchaîner sur :

Ce sera alors la vraie suite industrielle du projet. Mais j’ignore encore quel sera votre processus complet chez CA !