Module 11 – CI/CD GitLab (Voir le cours complet)

1. Pourquoi CI/CD ?

Sans pipeline :

• quelqu’un oublie de lancer les tests
• un bug arrive en prod
• personne ne sait quel commit l’a introduit

Avec pipeline :

• chaque commit est “certifié” par des étapes automatiques
• on détecte très tôt les erreurs

CI/CD = ceinture de sécurité.

---

Précision sur le vocabulaire

• CI (Continuous Integration) : intégrer souvent + tester
• CD (Continuous Delivery/Deployment) : livrer/déployer automatiquement

---

Pipeline minimal Maven

image: maven:3.9-eclipse-temurin-17

stages: [build, test]

build:
  stage: build
  script:
    - mvn -q -DskipTests compile

test:
  stage: test
  script:
    - mvn -q test

Explication :

• GitLab lance un container Maven
• exécute vos commandes
• si mvn test échoue → pipeline rouge

---

Ajouter un rapport JUnit (pratique)

test:
  stage: test
  script:
    - mvn test
  artifacts:
    when: always
    reports:
      junit: target/surefire-reports/*.xml

But : voir les tests dans l’UI GitLab.

---

Ajouter JaCoCo (couverture)

Vous voulez mesurer si vous testez “un peu” ou “sérieusement”.

---

Build Docker en CI

Version simple (concept) :

docker-build:
  stage: build
  image: docker:24
  services: [docker:dind]
  script:
    - docker build -t wouaf-api .

---

7. Check de santé après run (Actuator)

Dans un job, on peut :

• lancer l’API
• vérifier /actuator/health

Exemple (simplifié) :

curl -f http://localhost:8080/actuator/health || exit 1

Le -f fait échouer curl si status >= 400.

---

Pièges

• tests trop longs → pipeline lent → équipe contourne
• pipeline sans cache Maven → très lent
• secrets en dur dans YAML → interdit

---

A faire (optionnel car déjà vu dans le cours DevOps)

1. Ajoutez un job package (mvn package).
2. Ajoutez un job *lint (format, checkstyle si vous en avez).